I don't know if the 3rd party library we use is GPL'ed (even if it is not currently, you can ask the author to license it under GPL for you). That would allow you to ship the module's tarball with it included
There might be a time when you simply might not have enough time to maintain the module. If you used the Libraries API so that the external .js file could be placed under /sites/all/libraries, then it would be easier for end users to upgrade the js library to newer versions without having to "bother" you for a module upgrade too. Also, if one decides to hack the js file, they would still maintain their changes after successive module upgrades...
Using Libraries API (1.x) in your module to allow users to place libraries in the sites/all folder.
Thanx for considering this ;)
Comments
Comment #1
drurian commentedI don't think the plugin is maintained anymore, so I don't see the need to use Libraries API right now.
Comment #2
klonos...ok thanx for considering it anyways.
Comment #3
klonosOk, I'm re-opening this one. Two reasons:
1. Consistency: You already use the Libraries API for the imagesloaded plugin, so why not for Equal Heights as well?
2. Other modules (or themes) might require Equal Heights in the future. The reason Libraries API exists is for cases like these so that modules do not supply the same library twice. Reasons for that are multiple, including but not limited to:
- keep size of distributed modules down
- do not conflict with each other
- do not force users to download already existing libraries
- keep code neatly structured under /sites/all/libraries
So, could you please reconsider this one? Thanx in advance ;)
Comment #4
drurian commentedI'm just afraid the plugin may disappear from the developer's website at some point. Perhaps someone can create a github repo?
Comment #5
klonosYes, that might happen - just as you might at some time quit on Drupal and don't maintain the module any more.
So, how about this then: you ship the module with a certain version of the library (so you can provide an out-of-the-box UX), but still allow people to override the version that ships with the module by *supporting* (not *requiring*) the Libraries API module. In other words, give priority to
/sites/all/libraries/equalheights/jquery.equalheights.jsover/sites/all/modules/equalheights/jquery.equalheights.jsThis way, you also have the liberty to ship a specific version of the library along with the tarball ...though I find that unnecessary and bad practice for the reasons I've explained in the issue summary and #3.
Besides, equalHeights is really outdated (still in version 1.0 since 2008). The new official jQuery repository on the other hand is actually based on github as a backend* and there already exist:
- Equalizer (demo / github page) last updated Jan 18 2013
- equalize (demo / github) last updated Feb 2 2013
*from What Is Happening To The jQuery Plugins Site? (the short version) (posted December 8, 2011):
Comment #6
klonos...just food for thought: the equalize plugin mentioned above supports equalizing both widths and heights! So how about a new jQuery equalize project (the namespace is not reserved)? ;)
Comment #7
klonos...just in case it wasn't clear: what I mean with my posts is to say that even if equalHeights vanishes one day, we still have alternatives ;)