Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By eceleste on
The instructions for upgrading clearly state: "Disable all custom and contributed modules."
I did that when upgrading from 6.8 to 6.9 and it was a pain. I had to do it four times to get through all the dependencies. By the end I felt a bit foolish. But this was my first Drupal upgrade, I played by the rules.
Then I asked one more experienced Drupal admin and he said he often skipped that step, he knew the modules would do fine.
So I want to ask you: Do you disable modules or not?
Any advice on modules that definitely should be disabled and why? Or conversely, on ones you have regularly left enabled without harm?
Thanks for sharing honestly!
Comments
contrib_toggle
FYI, I've also discovered that for those of you who _do_ disable your modules for upgrades, there is a new module to help with that! Check out http://drupal.org/project/contrib_toggle.
Nope
Disclaimer: this isn't on a high traffic site. You'd probably want to at least take the site offline and/or clear the cache also.
For point updates eg like 6.8 to 6.9, I just overwrite the files (I have a shell script than checks out the code base from subversion and uploads it) and check for the rare change that needs update.php to be run. The release notes should point out any (very rare) change to the API - if there are no API changes, then it is highly unlikely that any modules will break.
For major upgrades eg 5.x to 6.x, I also just upload the new files and run update.php. BUT I would have repeatedly tested and debugged the process beforehand on another server first until I am confident it will work.
The update instructions are overly conservative (rightly so) and make no distinction (last time I looked) between minor updates and major upgrades. There are plenty of shortcuts possible, but you should only take them when you know what you are doing and have tested your own procedure.
Testing it on another instance is the key to having confidence in what you are doing. I don't recommend skipping steps unless you understand why that step is there and you know the ramifications of skipping it.
I agree completely, except
I agree completely, except perhaps on one point, "overly conservative (rightly so)".
The catch with an overly conservative recommendation is that, if many contributed modules need to be identified, disabled, and then enabled again in many sites, many people will tend to postpone even point security updates leaving them "for a better time", which defeats the point of those updates.
Practically, an overly conservative recommendation for minor updates is equivalent to a security vulnerability. Some tools like contrib_toggle are badly needed (although contrib_toggle can't re-enable the modules yet).
That's a very good point about security
I just remembered the hell that was trying to keep up with security hotfixes on NT4 servers in the late 90's before Windows Update came along. Or (to be fair) patching the average non-Debian Linux distro back then too ;)
The "rightly so" comment was aimed at the full version upgrades which are far less frequent but have far more that could wrong. I agree the full instructions are way over the top for the vast majority of minor updates, and that can have the unintended/unfortunate effect you mention.
The key to successfully pulling off the laziest method you are comfortable with is testing it elsewhere first. The conservative instructions are (I presume) aimed at the people who don't/won't/can't do their own testing and have only one shot at it.
Different sets of instructions for minor updates and major upgrades would be useful, but it would be hard to make blanket statements as there have been rare API changes that happen on minor updates that could still potentially break existing modules. Explicit statements in the release notes that there are no DB or API changes are probably the key to knowing which steps can be skipped. I think the release notes are improving a bit in this area, but probably could be more explicit.
Some rules of thumb:
If there are no DB updates, you should be able to skip running update.php for minor updates.
If there are no API changes, it is probably perfectly safe to keep the modules enabled.
And if there are API changes that break modules, you'll still need to fix the modules anyway. So testing is still the best approach anyway.
No, I don't.
No, I don't. But I do work with SVN, test locally, and if it works, deploy to the live site.
I do, but I forgot to upgrading from 6.9 to 6.10
I do, but I forgot to upgrading from 6.9 to 6.10. Now I can't see any of my content. Only my custom theme works. The database content is still there on the live database when I browse the tables, but Drupal can't see it. Good thing I have the backups.
I have upgraded from 6.6 to 6.7 to 6.8 to 6.9 before without incident.
Has anyone else experienced this? I am about to reinstall if I can't find the solution soon.
I didn't
I'm a newbie (first live site started on 6.9). I've got backups and know how to restore them. I figured I'd take the "risk" (with backups of course there's no real risk except for lost time) with 6.9->6.10. I used a patch file approach, as I posted about elsewhere (guards against overwriting any local modifications). As someone else noted, checking your drupal out from svn would be a good idea.
No
No
automated Disable/Enable of modules for Drupal core upgrade
To be on the safe side, you can automate disable/enable of modules in this way:
================================================
Install Drush module (--uri=http://example.com specifies which site you refer in a multi-site installation)
--- Get all enabled modules in a list delimited by spaces:
drush --uri=http://example.com sm --pipe
--- Remove from this list the core modules (block, filter, node, system, user) and disable the resulting list:
drush --uri=http://example.com disable <resulting_list>
--- Upgrade Drupal core
--- Enable the same modules with the command
drush --uri=http://example.com enable <resulting_list>
PS: Don't forget to check out http://drupal.org/upgrade/tutorial-introduction for a complete procedure for Drupal upgrade
If by some reason, you can't use Drush to enable or disable modules and your site does not work, you can still use MySQL command (http://drupal.org/node/157632):
UPDATE system SET status='0' WHERE name='module_name';
to disable a module, for example.
Careful with this, I tried
Careful with this, I tried doing this on my dev site and have been troubleshooting a White Screen of Death for 4 hours now...
I keep all contributed
I keep all contributed modules in sites/all/modules and all contributed themes in sites/all/themes.
For upgrades I removes ALL files from the server EXCEPT the sites folder ("sites/all" and "sites/default" - these contain all my contributed and default configuration files plus user uploaded files).
I have a custom zipped latest Drupal installation which DOES NOT contain a sites folder - upload and unzip that into the root folder and voila - I'm back in business with a new installation which includes a sites folder containing all my previous contributed info, configurations and user files (in the "sites/default/files" and "sites/all" locations).
This has worked for me on numerous websites - If I remember I put the site into maintenance mode but I never disable any modules - they always come back fine.
My admin blocks show a "who's online" block so I usually check to ensure no-one is online whilst I do all the above. My sites are all small business sites so not a huge traffic issue.
The whole process only takes about 15 minutes generally - I delete files whilst working in the server environment and extract my uploaded zip file from within my server - much quicker.
Well, I guess I have to
Well, I guess I have to confess... I have never ever disabled when upgrading... ;)
Disable contrib modules, YUP
I always do, and I've yet to have any pains upgrading a drupal site.
Thomas Newman
Drupal Developer, Site Builder, Themer