Implement libraries_library(), so that modules that work with Libraries API can use their libraries (via drupal_add_library()) without having to implement their own hook_library().

<?php
/**
 * Implement hook_libraries_info().
 */
function tinymce_libraries_info() {
 
$libraries['tinymce'] = array(
   
'files' => array(
     
'js' => 'tinymce.js',
     
'css' => 'tinymce.css',
    ),
  );
}

// Now to add TinyMCE's JS/CSS, you can do the following...
drupal_add_library('libraries', 'tinymce');
$form['myelement']['#attached'][] = array('libraries', 'tinymce');
?>

Comments

tstoeckler’s picture

The problem is that we can only register libraries that are installed. So we would have to detect all libraries in libraries_library(). That would currently be a performance hit, because we only cache libraries_load() currently.
Of course we could cache libraries_detect(), but I don't think that is necessary.
It is neither tested nor documented, but in theory we already support '#attached' anyway. So instead of your example, you can do:

<?php
/**
* Implement hook_libraries_info().
*/
function tinymce_libraries_info() {
 
$libraries['tinymce'] = array(
   
'files' => array(
     
'js' => 'tinymce.js',
     
'css' => 'tinymce.css',
    ),
  );
}

// Now to add TinyMCE's JS/CSS, you can do the following...
libraries_load('tinymce');
$form['myelement']['#attached']['libraries_load'][] = array('tinymce');
?>
sun’s picture

Status:Active» Postponed

Before attempting to do this, I want to see how generic something like this can be in the first place.

Based on the initial code for http://drupal.org/project/jquery, I somewhat doubt there's anything generic here.

Lastly, (I know I'm repeating myself ;) bear in mind that hook_library() is fundamentally different to Libraries API. The potential overlap with hook_library() only exists for 1:1 library-to-module relationships.

tstoeckler’s picture

Issue summary:View changes
Status:Postponed» Active

Re-opening based on #2167021: Revamp Libraries API integration

The important use-case that was not mentioned is declaring Libraries API libraries as dependencies of non-Libraries API libraries. I.e. if my mymodule.admin system library wants to depend on Backbone.js, which is registered with Libraries API.

rjacobs’s picture

I'm trying to relate some of this back to the recent related D8 core discussion in #2350877: Deprecate/rename drupal_add_feed(), drupal_add_html_head(), drupal_add_html_head_link(), drupal_add_http_header(), and allow to be set declaratively in #attached....

Lastly, (I know I'm repeating myself ;) bear in mind that hook_library() is fundamentally different to Libraries API. The potential overlap with hook_library() only exists for 1:1 library-to-module relationships.

I was wondering if someone could point me toward more clarification on that (it sounds like there is a separate conversation on this idea that I could reference)? I think I understand that implementing hook_library() (D7) and $module.libraries.yml (D8) only really makes sense for 1:1 relationships between 1 module and a library, but given that the job of libraries API is to allow multiple modules to leverage a common library installation, could this be a unique situation? Wouldn't it still be safe for Libraries API to implement that hook on behalf of (multiple) other modules given that it's still only one common library definition that's used (i.e. still 1:1 between the library and the Libraries API module)?

I might very well be missing something fundamental about that, but I'd still like to understand it better.

rjacobs’s picture

It looks like the related ref from core (D8) is now #2358727: Figure out what if anything libraries API needs for #attached support. Of course the reason for renewed interest in this issue, in addition to the point from #3, is that the pattern $form['myelement']['#attached']['libraries_load'][] = array('mylib'); is no longer possible in D8. Maybe this now needs to be marked as an issue against 8.x-3.x-dev with the potential for a backport?

Following-up on my comment above, I see that a 1:1 link between module and core library definition would be needed as each module declares its own unique files, etc. However, it would seem that Libraries API could accommodate for this by creating a separate core library definition per module. So if moduleA and moduleB declare the boomsauce library via hook_libraries(), but moudleA defines a boomsauce file that moduleB does not, the resulting core library definitions produced on their behalf could differ. I suppose this could open the possibility for load conflicts though, and for dependency management you still need some "canonical" form of a core library declaration, which may not be straightforward.

I'm also under the impression that the performance concerns from #1 are not issues in D8? It looks like the core library registrations are only altered/calculated during cache clears (as opposed to at load time).