Closed (works as designed)
Project:
Node import
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
2 May 2009 at 03:39 UTC
Updated:
2 Oct 2009 at 16:05 UTC
See both the attached images. Even though the Node Import module is not enabled, update.php ran some Node Import module updates.
This is a multisite install with most modules, including Node Import, in the sites/all/modules directory.
I do not recall whether Node Import was ever used on this site. If it was, it was probably over a year ago, back when this was a 5.x site.
| Comment | File | Size | Author |
|---|---|---|---|
| Drupal database update - White Rock District_1241235210539.png | 71.94 KB | aren cambre | |
| Modules - White Rock District_1241235302329.png | 480.94 KB | aren cambre |
Comments
Comment #1
aren cambre commentedIt's even more weird.
I have another site where I know I used the node import module a long time ago, back when it was a Drupal 5.x site. The node import has not been installed in a long time but reappeared when I switched most of my multisite common modules to sites/all/modules.
I just ran update.php and again got the node_import updates where it's doing update 6000, 6100, and 6101.
Strangely, this happened even though I don't currently and have never had the Date API module. Node import depends on Date API.
Comment #2
Robrecht Jacques commentedI don't know if this is a node_import issue.
AFAIK these are the possible states:
- module is not installed (directory is copied to server)
- module is installed (and thus enabled)
- module is disabled (but previously installed)
- module is uninstalled
It is possible that updates for previously installed but now disabled modules are run and that updates are not only run when the module is enabled... I don't know - would need to look into this.
If this is the case, going to the Uninstall tab to completely uninstall node_import would solve this issue. Could you try that?
If updates 6000, 6100 and 6101 are run, this would mean that the module was installed on 5.x. 6000-6099 are run for updating 5.x to 6.x. 6100-... are run for updating 6.x-1.y to 6.x-1.z (or for node_import: 6.x-1.0-rcX to 6.x-1.0-rcY). Since all three updates are run the above assumption that updates are run for disabled (but installed) modules.
Setting this to minor priority as running the updates does not affect the functionality of the module.
Comment #3
aren cambre commentedPer above, update.php is updating data for modules that are present but disabled.
I can see limited scenarios where this is useful, such as where all these conditions are true:
Unless all these conditions are met, I think this is poor design to force data updates for disabled modules. If the admin never intends to re-enable the module, there is no possible benefit to the update, and Drupal databases are exposed to possible corruption or errors. That is an impossible-to-justify cost/benefit ratio.
You may respond with, "Well, the user can uninstall the module or its tables." That is also not valid: the admin may not know if he ever wishes to reuse a disabled or not-present module but would like to retain the data just in case he changes his mind.
You may also respond with, "Then delete the module." Not doable for multisite instances that use sites/all/modules, where it is very likely that more modules will be present than enabled. Even then, that argument only applies to non-core modules, whereas my argument is for all modules, core or otherwise.
Comment #4
aren cambre commentedTagging as usability since this involves unintuitive or illogical behavior.
Comment #5
hass commentedThis is by design in D6+. Modules need to care about this.
Comment #6
hass commentedIf something is broken by this core feature - Node import need fix it's bugs. Moving back to Node import.
Comment #7
hass commentedSee #194310: Check / run updates of disabled modules for the reasons why this has been implemented.