Installed filedepot 7.x with libraries 7.x-2.0. The main filedepot page was blank owing to a js file not loading properly. One solution was to use an older version of the libraries module.

The problem was in the following 2 lines of filedepot.module code:

  drupal_add_js(libraries_get_path('jquery.blockui.js'));
  drupal_add_js(libraries_get_path('html_encoder.js'));

I realize this syntax is probably wrong -- the argument should be something like:

  libraries_get_path() . '/html_encoder.js'

but libraries_get_path() did not return /sites/all/libraries as expected. It returned an empty string.

libraries_get_path() is a drupal_static function. The first time it fires the $name argument that is passed is FirePHPCore.

WTF? A findstr (grep) for 'FirePHPCore' reveals only 2 files on this dev platform have this string: devel.module and devel.drush.inc

So I am putting forth a theory that the Libraries API module is drush dependent. The documentation should say so if this is the case.

I'm astounded that this module is used on over 178,000 sites. This was the first time I have needed to use it and it failed spectacularly. And I am still having a hard time getting my head around why it should be necessary to install a module to use a library. It's like installing an elevator for old modules that refuse to climb the new stairs.

The latest filedepot issue was first reported over 5 months ago. If this is a Win only issue (and I suspect it is) then it points to a weakness in this open source model.

Comments

Priority:Major» Normal

This looks like a problem with filedepot not using the API correctly making it break with any version other than Libraries 1.x, not a problem with Libraries API.

As there are multiple filedepot issues (and at least one suggested fix #1734828: Explicitly declare libraries 1.x dependency), IMO this can be closed.

Good job rock...

The fix is one line; better than two (like mine), and I didn't know that one could specify a dependency version in the .info file. Ain't Drupal amazin'?

Maybe you can explain the use case for the Libraries API when the Drupal 7 library hooks have been properly implemented in a D7 module? I'm getting old and was never the sharpest knife in the kitchen, but the way I see it, this module should be a D6 module and D6 only.

-Dio

Issue summary:View changes

added target attr to

Libraries is just a way to reuse code. A module can use library hooks to document the dependency on external code, and load it from a common place on the server.

The big difference between the library hooks in Drupal 7 core, and this Libraries API module is the support for external libraries. In core, you can only specify that a library exists in your module, and it's available for anyone to use if they wish. This is why other modules can load jQuery UI components, because it's in core and available via hook_library().

Some libraries aren't GPL compatible so they cannot be hosted on Drupal.org and requires the end user (module installer) to go download them manually. By storing these in sites/all/libraries you get a common location for external libraries.

Filedepot is using the Libraries API module hooks incorrectly, causing the problem. Used correctly, the changes in Libraries API 2.x would have been backwards compatible and filedepot wouldn't have broke.

Current:

drupal_add_js(libraries_get_path('jquery.blockui.js'));
drupal_add_js(libraries_get_path('html_encoder.js'));

Correct:

drupal_add_js(libraries_get_path('jquery.blockui') . '/jquery.blockui.js');
drupal_add_js(libraries_get_path('html_encoder') . '/html_encoder.js');

I know what libraries are for. I've been doing this shit for too many years. My dev system is a multi-site WAMP stack with the latest versions of D6, D7 and D8. I can set it up so I have two different sites with different versions of the same 3rd party library if necessary. My production sites run on a linux shared server. This can be a challenge at times. I get by.

I know it's not a great idea to specify /sites/all/libraries in code because Drupal has done a pretty good job to accommodate multi-site development. And if a D7/D8 module properly implements the Drupal library hooks (available D7 & D8 only), drupal_add_library() should handle the sites//libraries discovery process without any need for another goddamn module.

So my point is there is no point to a Library API module if the module is done right. Please correct me if I am wrong.

-Dio

IMO, Libraries API does fill a need because core implementation does not work well for libraries that must be downloaded separately from the module. Like any other API module (entity, voting_api, ctools) it is entirely optional for a module developer to require it.

Core library implementation has no special consideration for the sites/*/libraries folder. drupal_add_library() only works with libraries declared using hook_library(), where the path to the library is set (hardcoded). If you have many modules that use the same external library, how do you chose which of those modules should implement hook_library()?

The Libraries API module will automatically search in sites/*/libraries. You can have 2 or 3 modules that all call drupal_add_js(libraries_get_path('html_encoder') . '/html_encoder.js'); and none of them have to implement hook_library().

I'm confused here. If every module that required a certain library implemented hook_library() and drupal_add_library(), what would be the circumstances or case be where the Libraries API is needed?

And why do you need to choose which module implements hook_library(). Is there a problem if they all do?

Category:bug» support
Status:Active» Closed (fixed)

@Diogenes, contrib modules should rarely implement hook_library(). That hook is for libraries that you ship with yourself. An example is the core tabledrag library. If you were to write something like that you could use hook_library(). Libaries API is for libraries that are developed externally.

Also, if you do not want to use Libraries API, because you think it is unnecessary, then please don't waste everyone's time by posting here. Thanks!

@tstoeckler

contrib modules should rarely implement hook_library().

Really? I am going to disagree on that point. Please provide any links that might enlighten me. D6 didn't have hook_library() so maybe there was a need for a Library API, but not in D7.

If filedepot had properly implemented hook_library(), there would be no need for Libraries API and it would have worked fine. I raised a flag and provided a fix for an issue that has been kicking around around for 7 months. Then a new release of filedepot appears that specifies a dependency for an old Libraries API version. Brilliant! Works as designed. I didn't know Rube Goldberg taught software design.

And I'm wasting everyone's time?

Thanks.

And I'm wasting everyone's time?

Since you're asking so bluntly, I dare to answer likewise: Yes, sort of.

Please read http://drupal.org/node/1342220 for the difference between hook_library() (core D7) and hook_libraries_info() (Libraries API 2.x). The essential difference is that the latter is for *external* libraries (jQuery, any jQuery plugin, CSS grid frameworks, Symfony components,...).
I see no purpose discussing the usefulness of this module. If you find it useless, justly or unjustly, don't use it and be done with it.
kthxbye

(btw: I stumbled on this issue by accident, because it is marked fixed. If you post a reply here, do not expect me or anyone else to read it. Only if you re-open this issue it will become visible again. In this case I strongly advise you not to do that, though.)

Issue summary:View changes

oops - small change to code