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.
When two modules with the same name are placed in different locations (ie core vs sites) the system does some rather dumb things.
- Loads both install files, which results in nasty things like:
Fatal error: Cannot redeclare simpletest_install() (previously declared in /home/boombatower/software/simpletest/simpletest.install:109) in /home/boombatower/software/drupal-7/modules/simpletest/simpletest.install on line 54
- Uses the proper .info file.
- Actually loads the core PHP files and ignores the ones in sites folder.
Comment | File | Size | Author |
---|---|---|---|
#26 | 625744-epic-fail.patch | 2.13 KB | boombatower |
#19 | 625744-epic-fail.patch | 2.05 KB | boombatower |
#13 | 625744-epic-fail.patch | 2.06 KB | boombatower |
#9 | 625744-epic-fail.patch | 1.01 KB | boombatower |
Comments
Comment #1
sunEverything in sites/ should always have precedence.
Comment #2
boombatower CreditAttribution: boombatower commentedRight, but they don't.
Comment #3
boombatower CreditAttribution: boombatower commentedWorking on this.
Comment #4
boombatower CreditAttribution: boombatower commentedSo far, drupal_get_install_files() returns the proper .install file locations, and only one of them for simpletest.
Comment #5
boombatower CreditAttribution: boombatower commentedsystem_rebuild_module_data() seems to exhibit the behavior I noticed.
It says simpletest is in modules directory, yet picks up the .info file information from the one in sites (double whammy).
Would seem it has to do with:
Not updating to the proper file since the database has the wrong file, but:
returns the right one (which is used for .info file parsing).
Not sure why this code is so extremely convoluted.
Comment #6
boombatower CreditAttribution: boombatower commentedIt would seem that one function (for scanning file system) would be enough then...you update file listing ..and read .info files.
Secondly, I have no idea what the purpose of the get and then update the files database...as from scanning it would appear no change is made...the files table is simply re-written.
Comment #7
Dave ReidNot sure what you mean by re-written in http://api.drupal.org/api/function/system_update_files_database/7. Old obsolete module records are deleted and new/discovered/updated (as in info in the module's .info file changed) modules are inserted/added. The point of the two functions (you should take a look at this nasty code in D6), was to re-use the functions with both themes and modules.
Comment #8
boombatower CreditAttribution: boombatower commentedThe names are not clear, but either way since both modules and themes have info files they still share everything in common and should be able to use the same function, I am not seeing why the info file parsing is completely separate or if anything why they do not use the same method to seek the actual files.
Either way, the functions that seek the files do not function properly, when I get time I'll try and figure it out, otherwise it would be great if someone else had time to fix them.
Comment #9
boombatower CreditAttribution: boombatower commentedWin on the "key" instead of "$key".
Comment #10
sunGreat.
So what we do now is:
1) Add modules/simpletest/book.module.
2) Put some completely different stuff in there. Including hook_menu() to test a callback. Perhaps also an arbitrary alter hook.
3) Add a test that enables "book" module.
4) Verify that modules/book/book.module is NOT loaded and entirely unknown to the entire system.
Comment #11
boombatower CreditAttribution: boombatower commentedThat doesn't really work since it should always override. We only care about levels when modules/ vs sites/all vs sites/xyz.
And we dont' have write access to sites/[non-files] or modules/ so unless we do somethign interesting it isn't really possible since we need to gen module on the fly. (or break rules)
Comment #13
boombatower CreditAttribution: boombatower commentedDouble wammy, bad test as well, since $array1 == $array2 or $array1 === $array2 will only be equal if they are in the same order, which sadly the test it trying to check once in order and once not, but uses same assertion.
For example:
Results in:
Which is what we want.
Comment #14
Dave Reid@boombatower: If you use array keys (which is what happens in module_list()), comparison does work:
results in
true
Comment #16
Dave Reid@boombatower: Not sure what you mean by array_combine not working. "array_combine — Creates an array by using one array for keys and another for its values".
$expected_values = array_combine($expected_values, $expected_values);
basically works like drupal_map_assoc().Comment #17
boombatower CreditAttribution: boombatower commentedHere are the arrays the test has when it runs.
Only difference is default is in a new location.
Looking into this.
Comment #18
boombatower CreditAttribution: boombatower commentedAh, yes @Dave Reid: your example uses "==" when assertIdentical() uses "===".
I'll update test to use == and then we don't need array_diff().
Comment #19
boombatower CreditAttribution: boombatower commentedComment #20
boombatower CreditAttribution: boombatower commentedchx said it was worthy of a phpwtf: http://www.phpwtf.org/identical-arrays-vs-equal-arrays.
Comment #21
rfaySubscribing. I too have spent pain on this issue.
In my case:
Comment #22
boombatower CreditAttribution: boombatower commentedFor clarification, #19 works great for me at solving the problem, just need someone to "review" the patch.
Comment #23
chx CreditAttribution: chx commentedBugfix and a PHP ouch in the test. Please understand that this is a serious regression. The capability of site specific core hacks by copying a module and hacking there is rather important.
Comment #24
sunCould we quickly clarify/improve this inline comment a bit? I don't get what it wants to tell me by reading it.
I'm on crack. Are you, too?
Comment #25
webchickComment #26
boombatower CreditAttribution: boombatower commentedHere ya go.
Comment #27
sunMarked #345031: Useless condition in system_get_files_database and #610214: Fatal error if you move or override an enabled module. sites/all/ vs sites/sitename/. Cannot disable, cannot recover. as duplicates.
Comment #28
boombatower CreditAttribution: boombatower commentedoo...lets get this in.
Comment #29
webchickCommitted to HEAD.