[support] upgrading to 5.8. One question.

Victor Kane victorkane at gmail.com
Tue Jul 15 10:08:53 UTC 2008


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 at 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 at users.sourceforge.net>:
> > Quoting Brian Choc <bchoc at 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 at koba.be
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20080715/d8c3c264/attachment-0001.htm 


More information about the support mailing list