4

I have seem multiple update tutorials tell you to disable all non core modules before doing an update. What is the reason for this? I'm not real familiar with the update area of core but can't see any real good reason. Is there something major I am risking if I don't do this?

I can understand the reasoning if we are doing an update between major versions (6 -> 7). But when doing a minor update (7.10 -> 7.12) is where I have my question.

Improve this question

3 Answers 3

Reset to default
3

Contributed modules are not always robustly built and can fall victim to changes made in core. This is particularly an issue if the contributed module has not made proper use of Drupal's API or relies on a database structure in core that may change with the upgrade (even if it is just a minor update). It is therefore safest to disable all the contributed modules before updating in case one of the modules causes the site to fail on completion of the upgrade process. Admittedly this is rare, but it does happen. It happened to us once, but thankfully just on a dev version of a site.

Improve this answer
2
  • Considering the rarity of something catastrophic happening, wouldn't it be good enough to depend on the backup you made just prior to doing the update? It seems to me like the chance of something going wrong is hardly worth the effort, time and risk of error that exists when you disable all your contrib modules.
    – Icode4food
    Feb 16, 2012 at 17:11
  • 1
    As long as you have backups and you test it on a copy of the live site it should be fine to do this. If all goes well then you shouldn't have an issue on the live site, but make sure you put the site in Maintenance mode before upgrading. You don't want users messing things up. :)
    – drmonkeyninja
    Feb 16, 2012 at 17:19
0

When upgrading from 6 to 7, none of the modules should use sessions table (in *hook_boot* or *hook_init*), otherwise it generates the fatal error. If you have simple website, you can try to upgrade Drupal, but in case of any fatal errors, you should disable them.

Please see the common problem which happens when some people trying to upgrade with contrib modules:

Upgrade D6.20 to D7 fails with PDO Exception

Here is sample command to disable all non-core modules and themes:

echo 'UPDATE system SET status = 0 WHERE filename NOT LIKE "themes%" AND filename NOT LIKE "modules%";' | `drush sql-connect`

Also you may try to clear the caches:

echo "DELETE FROM cache`drush sql-connect`
echo "DELETE FROM cache_bootstrap" | `drush sql-connect`

And remove any included files from the settings.php file such as memcached, etc.

Improve this answer
0

My suggestion is: don't. It's Drupal 6-era advice, and the world has changed since then.

In Drupal 7, many modules can't be disabled properly, or there is a danger of them not working properly when they are re-enabled. Any module that provides field / entity types is a suspect, Commerce for instance. This is why Drupal 8 has removed the concept of disabled modules completely.

(Of course, this only concerns point upgrades, not major version upgrades such as 6 -> 7)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.