Hi, I' ve integrated the libraries api in the epub module, but I was wondering what' s the best way(if any) to make the update procedures to automatically move the libraries. I think hook_update() is not meant to deal with this kind of problem, but still I' d like to avoid to ask the user to do move things manually, because it could break the module' s functionalities in case it is note done. Have you got any suggestions?

Claudio Beatrice

What you could do to nudge users to move the library is show a warning message somewhere in the UI, but still support the old location. Then in the next release, you can remove the support for the old location.


If a module properly implements the D7 hook_library() or the D8 hook_library() and hook_library_info(), why would you need a Libaries API module?

I installed one module that did not work because of a bug in the Libraries API module. After posting on the issue queue, the answer was to use the Libraries 1.0 version. The problem was I had another module that was dependent on the Libraries 2.0 version.

Changing one line of code in each dependent module was all that was necesssary to eliminate the need for the Libraries API module.

I have also seen a case where a bug was reported and code was changed because adding the Libraries API module caused a problem -- a case of the tail wagging the dog.

A third party library can be in any number of locations /sites/all/libraries, <site>/libraries, <profile>/libraries or at some URL on a content delivery network (CDN). A proper hook_library() and hook_library_info() should be able to specify which library (and even version) to use. That is a responsibilty of the module developer and they should be given the ability to specify a library without having to battle with the quirks in the different versions and behaviors of a Libraries API module.

I have read the comments on this page and the child pages that follow. The Libraries API module is creating a lot of confusion and frustration.

Is this module really necessary?

The core hooks are for CSS/JS libraries (like jQuery UI) while the Libraries API covers more bases; such as a code library you won't/can't distribute with your modules but still rely on.

I'll concur that the name is confusing because there is the Core Drupal concept of a "library", and then there's the more general concept of a software library... and Libraries API is about the latter, not specifically the former.

TCPDF, for example, is a PDF generating class that you need to put somewhere so that it can be found via a call to include or require. Libraries API allows you to instruct someone to just plunk it into sites/all/libraries and now your module works. No instructions on how to configure a PHP include path, or how to find what yours is, or how to use PEAR to install a library. Most importantly; no distributing the TCPDF code (or any other code you haven't written) directly if you don't have to.

It is true that the use of PHP libraries with the Libraries module is not clearly documented for newbies, such as myself. I was trying to use it with the google-api-php-client to allow a site read-only access to a user's Google Drive and it took me a while to figure out that I needed to update the PHP include path. But once I figured it out, it just took two lines of code in my modules init() function:

  $glibpath = libraries_get_path('google-api-php-client');
  set_include_path(DRUPAL_ROOT . '/' . $glibpath . "/src/" . PATH_SEPARATOR . get_include_path());

Now the Google API PHP library loads properly. Thought this might be helpful to others trying to use PHP Libraries.