I am consistently having some problems with 3rd party JS/CSS libraries, and I know I am not the only one, at CERN or elsewhere…
I noticed that there were already a couple of topics on these forums about this, that were more specific to certain libraries (for example this one: How can specific module libraries be installed?).
I want to discuss here a general solution, since unfortunately the suggested answers on these other posts were in the line of ‘hacking’ the modules so they look for the libraries in the right place, which I think we will agree should not be the way to go.
The one in red, but look also at the ones in : there are libraries missing for core modules as well…
My first idea was of course to upload this mmenu library to /libraries/mmenu. But we don’t have access to the root /libraries folder, since this is a multi-site Drupal installation and we are only admins on our sub-sites…
Problems
So I use /sites/my-site/libraries to put the libraries. But then, they aren’t detected.
It turns out we have two problems:
Most of these modules expect these libraries to be in /sites/all/libraries to which of course developers don’t have access — nor should we have. Some modules are not even making a correct use of the Libraries API, hardcoding the expected paths, etc.
The Libraries API for Drupal 8 is absolutely disastrous… they lack proper documentation, and most functions used by these modules are —or will be— deprecated soon. It’s difficult to know which modules are doing the right thing and which ones aren’t.
I am looking forward to come up with a recommended approach that makes use of Libraries API in the most future-proof way, if possible without needing to hack the 3rd party modules (maybe a CERN community module that can intercept or override libraries loading to inject the sub-sites on the path?)
Wow, it’s a bigger issue than I understood at first. Thanks for the thorough report!
My first reaction is however to notice that we are looking at a single-site solution for the central CERN infrastructure, based on containers, in the general timeframe of Q4 2020. In the new infrastructure every site will be isolated.
Given this timeframe, do “hacky” solutions sound maybe less unappeasing?
I understand there is no community solution yet to this problem —which blows my mind, honestly— so we need to hack things up. I can live with a hack here and there, of course, but it would be nice to know the right way to do this, if there is a right way.
Do you have an example of the proper implementation of library loading using Libraries API 3.0 on a multi-site installation? I guess it cannot be that hard!
In the meantime I will hack the Responsive Menu module or implement my own responsive menu if I have the time
PS: By the way, the Libraries UI module fails on CERN Drupal installations due to the CERN Landing Page module probably having bugs (edit: or triggering a bug) in the Locale module’s locale_library_info_alter hook: https://test-procurement-d8.web.cern.ch/admin/config/media/libraries_ui
Certainly for people like me, used to the functionality of the Drupal 7 Libraries API module, the new version on Drupal 8 is really complex and very difficult to setup. Also the objective of the module seems a bit different, now more focus on making the library load more flexible in terms of versions or sharing libraries between multiple contrib modules, not really on storing the libraries on a different path for multisite environments.
Unlike the Drupal 7 version where you just need to enable the module and put the libraries under your /site/mysite.web.cern.ch/libraries/ folder, the Drupal 8 version works as a framework that requires extra modules to implement, a library registry file to generate, and some config.
I’ve looked around and seen this solution explained by someone as an alternative to the Libraries API.
Basically the workaround is based on creating a custom module that will re-define parts of the libraries loaded by your module and rewrite the paths to point to the site’s libraries directory.
I just tested it and seems to work. I must advise it requires some trial and error to find out the exact values to override…
Here the example site, https://test-edu-after-pass.web.cern.ch/, where clicking on “Menu” will load the responsive menu provided by the module out of the box.
The module code looks like load_libraries.module
<?php
function load_libraries_library_info_alter(&$libraries, $extension) {
// Enable the next lines to check values to modify, clear caches once done since libraries are
// only loaded once and then cached.
//dpm($libraries, "libraries");
//dpm($extension, "extension");
// Update path for the desired library
if ($extension == 'responsive_menu' && isset($libraries['responsive_menu.mmenu'])) {
$new_path_js = array();
$new_path_css = array();
$base_path = \Drupal::service('site.path');
$new_path_js["/$base_path/libraries/mmenu/dist/mmenu.js"] = array();
//dpm($new_path_js, "new path js");
$libraries['responsive_menu.mmenu']['js'] = $new_path_js;
$new_path_css["/$base_path/libraries/mmenu/dist/mmenu.css"] = array();
//dpm($new_path_css, "new path css");
$libraries['responsive_menu.mmenu']['css']['theme'] = $new_path_css;
}
}
Now, is this a good solution? not sure about that. But if someone arrives to this issue, might want to try this option.
PS: I disabled CERN theme on purpose on the test site, since there is some layout issue with this module and CERN theme that probably requires some tweak but I wanted to focus on the issue discussed on this topic and not Theme details.
thanks a lot for your help and idea. I guess this is a nice workaround, since it can also be tweaked to be dynamic so it can work with any module using the library_info hook expecting libraries to be in the Drupal root folder.
I might try your method and post the results here if I can make it work in a more generic way
In the end, for this particular module I found out it has problems when used with the CERN Theme as you pointed out (basically it makes the main menu disappear, amongst other things), so I went for a different module instead: Superfish https://www.drupal.org/project/superfish (a classic!) which has a nice port for Drupal 8.
Of course this module also requires libraries (Superfish JS and jQuery easing) and I had to hack it as well, but it doesn’t clash so much with the CERN Theme’s menus. Just in case anyone is in the same situation
I tried to add the extensions in the library folder I could find on my site webdav folder.
As I read the message from @ogomezal, I should put these libraries in /sites/all/libraries which I cannot access (or do not know how to access). I just followed the explanations here (Cyberduck, Windows).
How to even access that folder?
The Webform module works, but the huge warnings list (16 items) and the fact that I do not know Drupal that much (I would prefer Wordpress) bothers me a bit. I’m afraid that somedays it breaks and no one in my team will know what to do.
I’m in HR-LD so spending a lot of time in web development is not really on my tasklist (I wouldn’t mind though). I have the feeling that given my role, I have many access and folders that are completely out of reach…
I do not know how to access the Webforms folder to use the solution you proposed here…
…since I can’t even access the Webforms folder (I only have the modules I tried to install in the module folders).
I also see the possibility to use Drush, but I don’t even know how to SSH to my website’s folder. I have putty, but what is the host? my_website.web.cern.ch is not the solution and I guess there is a well kept secret around the host address…
To run Drush you have specific instructions for your site by visiting the admin panel:
https://<your-site>.web.cern.ch/_site/drush.php
However keep in mind that we are allowed to use Drush only in test websites, so if it’s not the case, you can actually:
register a new test Drupal 8 site,
clone from your site to this new test site, and
perform your Drush fix on it.
When you are done, you can just clone back from test to production.
It’s not ideal, but it’s a workflow that saved my day more than once
PS: Sometimes you can just create the libraries folder on your site’s root folder (after mapping it as a network drive in Windows or mounting it as WebDav in *nix systems), and the module will just workTM.
If it’s not the case, you can also hack the modules so they look for libraries on a folder of your own choosing. I did this for some modules, and just added the libraries inside the module’s folder (<site-root>/modules/<offending-module>/libraries/<library-folder>). But it’s bad practice and a last resort, since it’s absolutely not maintainable or future proof.
Thank you, this helps to better grasp the thing. Future proof is definitely a thing to keep in mind as the website will live longer than my CERN contract
The one in red, but look also at the ones in 
: there are libraries missing for core modules as well…
