getid3 library not found error...
| Project: | Media Field |
| Version: | 5.x-1.01-rc1 |
| Component: | Documentation |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
I don't mean to be dense, but I can't get mediafield to recognize the getid3 library. You vaguely say put it in misc/lib, fine. I created a misc & lib directories in the module folder. And I put getid3 in there. So, just to be unambiguous, the path to the getid3.php file is:
sites/<<subsite>>/module/mediafield/misc/lib/getid3/getid3/getid3.php
However, when I check the code in the multimediafile.inc file I see that you have 'misc/lib/getid3/getid3/getid3.php' hardcoded in there. Seems reasonable. It must automagically use a relative path from the module folder. Just to be sure I stick a system call in there to see the path - whoops, it is not relative to the module folder, it is relative to the base installation folder. So it is looking for getid3 in base_path()/misc/lib/getid3. Is that what you meant?
I haven't been using Drupal for that long, but every other module I've tried that has dependencies puts those dependencies in the module folder, not in a base_path()/misc/lib folder - I've searched the handbook to see if this was some standard I was unaware of. If it is it is undocumented.
Is this a problem with my setup? Should the path in the multimediafile.inc be relative to the module directory? I've tried this with multiple sub sites - the first one has a complicated directory structure, but the same problem occurred even in a simple sub site configuration.
Any ideas what I'm missing?
#1
Hello,
Yeah, when I wrote misc/lib I ment that good old global misc folder. I think that putting common 3d party lib/component into the module's folder is a bad idea because this component can be shared between several modules. Don't you want each of them has its own copy of getid3 lib?
As for standard, I didn't find anything saying where to put such common 3d party libs and decided to put it into misc folder. Even in multisite configuration you probably don't need to have several copies of getid3 lib, right? If so, global misc is a best choice.
multimediafile.inc file should be in the same folder where audio and video fields are.
Honestly, I myself am not satisfied with misc. Instead, I prefer 'lib' or 'common' or 'cmn' dir in the root of Drupal for 3d party components, but unfortunatly Drupal doesn't assume this. Any ideas how to solve it?
#2
No I do not have a solution. I see the merit of both positions, each module using its own version or a global library area for shared resources.
The short term problem as I see it is the readme is vague about creating a global misc/lib folder. Misc already exists, but lib didn't. Since no other module I've used has ever used or expected anything outside of its own folder tree, I believe you need to be 100% unambiguous that is where the module expects to find the getid3 library.
Thanks for the response. I'm sure it'll work now.
#3
For instance, gmap module does almost the same. It requires several javascript files to be put into global misc folder.
Okay, you absolutely right concerning documentation. I have updated it for HEAD, 5.0 and 4.7 revisions. Release will be available shortly.
Please, set this issue to close if everything is working. Otherwise, you are welcome to ask questions.
#4
#5
It would be a good idea to explicitly say in the documentation exactly where to put the getid3 library, giving a complete path.
The two nested 'getid3' folders can be confusing too!
Saying something like
"so that the path to the getid3.php file is (drupal base)/misc/lib/getid3/getid3/getid3.lib.php"
#6
Updated documentation was commited.
#7
The installation directions in the README file say:
But when I installed the module, I got this error:
I moved the files over to the modules directory per the error instructions. Please update your documentation to reflect the proper location of the getID3 library as per the getID3 module.
Thanks!
#8
Good catch, in the latest update the module became dependent on the getid3 module, which deals with the id3libs... I've just updated the README to reflect this.
#9
Automatically closed -- issue fixed for two weeks with no activity.