Drupal Association members fund grants that make connections all over the world.
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:
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.