_drupal_add_js()/css() removed from core

Yeah, we have to completely refactor Libraries API to work with more modern concepts...

Basically we need some plugin mechanism for libraries and then for JS and CSS libraries we need to translate those into system libraries (*.libraries.yml).

We can now dynamically define libraries via hook_library_info_build(). https://www.drupal.org/node/2374649

The issue I ran into with *.libraries.yml is that the 'base' path for the css and js is the module's directory which makes it's difficult to include css and js in an outside directory like in the /libraries directory.

Might be able to use hook_css_alter and hook_js_alter to fix the 'base' paths.

@jrockowitz: Wow, I need to look into that. If it's not possible to avoid that base path, then we need to add a core task for that. That is definitely required for Libraries API to make any sense in D8. Thanks for pointing that out, I wasn't aware!

Hi,

Is the following error due to the above mentioned issue?

Warning: call_user_func() expects parameter 1 to be a valid callback, function '_drupal_add_js' not found or invalid function name in libraries_load_files() (line 687 of C:\Users\Hp\Sites\devdesktop\drupalbangalore-dev\docroot\modules\libraries\libraries.module).

Thanks!
Jaya

Yes, Libraries API is currently completely broken in Drupal 8 because of this, unfortunately. There are plans to improve the situation, but I still need to carve out some time to actually implement them, so there's no concrete timeplan as of yet. Sorry!

I think this is a dup of #2183087: Find a way around _drupal_add_js/css, or either that is a dup of this. Either way one of them should probably be closed (though I'm really not sure which). It sounds like we need an issue to serve as the master reference for the process of adapting Libraries API to work with dynamic core library definitions. Should this be that issue? Note that we also have #2358981: Provide a mechanism for dynamic library declarations.

I just figure that it might be a bit easier for everyone to follow along if we consolidate some of the items in the queues a bit, or setup a parent issue and link these to it.

My very dirty workaround was to comment out all libraries_load() calls and then use the below code snippet to load my module's libraries on every page.

Hope this helps someone.

/******************************************************************************/
// WORKAROUND: Libraries module is broken. https://www.drupal.org/node/2418907
/******************************************************************************/

/**
 * Implements hook_css_alter().
 */
function mymodule_css_alter(&$css) {
  $libraries = mymodule_libraries_info();
  foreach ($libraries as $library) {
    if (isset($library['files']['css'])) {
      foreach ($library['files']['css'] as $library_css) {
        $library_path = (isset($library['library path'])) ? $library['library path'] : 'libraries/' . $library['name'];
        $basename = basename($library_css);
        $css[$basename] = array(
          'data' => "$library_path/$library_css",
          'basename' => $basename,
          'type' => 'file',
          'group' => CSS_AGGREGATE_DEFAULT,
          'weight' => 0,
          'every_page' => FALSE,
          'media' => 'all',
          'preprocess' => TRUE,
          'browsers' => array(
            'IE' => TRUE,
            '!IE' => TRUE,
          ),
        );
      }
    }
  }
}

/**
 * Implements hook_js_alter().
 */
function mymodule_js_alter(&$javascript) {
  $weight = 0;
  $libraries = mymodule_libraries_info();
  foreach ($libraries as $library) {
    if (isset($library['files']['js'])) {
      $library_path = (isset($library['library path'])) ? $library['library path'] : 'libraries/' . $library['name'];
      foreach ($library['files']['js'] as $library_js) {
        $filepath = "$library_path/$library_js";
        $javascript[$filepath] = array(
            'group' => 50,
            'weight' => $weight++,
            'scope' => 'footer',
          ) + drupal_js_defaults($filepath);
      }
    }
  }
}

Libraries API at first sight seem to be really important for third party module developers to start working on their Drupal8 modules.
But due to the introduction of .libraries.yml file in Drupal8.. I just wonder is this still relevant?
Or maybe we should revise Libraries API to get it along with .libraries.yml and alter the way we use hook_libraries_info?
Or should someone revise what are documented in https://www.drupal.org/node/2170763?

For side information:
Due to the lack of recent update in this module for latest Drupal 8 beta-9
I have to introduce my own way of centralization third party javascript.
And return #attach from hook_preprocess_page(&$variables) to load the javascript I defined in center .libraries.yml
I found it pretty convenience though.

I am not sure this patch is appropriate as it is basically including ALL libraries (using libraries_get_libraries()) on ALL pages.

As a developer, I am expecting to use the Library API to "simulate" a libraries.yml when I don't want to include third party in my code. For example:

function MYMODULE_libraries_info() {
  $libraries = array();

  $libraries['jquery.cycle'] = array(
    'name' => 'Jquery Cycle',
    'vendor url' => 'http://malsup.github.io/',
    'download url' => 'http://malsup.github.io/jquery.cycle.all.js',
    'version arguments' => array(
      'file' => 'jquery.cycle.all.js',
      'pattern' => '@(?i:Version:)\s?([3\.a-z]+)@',
      'lines' => 5,
    ),
    'files' => array(
      'js' => array(
        'jquery.cycle.all.js',
      ),
    ),
  );

  return $libraries;
}

and then

  $output['#attached']['library'][] = 'MYMODULE/jquery.cycle';

At some point the Library API module should browse the #attached array to find any library defined in a hook_libraries_info() implementation and then attach appropriate js/css.

