This started out as a normal bug report:
On the Upgrading modules page there's a subheading "Reinstall Module." The text under the subheading only talks about file management. Obviously, reinstalling includes re-enabling the module, but the absence of the word "enable" can cause some people to think they should not enable the module at that point and they'll even try to run the module's update functions with the module in disabled state.
The comments show that this has caused confusion back in 2008, and it continues to cause confusion even in 2011; see #1022652-4: While update: Fatal error: Call to undefined function for an example.
Half a year ago, Merlin already commented that disabling modules was bad advice. Indeed, this is catastrophic advice!!!
If you run a Node Access module, for example, and you disable it for updating, then all your content will be publicly accessible until you re-enable it! Disabling essential modules while your site is on-line is a very very bad idea.
Putting the site into off-line mode is essential, and it should be sufficient, too, at least for sites managed by admins who need to refer to these instructions.
P.S. Re-enabling a Node Access module typically requires rebuilding permissions, which can be a lengthy process, during which confidential content continues to be accessible for everyone including Google...
Comments
Comment #1
chx commentedthe problem is that some modules won't even allow you to bootstrap Drupal until the upgrade finished. So the advice stays because it's very hard to be more detailed about it.
As for node access, you surely are updating a copy of your site and then deploying an upgraded version and not trying to upgrade a live site.
Comment #2
arianek commentedThis opened up quite the can of worms... (reopening). The proper instructions are in the UPGRADE.txt file in Drupal 7. This page *does* need updating... but http://drupal.org/node/250790 is also in the wrong section (Install Guide).
Probably because of that there is a very recent duplicate page in the Upgrade Guide http://drupal.org/node/948216.
This newer page needs any pertinent content moved to the older one, then we should move the older one from the Install to Upgrade guide to replace the newer page.
Comment #3
salvisIs this Drupal's problem? Does Drupal really have to accommodate such far-out requirements? I don't think so.
I don't think that's acceptable. We want to become a major player in in the CMS field and we can't even come up with specific instructions on how to update modules?
As arianek points out, UPGRADE.txt gives conflicting instructions. We have to come up with ONE procedure and stick to it. If a module really cannot fit in, then that's their problem, and they have to shoulder the burden of educating their clients accordingly, but we can't just pass the confusion on to the world.
I guess this is another classic case where some faction is unwilling to stick to the rules, so they sneak in some conflicting ones. No one notices it and subsequently they can claim they're adhering to the rules, and Drupal suffers from the confusion.
No, not at all. I'm perfectly happy with putting the site off-line and updating my node access modules on the live site.
This is not just about node access modules — I just picked that as an example that I'm familiar with. The directions on the 'Upgrading modules' page say nothing about putting the site off-line but instead tell you to disable the module you want to update.
For one thing, there's probably a reason why that module is installed, and the site won't work normally if you disable that module. And secondly, it's a weird idea to disable a module during its most critical minutes. We certainly don't disable core modules while system.install updates their tables, so why would we want to do that for contribs?
Comment #4
arianek commentedtags
Comment #5
quietone commentedThis is about Drupal 7, which is EOL.