I think it's better to distinguish between release upgrades, security upgrades and module upgrades (upgrades for individual modules).
On the big upgrade (release upgrade) from 4.7 to 5.x, of course, the best practice was to disable all modules, basically due to the objective of making sure the upgrade to a new release was working, and also because modules had to be completely rewritten for the new release.
Also, the idea was to enable each contributed module one by one, in order to know what when wrong, if it did, and when it went wrong: specifically with which module lay the problem. And doing a database dump each time, you can always go back to a working scenario.
If you leave all modules enabled in a release upgrade you are almost definitely going to have problems and worse, you are not going to know where the problems come from.
Imagine someone upgrading from Drupal 5.x to Drupal 6.x; this is a migration, not an upgrade. Many things are going to have to be pinpointed and taken care of.
With security releases, I do not disable modules and have never had any problem.
On 4.7.x to 5.x see my article at http://awebfactory.com.ar/node/223 (based on webchick's video from Lullabot)
Victor Kane http://awebfactory.com.ar
On Mon, Jul 14, 2008 at 6:14 PM, KOBA | Hans Rossel info@koba.be wrote:
Interesting discussion.
I also never disable modules when upgrading. I have never lost data when I disabled them originally, but as far as I remember some configurations of CCK were lost. But that was in the early days of cck and Drupal 4.7. Since then I never disabled modules and never had problems (always with backup ready). Its also quite annoying when you have more modules uploaded than enabled to have to write down which modules are needed for each installation.
it could be good to hear from somebody who always does it right and disables all modules before upgrading that it has never caused problems, just to add some counterweight to this thread.
Hans www.koba.be
2008/7/14, Earnie Boyd earnie@users.sourceforge.net:
Quoting Brian Choc bchoc@t4tcolorado.org:
I found that disabling modules during minor upgrades causes data loss consistently under specific circumstances, during earlier updates (e.g. 5.2, 5.3). I observed that any module-supplied node type would drop all the data in any assigned CCK fields when disabling & upgrading. For example, if one had a simplenews node with an "editor" cck field attached to it, one
would
lose all "editor" information. However, the basic simplenews node data would be kept, as would any cck fields attached to standard nodes. Only the combo of cck + module-supplied-node-type seemed to cause problems.
So what you're indicating is that modules implementing hook_node_info will loose the node_type row and thusly the nodes of that type. This would then be a critical bug in the core base system. Or perhaps your incident is related to only one of the CCK fields modules and then the critical bug would lie with that module. Disabling a module should not under any circumstance cause data to be removed.
That said, I do not disable modules either when upgrading from Drupal version 5.x to Drupal version 5.y. However, that isn't the documented method and the documented method needs to work.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Hans Rossel KOBA Webdevelopment Kerkstraat 228 9050 Gent 09-334.52.60 0472-79.32.16 www.koba.be info@koba.be -- [ Drupal support list | http://lists.drupal.org/ ]