Add support for Libraries API

Thanks for looking into this Jorrit! I appreciate you implementing hook_libraries_info(). Hopefully in future releases of Libraries we can leverage all the meta data you provided to make it easier to download those assets.

I apologize about #2, that was something I overlooked about Libraries 6.x-1.x. However, there /is/ still a need to use its API to discover the location of external assets. I entirely agree with you about not forcing a dependency; using "function_exist" is a great way to basically say "It's nice to have if available, but not a requirement." Several grade-A contrib modules already use this approach to make them more adaptable to the environments they are used in (for instance, in my case where I'm developing for a multi-site installation, and I don't have access to either "sites/all" or even know the name of the subdirectory the multisite will be hosted in – this is currently not deployable without this patch.)

I hope you'll reconsider adding this to VideoJS. I re-rolled the patch from #1 with the added corrections. This patch will be for the 6.x-1.x branch, and I will eventually post a patch against 6.x-2.x as well.

Please disregard the previous patch in #5. This is an updated patch that should be applied to 6.x-1.x. The process of deriving a path has been abstracted to videojs_get_path() and is replacing most instances of variable_get('videojs_directory');

Here is a patch for the 6.x-2.x branch.

Ah, that is a valid point. That makes sense in the rare case when two copies of the library are on the site, (sites/all/libraries might contain version 2, while sites/{site_name}/libraries can contain version 3) -- and reversing the preference in videojs_get_path() allows the configuration to override the Libraries API fallback.

Thanks for committing that!

Edit: double post.

Hey Jorrit, I just noticed that the code you committed had a typo that causes this feature to fail :\

module_exists('libraries_get_path');

should be

module_exists('libraries');

or

function_exists('libraries_get_path');

Also, the concept we mentioned in #8 and #10 doesn't actually currently work the way we expect it to. VideoJS still takes precedence of sites/all over multi-site installations. Libraries API can figure out the correct order of preference, and we can still have the path overridable by the user, all it takes is a little bit of rearranging in videojs_get_path(). I'll post a patch against 6.x-2.x soon.

Also added a checkbox to reset the configured path if the user wants the system to just figure it out.

function videojs_get_path() {
  // Default directory path.
  $directory = 'sites/all/libraries/video-js';

  // Libraries API integration - In case VideoJS library is in multiple
  // locations (profiles/{profile_name}/libraries, sites/all/libraries,
  // sites{site_name}/libraries ) Libraries API can determine which copy should
  // take presidence...
  if (module_exists('libraries') && $libraries_dir = libraries_get_path('video-js')) {
    if (file_exists($libraries_dir . '/video.js')) {
      $directory = $libraries_dir;
    }
  }

  // ...However, we also give the user the opportunity to override the path.
  if ($conf_dir = variable_get('videojs_directory', NULL)) {
    if (file_exists($conf_dir . '/video.js')) {
      $directory = $conf_dir;
    }
  }

  return $directory;
}

In videojs_get_path() the $directory variable is altered from lowest priority to highest:

It starts with the default path "sites/all/libraries/video-js";
Then, if the Libraries API is available it will discover paths that /actually/ exist and reassign $directory;
Finally we check if the user had in fact configured the "videojs_directory" setting, and use that path over any previous discovered path.

Previously, "sites/all/libraries" was taking preference over Libraries API paths, which is incorrect. The idea is to use the most specific library path available, but still let the user configure a custom path, if they choose.

Order of library path specificity should be:
profiles/{profile_name}/libraries
sites/all/libraries
sites/{site_name}/libraries
** path/to/user/defined/directory **

Once the "videojs_directory" setting is configured however, Library API paths are ignored completely. That's why I added a checkbox to "reset" the variable so the system can continue to decide what path is best.

Re-rolling patch to accommodate for recent changes in 6.x-2.x

Yea, I know what you mean. I've ran into that also, but felt it was just a bit out of scope to what this issue is addressing. I can solve that "UI wtf" by splitting up the configuration into a different local task. Like this..?

With this patch I am now finally able to use it with multi-site installations (where access to sites/all is not an option), as well as install profiles. I think I have pretty much addressed all of your concerns in a fair amount of detail -- what direction do you want to go with this issue Jorrit?