Libraries API allows the use of a central repository of libraries under ../sites/all/libraries
and this makes maintaining them easier. Plus you don't need to have the same library (in our case the same .js plugin) more than once in case two or more modules are using it.
If the user doesn't have the Libraries API module installed, then you can have it gracefully fall back to the old directory. I believe it is becoming more of a standard though (like cck and views), so most people will be installing it anyways I guess.
Thank you in advance for considering this.
PS: Thought I should list Libraries API's features here in order to support my case:
- The same library can be shared by more than one module.
- The same library can be shared by more than one site.
- Ease the process of upgrading a module that requires an external library. Just replace the module folder with the new one. No need to move the contained library out and back in.
- Preventing incompatibilities due to having the same library installed more than once in different versions.
- Central installation instructions (widget) to help users figure out how to install.
- Library classification.
- Handling of dependencies between libraries.
- Library version detection.
- Runtime control of library availability.
Comments
Comment #1
RobLoachIt might be easier to just pack jquery.js as part of the module itself...
Comment #2
klonosI know that this would be easier, but this way we would be missing the whole point of this feature request...
The point is that each time there is a library update, site developers that use a lot of modules that reuse the same library have to update the library in each module's folder. That is a painful process. The goal is to have a central place where one places all libraries and their future updates. Modules that require these libraries would all look in that central place and have the latest version available or multiple versions of the same library for debugging (once that feature gets implemented).
So, please keep this one active till it is fixed. If you mean to clean up the issue queue, then set it to 'postponed' till someone has the time to work on it, but please don't close it unless the feature has actually been implemented.
Thank you.
Comment #3
RobLoachIf we hold updated versions of jquery.js in the module itself, and you run a multisite install, then in order to update to the latest version of jQuery, all you have to do is update the jQuery Update module. If it's in sites/all/libraries, then you'd have to first update the jQuery Update module, as well as download the updated jquery.js into sites/all/libraries.
Another thing to note is that there are API differences between different versions of jQuery. jQuery 1.2.6 could not so easily be replaced with jQuery 1.3. The update to 1.4 is easier, but this is something to keep note of. Making the module in charge of this means we have control over what replacements come included with that update.
Don't get me wrong, I'm not completely dismissing the idea. If you send up a patch, we'd love to give it a look to see how things would work.
Comment #4
klonosThat's why I am suggesting to support ../sites/all/libraries, not to replace the current implementation with it. The title of the issue is not 'Remove the jquery.js that jQuery Update ships with'. This means that if it is detected (in other words if the Libraries API module is installed and enabled), then all jQuery Update module would do is help the site builder override Drupal's default jquery.js with the one in ../sites/all/libraries. Now, if the API is not installed, then jQuery Update could gracefully fall back to using the jquery.js it ships with.
As for the multisite case... two thoughts here: One is that in these cases there would be
../sites/all/libraries
../sites/site1/libraries
../sites/site2/libraries
etc. Second thought is that what you suggest as an upgrade path would force all sites to use the same version of jquery.js (the one that ships with jQuery Update). What about if people would want different versions of jquery.js for different sites in this multisite setup? Also what about if different versions of jquery.js would be required by different modules?
The Library API would take care of that! It will hold all libraries (including jquery) in one place and allow a per site global setting for which version to use. At the same time it will hold different versions of the same library so it will offer the option to override the version used in each module's settings page. This would also allow for easy troubleshooting, since if a module would behave funny after a library update, all the site builder would have to do is go to its settings page and override the version of the library used by reverting to a previous version or a debug version.
The whole point of using the Library API is to let it handle things like these. The ultimate goal is to stop shipping libraries with module releases unless they mean to override the default used by the site. Once #719896: Add a hook_libraries_info() is implemented, there even won't be a need for it either.
Do you see the potential in this?
I couldn't possibly get you wrong :) and I don't. I also understand that you aren't throwing this to the bin.
... you see most module maintainers hurry to mark their issues as fixed in order to clear their queue. Some of them don't even wait for a positive feedback after releasing a patch. They simply mark the issue as fixed. I really want this to have some love and if you marked it as 'fixed' or worse 'won't fix', people wouldn't see it in the queue.
As for the patch thing... I wish I knew more about drupal module developing and that I had some experience so I could help, but at the moment all I can do is throw some ideas on the table for others to pick up if they are up to it. I hope that this will change soon...
Bottom line is... please keep this in the queue to serve as a to-do in the list. Thank you so much.
Comment #5
mfer CreditAttribution: mfer commentedFor a lot of things the libraries api module makes sense. But, because the smallest point versions (1.2.3 vs 1.2.6) matter to the dependencies I think it would be a good idea to keep it in the module.
When we upgraded from 1.2.3 to 1.2.6 we had to make changes to farbtastic to not break core, for example.
Comment #6
klonosI am not going to argue any more on this one, since I've stated my case in #4 and my other posts. I know you cannot be in a million places at once and you seem to know better after all ;)
Perhaps when I am comfortable with coding drupal modules I can provide code for my own suggestions and then I might have some chances to see them get implemented.
Comment #7
lpalgarvio CreditAttribution: lpalgarvio commentedmy thoughts on this:
http://drupal.org/node/681034