I have some files in a libraries/ directory in the Backdrop root for various modules. I see that the Libraries module is deprecated, but there doesn't seem to be an equivalent of libraries_get_path() now. Is that common libraries/ directory also deprecated now?

Most helpful answers

Ah, I think I understand what you're asking now...

Yes, the Libraries module and the /libraries directory are deprecated. Modules that used to have a dependency on the Libraries module should now include the third-party library in their code (as you saw Views Slideshow Cycle2 does) and implement core's library hooks to define, call and load the library.

For users, this means no more having to download libraries separately. Everything for a module just works out-of-the-box.

See the README here for more information about converting from the Libraries module to core's library API hooks.

It depends on the modules those libraries are for. Modules should bundle libraries with them now, so check each library to see if its module includes it now (you might need to update to a more-recent version). If so, you can delete that library from your 'libraries' directory. If not, you'll need to leave it there for now, and I suggest filing an issue asking the module to bundle the library in future.

I can't test on my phone, but does backdrop_get_library() work for getting the path of a library?

Comments

It depends on the modules those libraries are for. Modules should bundle libraries with them now, so check each library to see if its module includes it now (you might need to update to a more-recent version). If so, you can delete that library from your 'libraries' directory. If not, you'll need to leave it there for now, and I suggest filing an issue asking the module to bundle the library in future.

I can't test on my phone, but does backdrop_get_library() work for getting the path of a library?

The specific 'js' and 'css' entries in the library info look like they are supposed to be complete paths - the arguments for backdrop_add_js() / backdrop_add_cs(). So there's no general concept of a library directory, as far as I can tell.

This came up as I was trying to remove the dependency on Libraries from the Expander (jquery_expander) module. I ended up doing what you describe - moving the plugin file into a 'library' directory in the module itself. It looks like other modules like views_slideshow_cycle2 have done something similar.

Ah, I think I understand what you're asking now...

Yes, the Libraries module and the /libraries directory are deprecated. Modules that used to have a dependency on the Libraries module should now include the third-party library in their code (as you saw Views Slideshow Cycle2 does) and implement core's library hooks to define, call and load the library.

For users, this means no more having to download libraries separately. Everything for a module just works out-of-the-box.

See the README here for more information about converting from the Libraries module to core's library API hooks.

klonos's picture

What @BWPanda said @brad.bulger ...all that, plus the folder that will hold the 3rd party library within the module should have the name of that library So:

  • instead of the generic /library directory you said you ended up using, the directory name should be /jquery_expander.
  • that folder should be at the top level of your module folder structure (not inside a /library folder).
  • If you need to include more 3rd party libraries, then each library should have its own folder, by its name, at the top level of the module folder (not inside a /libraries folder).

I hope that all that is clear. Please let us know if you need further help with this or anything else.

Hello everyone,

I am seeking clarification regarding how a library that a module is dependent upon should be organized in a particular module.

For example, if you have a library called "weather" and your module is named "headache_buddy", is it the Backdrop CMS standard to put weather at the top level of the module or is it just a preference? For the organization I work for, it makes more sense to organize the library into a "Libraries" folder in the event your module may rely on more than one library. It's cleaner and is more organized.

headache_buddy/libraries/weather

VERSUS

headache_buddy/weather

Thank you and cheers!

 

So to get a bit literal as usual, in this case, the repository for the plugin is https://github.com/kswedberg/jquery-expander and the plugin itself is jquery.expander.js. The old expectation of the module was to find a libraries directory named 'jquery.expander'. So I guess either that or 'jquery-expander' to match the source?

I used library/ because I saw a variety of cases in the modules using what I had in the old libraries/ folder: libraries/, library/, cycle2/. I appreciate the clear standard.