Maybe I missed something in core functionalities but it seems not possible to do it for now. As said by vorapoap, I am not it is relevant to do it in Library API and it may be better to have it in core.

I finally realized that D8 does support root-relative paths within *.libraries.yml

Below is an example of my jQuery Chosen config

# jQuery Choosen - http://harvesthq.github.io/chosen/
libraries.jquery.chosen:
  version: 1.1.0
  css:
    component:
      /libraries/jquery.chosen/chosen.css: {}
  js:
    /libraries/jquery.chosen/chosen.jquery.js: {}
  dependencies:
    - core/jquery

I am attaching this library using...

$output['#attached']['library'][] = 'MYMODULE/libraries.jquery.chosen';

BTW, you don't have to use the libraries.* prefix. I just felt it helps developers understand what is being attached to the $output.

This is definitely a poorman's implementation of the libraries.module but it works.

My main concern was about "optional" library. If the user want to use some advanced features of my module, I could download a third party library and it should provide him advanced settings.

I finally define these optional libraries in *.libraries.yml file and expect the library being placed by the developer in the /libraries directory.

Then before displaying the advanced settings form, I check if the expected files have been placed in /libraries:

    $hoverIntent = \Drupal::service('library.discovery')->getLibraryByName('my_module', 'jquery_hoverIntent');
    if (isset($hoverIntent['js'][0]['data']) && file_exists($hoverIntent['js'][0]['data'])) {
      $vars['#attached']['library'][] = 'my_module/jquery_hoverIntent';
    }

I don't know if it is the right way to deal with optional third party library but it works.

@vbouchet: In fact the core library system will work fine with an non-existing library, so that just calling

$vars['#attached']['library'][] = 'my_module/jquery_hoverIntent';

unconditionally will work fine as well, and will provide the same "optional" integration.

Marking postponed on #2090623: Turn hardcoded library_load_files() into a more modern, flexible system for now. Working on a basic implementation now.

Thanks for your feedback @tstoeckler, I don't even thought about it. Will update my code.

I'm thinking that is might be time to close this in the interest of housekeeping. It's been established in other issues (e.g. #1386368: Register Libraries in hook_library()) that it'll be compulsory to leverage core's own library handling for asset loading, and some work to make it happen is underway (in #2090623: Turn hardcoded library_load_files() into a more modern, flexible system).

There are possibly some useful notes above on "workarounds" for the current/incomplete state of 8.x-3.x, though I wonder if there is anything that still needs to be addressed here which has not already been picked-up elsewhere? At this point my thinking is that it could be best to close this is direct attention to #2090623: Turn hardcoded library_load_files() into a more modern, flexible system

The master port issues (though still very much drafty) may also be useful for context: #1704734: [master] Libraries API 8.x-3.x.

In the interest of housekeeping I'll go ahead and close this. Marking as dup of #2090623: Turn hardcoded library_load_files() into a more modern, flexible system.

Is there any guide for porting modules that were using Libraries before the architectural change to use this new architecture? I'm trying to use the Font Awesome module, but it seems to use the old architecture, which (as of the 8.x-3.x-dev branch today) is still calling the nonexistent _drupal_add_js() and _drupal_add_css() functions.

I'd like to help that module (and some others) port to the new architecture so they can at least work, but after reading through #1704734: [master] Libraries API 8.x-3.x and a few others, it's getting a little confusing...

#20
indeed, the state of the Libraries Api is confused and incomplete.

some key links:

• Best practices for handling external libraries in Drupal 8
• Adding stylesheets (CSS) and JavaScript (JS) to a Drupal 8 theme
• Using Libraries API 8.x-3.x (as a module-developer) -- note: current d.org documentation changes have messed this page up a lot

Myself, as i've been working with 8 i've found moving away from the Libraries API easier.. Finding other modules that are simply declaring libraries through it's own .yml file is more ideal. hopefully, #1167496: Libraries API in core will have more motion on it sooner than later.

Is there any guide for porting modules that were using Libraries before the architectural change to use this new architecture?

There is now :) ... at least I've been working on the basic structure for one:

https://www.drupal.org/node/2170763

I'd like to help that module (and some others) port to the new architecture so they can at least work

That would be fantastic. Documentation has been lacking for sure, and I've been trying to chip away at that. The API itself is of course still a work in progress as we don't yet have a tagged release, but I think (hope) that enough of a foundation is in place for testing with basic use cases. I had a look at Font Awesome and I don't think it would be that difficult to update it for the new API. I think the bottom line is that we need to start validating assumptions and seeing how things work in real use cases in parallel to finalizing and stabilizing the module. If you have questions please let me know and I'll do what I can. In the interest of transparency I should re-state that we still have some critical open issues holing up a tagged release, but the new D8 concepts we are shooting for are finally taking on a useable form now.

Myself, as i've been working with 8 i've found moving away from the Libraries API easier

Libraries API is certainly not needed for all library management use cases, but it still aims to fill a gap in core support for shared external libraries. Hopefully the notes in the "Why Use Libraries API in Drupal 8?" section on this page will be helpful.

hopefully, #1167496: Libraries API in core will have more motion on it sooner than later.

I don't think that effort is mutually exclusive. While I don't personally have insights into all the history discussed in that issue I think that Libraries API for D8+ will need to be proved and refined in contrib before it can be realistically explored as a core addition.