Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I think you'll find that digging thorough the audio_getid3.module in the audio module would be a good source for code for dealing with getid3. i've got a couple of years worth of time in dealing with it and i'd hate to see you duplicate it.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | switch_to_libraries_api-173616-10.patch | 9.27 KB | mglaman |
Comments
Comment #1
RobLoachAudio_getid3.module assisted greatly when working on this. Is there anything else that could be abstracted away from audio_getid3.module that would help other modules using GetID3?
Comment #2
RobLoachMoving the GetID3 module over to Libraries would allow us to easily change the path..... Otherwise I think we should close this issue.
Comment #3
drewish CreditAttribution: drewish commentedLibraries still needs work. They don't have a stable release so I'm not in any hurry to migrate to it.
Comment #4
hswong3i CreditAttribution: hswong3i commentedgetID3() with Drupal 7.x Library API integration. This will also works within installation profile, and able to auto detect the default value of getID3 library path. Fully tested with Drupal 7.x installation profile development.
Moreover, this patch also simplify some dummy error message handling, plus coding style cleanup with coder.module.
Finally, it also synchronize coding style with that of patching colorbox.module with Drupal 7.x Library API support (http://drupal.org/node/989590).
Comment #5
JohnAlbinI committed some of the comments and the t() -> st() fix in the .install file. Thanks!
However, I don't understand why you haven't fully ported getID3() to Libraries API. The patch above only uses the libraries_get_path() function if the the Libraries API is installed. The patch doesn't define any of its hooks or declare it as a dependency.
Comment #6
hswong3i CreditAttribution: hswong3i commentedThis is because during installation libraries API may not yet successfully load in and so if we call it directly, the call will be failed. Therefore we need to manually include libraries.module.
On the other hand, libraries API just give a hand for us to figure out the correct path of library, and it is only useful IF user are not placing the files under module's path; besides this, nothing at all. So I would like to suggest NOT with enforced dependency with libraries API since it is not a most ;-)
Patch reroll via GIT 7.x-1.x.
Comment #7
ericduran CreditAttribution: ericduran commentedCurious is this something people are still interested in?
Personally I think it's a good idea.
That being said this patch needs work.
It seems like this was written before libraries-7.x-2.0
Comment #8
mglamanHere is patch migrating to use Libraries 2.x. I have this implemented in my custom module, which I utilized since I did not have immediate time to write patch here for.
Comment #9
mglamanMoving this to 7.x-2.x It can be marked as a patch to be back ported.
Comment #11
mglamanHere is a patch with a diff of the 7.x-2.x Libraries implementation to 7.x-1.x.
Comment #12
mglamanLinking to 2.0 release plan