Feel free to ignore this, but it seems like implementing the Libraries API might be helpful for this module, since it implements an external library (http://timeago.yarp.com/jquery.timeago.js).
Context: I was recently messing around with my site, and downloaded the the dev version of timeago to overwrite the old version I had installed. Got distracted with other issues, then discovered that something weird was going on with javascript on my site, and timeago didn't seem to be working correctly. Well, I had completely forgotten about the external library requirements of the module, and that I needed to download http://timeago.yarp.com/jquery.timeago.js again and put it in the module folder. That fixed things. But since I was dealing with a bunch of issues, and a complex site, and had installed this module so long ago, it took me a bit longer that it should have to realize the problem. Which I think is the point of the Libraries API: making module upgrades more standardized (no need to keep track of which modules depend on an external library and then go and download the library with every upgrade).
Anyway, like I said, feel free to ignore this if you feel it would be too much work, but I thought I'd throw it out there.
Comments
Comment #1
icecreamyou commentedHere's an untested patch to add support for Libraries API v2.
Comment #2
jordanmagnuson commentedThanks Isaac!
I applied the patch, moved jquery.timeago.js to sites/all/libraries/timeago/, and so far everything seems to be working fine.
One small issue: status report is not registering the correct version of timeago, or the fact that the library is installed:
Comment #3
icecreamyou commentedWell, you're probably using version 0.9.3. The current version of the library is actually 0.10.1. You can go download the current version from http://timeago.yarp.com/jquery.timeago.js. If that works for you, you can mark this issue RTBC.
Comment #4
jordanmagnuson commentedActually, I'm using version 0.10.0. That's the version of jquery.timeago.js I have, and the version I have declared in the timeago module:
The problem lies in timeago.install, which needs to be patched to work with Libraries API:
I'm also wondering why the jquery.timeago.js version number is hard-wired into the code, both here and in .module...? Shouldn't it be checking to see what version you have installed (from jquery.timeago.js @version), rather than telling you?
Comment #5
icecreamyou commentedOkay, try this one.
I don't really get why the version has to be hard-coded either, but that's what the core hook_library() mandates.
Comment #6
jordanmagnuson commentedThanks for your help on this once again Isaac. I noticed that your patched install file just ignores the case of libraries api being installed... of course that fixes the error message, but doesn't give a lot of feedback if, like me, you are using the libraries api... of course, I realize that you're probably short on time, and getting the libraries api fully integrated probably isn't high on your todo list, which is totally understandable...
So anyway, I messed around a bit with the code myself, and created a new patch file, that gives a bit more status page feedback, regardless of whether you have libraries api installed or not. It also pulls the library version number from the actual javascript file, rather than hardcoding it. The install file is the only thing I've changed... the rest of the patch should be identical to yours...
I'm relatively new at Drupal development, and this is the first time I've attempted to create an actual patch file, so if I've done something terribly wrong, let me know, and I'll try to do better!
Anyway, let me know
Comment #7
jordanmagnuson commentedOkay, a bunch of bad whitespace and tabs in that last one, so here's another try...
Comment #8
icecreamyou commentedThere is no guarantee that the library is in sites/all/libraries. The Libraries module checks several locations. The right way to check if a library is installed is to call libraries_load() and check the "installed" key of the returned array. Also check out libraries_get_path().
extra indenting here
Use PHP's version_compare() function.
Why are you putting "@path" in a separate string? It's not a PHP variable so it doesn't need to be in double quotes, and concatenating strings confuses the translation script.
Same comment as above -- putting "@path" in a separate string doesn't make sense
Add a line between the description and @params. Also add an extra space before the @param descriptions (there should be 3 spaces after the *) and add "@see libraries_get_version()".
This needs to handle the case where the file cannot be reached, e.g. no internet access is available. It also fails if no version string is found.
latest version is 0.11.1
Thanks
Comment #9
jordanmagnuson commentedThank you for the pointers Isaac. I've tried to address everything you mention.
Regarding timeago_get_version, I think it should work if the remote file cannot be reached, as it will return false in that case (fopen will return false), and the install function will report that update information cannot be found... I tried accessing a nonexistent remote file, and it seemed to behave as desired.
One addition I made in this patch was to define constants for the library website, file name, and download url... was starting to reference them in a number of strings, etc, and it seemed like having constants defined would make things simpler in the future, should the library ever change its location, or file name. I've seen this method used in a number of other modules, but if it's undesirable for some reason, of course I can revert.
I also fixed a couple of spacing issues in timeago.module after running the code through coder, and changed timeago_add_js so that it looks for language files in the correct location if libraries is installed.
Comment #10
icecreamyou commentedYeah this is fine.
The logic here should be:
$path = libraries_get_path('timeago');$pathis empty (i.e. the library was not found or the libraries module is not installed) then look for the path in the module folder.There is no circumstance under which you can assume that the path should be in sites/all/libraries/timeago.
Let's just do
if (file_exists($path))instead of using an intermediate variable since we don't use that variable anywhere else.We should probably cache this so that we don't have to request a foreign URL every time the Status Report page is loaded.
This message should have some indication that the library was installed, not just that no information was found.
Remove the phrase "It appears that" and so the message starts with "A newer version of the library is available"
This will still check the whole file for a version string -- it should only check the first 200 characters of the first 20 lines or whatever the libraries module does.
Thanks for your work on this.
Comment #11
jordanmagnuson commentedThanks again for the recommendations: I've tried to address everything. Tested with and without libraries api, in various states, and seems to be working.
The only thing I question is:
I agree that bothother locations should be checked first (which I neglected on the last patch), but if the user has libraries api installed, but does not yet have jquery.timeago.js installed in either location, I think the status message should recommend installing to the default libraries api location, rather than within the modules directory, as a best practice. I think the libraries module should have some kind of libraries_get_default_path() function, but instead, the default location is just hardcoded into the module (as 'sites/all/libraries'). I agree that 'sites/all/libraries/' is not the only place that the library could go (given that other locations are also checked), but if it is not installed already, I think the libraries default path should be recommended.
Comment #12
jordanmagnuson commentedMoved the constant definitions from .install to .module, where they should be, and got rid of some left-over comments...
Comment #13
icecreamyou commentedCommitted #12 to dev with minor modifications to the description strings for the status report page. Thanks!
Comment #14
icecreamyou commentedOh actually this needs to be backported to 6.x... reopening
Comment #15
icecreamyou commentedThe change in #13 causes these notices when the module is installed because the .install file is loaded before the .module file:
Probably we should just load the module file at the top of hook_requirements() if it isn't already loaded.
Comment #16
icecreamyou commentedCommitted fix to dev. Took the easy way out.
Comment #17
icecreamyou commentedI'm actually okay with not backporting this to D6.