The filedepot interface doesn't appear

Before this issue is changed to fixed once again...

I too had the same problem. So have many others -- see here or here or here. Going by the posting dates of the comments on these links, this problem has been festering for months. I develop with a Win7 WAMP stack (multisite) and I suspect most others having the same problem are using a similar config.

There are two bugs at play here, one in the Libraries API module, the other in the filedepot.module file. Before I give my solutions, I'm going to vent a bit.

The current Filedepot page makes no mention of the quirky installation (cut and pasting web page output to a textfile in a libraries directory? - how convenient!) or even where the main page is (/filedepot). If a site theme does not make use of the Navigation menu (where the /filedepot link appears), then the only way this becomes apparent is if you switch to a default theme and the Navigation menu is in a sidebar. I looked at the filedepot_menu() code to discover that there was a /filedepot link -- which then rendered a blank page. WTF?

Yes, I read the readme file; carefully; several times. It did help to trace the problem. jQuery.blockui() does not exist on the blank page. Look at the page source (ctrl+U) and you can see that the jQuery.blockui.js filename never appears in the header (the js load after common.js).

There are two lines in the filedepot.module that are rubbish need to be corrected (around line 600, depending on the release):

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

Maybe this used to work; maybe it still does for linux or drush; we're not sure. Change the 2 lines to something like:

  drupal_add_js('/sites/all/libraries/jquery.blockui.js');
  drupal_add_js('/sites/all/libraries/encoder.js');

and /filedepot should appear, providing that you have previously followed the instructions regarding the js files in the readme file.

Another possibility is the following:

  drupal_add_js('http://bainternet-js-cdn.googlecode.com/svn/trunk/js/jQuery%20BlockUI%20Plugin‌​/‌2.39/jquery.blockUI.js');
  drupal_add_js('http://www.strictly-software.com/scripts/downloads/encoder.js');

Then you don't even have to worry about the libraries or even looking at the readme file. BTW, the first link above is from a Content Delivery Network (CDN) that I found here.

The idea of having to install a module (Libraries API) to use a common library is just weird to my way of thinking. There was also a problem with the latest version of the Libraries API module, which compounded the problem of problem discovery. I'll document that as a Libraries API issue.

In the meantime, the Libraries API module is not needed (methinks). You can get rid of the dependency by commenting out the appropriate line in the filedepot.info file. i.e.

;dependencies[] = libraries

IMHO, the libraries API module needs some work.

-Dio

PS - Set the private file system to /sites/default/files/private (or whatever). Although this directory is within the base_url dir tree, an .htaccess will be created to limit access. It does not have to be located outside of the htdocs tree for security purposes (as indicated in the filedepot README file). See http://drupal.org/documentation/modules/file

Oops - spelling mistake in title -- corrected.

Some caution should be used when reading and following the post above from @diogenes. The current version of filedepot uses the libraries 1.x version of the API module as the 2.x branch only recently had a final release and was still evolving when our D7 port of the filedepot module was done so only 1.x version of the libraries module is currently supported.

We do not recommend that you hard code the library paths in the drupal_add_js function. Most of our development and testing has been done on a windows 7 environment and these issues were not experienced.

It's our recommendation that your filedepot private root folder be located outside the public web folder. If you read the D7 filesystem config documentation at: http://drupal.org/documentation/modules/file, you will see there are several potential security issues and concerns noted that need to be carefully checked and followed to prevent unauthorized access.

I had the same issue btw,
I solved the issue quite similarly as @diogenes

1. Created a folder named "filedepot" in the libraries folder, and moved the two JS files there
2. updated the lines in the filedepot.module
drupal_add_js(libraries_get_path('filedepot').'/jquery.blockui.js');
drupal_add_js(libraries_get_path('filedepot').'/html_encoder.js');

After these changes it loads perfectly.

@gaborpeter, my reasoning for not creating a folder under libraries called 'filedepot' was to not make these libraries specific only to the filedepot module. It also adds yet another manual step to create that folder. You should not have needed to modify the drupal_add_js statements if the js files where in sites/all/libraries where the libraries module is expecting them.

@blainelang

The current version of filedepot uses the libraries 1.x version of the API module

Then maybe you should mention that somewhere in your documentation!

The Libraries 7.x-1.0 version is dated Jan 27. The first time the blank screen issue appeared was Feb 5.

You could have changed 2 lines of code to make use of the 7.x-2.0 Libraries. Or better yet, you could make use of the hook_library() and drupal_add_library() functions and do away with the libraries API dependency altogether.

But NO! It's not a problem is it? The current filedepot is wonderful. If one spends enough time going through all the closed issues here, one will eventually discover that you need an old version of the Libraries API.

It comes as no surprise that you have re-tagged this as closed (works as designed). You have done it before.

I won't argue here. There is no point in arguing with someone who has fallen in love with his own code.

But thanks for wasting 6 hours of my life that I'll never get back.

Version 2 of the libraries module is now supported.
Please see http://drupal.org/node/1757698#comment-6401596