Closed (outdated)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
23 Nov 2010 at 14:55 UTC
Updated:
14 Dec 2010 at 09:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
fagoadded a test.
Comment #2
klausiI think the test does not trigger the error. Here is patch that only changes the test case and it does not fail on my machine. Let's see what the bot says.
Comment #3
fagoindeed, module_hook() and so module_invoke() works regardless whether the module is enabled. The problem is though, module_invoke_all() uses module_implements() which does not work for disabled modules. That inconsistency is another issue though.
Attached patch contains only the test improved to also check module_implements(), thus it should fail.
Comment #5
fagoOk, here is a patch including the improved test + the fix. Should be green now.
Comment #6
drunken monkeySubscribe.
Comment #7
fagoAny reviews? This is required to make #978832: enable modules to apply configuration (exportable entities) actually work.
Comment #8
drunken monkeyTried it, but doesn't seem to work.
Setup:
When disabling module2, only the "hook_modules_disabled()" message is displayed.
Comment #9
klausiAs fago said: you cannot use module_invoke_all() as it uses module_implements() which does not work at this point (this is a separate issue).
Otherwise the test now correctly triggers the error, RTBC for me.
Comment #10
fagoad #8: Try running the test-case of #3 with and without the fix applied, that should work.
Comment #11
drunken monkey[Sorry, duplicate comment — had some weird display bug here just now.]
Comment #12
drunken monkeyThen what exactly does this patch fix?
Also, as mentioned in #978832: enable modules to apply configuration (exportable entities), your own code using this doesn't work for me, so there has to be a bug somewhere.
Comment #13
drunken monkeySorry, my bad — made a stupid mistake when testing.
Patch seems to be RTBC to me, too.
Comment #14
dries commentedWhy do we want to move the code, versus updating the code comment.
Based on the name, I'd expect hook_modules_disabled() to be called after the modules have been disabled.
If the hook is going to be called before the modules are disabled, I'd expect it to be called hook_module_disable(), i.e. no trailing 'd'.
Comment #15
fago>Based on the name, I'd expect hook_modules_disabled() to be called after the modules have been disabled.
Ops, indeed, that's the only way it makes sense. Also the hook description says "Perform necessary actions after modules are disabled." - thus modules have to be disabled.
In my use-case #978832: enable modules to apply configuration (exportable entities) I'd need to be able to invoke the module's hooks in order to get the exportables defined by the modules being disabled. Thus having enabled modules would be useful, but well, that would be pretty inconsistent with the hook description.
So, I've re-rolled the patch to fix the comment instead + changed the test to make sure modules are actually disabled.