By matteoraggi on
Also wordpress as drupal need to uninstall all plugins-modules first to get an upgrade, and I suggest as wordpres is doing to have by default or a module that deactivate with a click all modules and after upgrade resume the old activation list of modules, I think many people as me , have dozenz of activated modules and some not yet activated, and click all one by one need many minutes and could also take some errors plus other looose of time, instead here with a simple developing work, is possible to give big human advantage to the comunity of drupal when upgrading
Comments
You don't need to disable
You don't need to disable modules to upgrade Drupal.
you are right
Sorry for my mistake, it was needing only for drupal 5.x , 6.x don't need it, sorry for distraction
Luxury Furniture
http://www.luxury-furniture.biz
According to the
According to the documentation, disabling contributed modules during an upgrade is always needed.
Many people (including myself) believe that it is only needed for major upgrades (5.x -> 6.x) and not for minor upgrades (6.8 -> 6.9).
Recently I saw the http://drupal.org/project/contrib_toggle module which can disable many modules at once, and in a future version will be able to re-enable them.
Where in the doc that say...
>According to the documentation, disabling contributed modules during an upgrade is always needed.
What documentation say this?
I could be wrong but I don't see the need to disable contrib modules. Running update.php goes through each modules's .install, applying any necessary patch. For existing running modules, this is just a no-op.
I agree, but
I agree, but http://drupal.org/upgrade -> Drupal Upgrade Tutorial for upgrading from one version of 6.x to another says otherwise.
Maybe there is some rare special case which needs to be covered, or maybe it is just wrong.
During a CORE upgrade...
During a CORE upgrade... It's recommended; but you might have to fix the garbage, if you choose otherwise. Only the build-in core modules are sufficient tested for this.
Today I researched this a bit and I found something like this: It seems that especially "node-modules" have to be unchecked/uninstalled before (minor) upgrades (if not all to be sure)on minor upgrade. But now Im not sure anymore if unchecking is sufficient, or that one also has to de-install the modules on the next page. The statement was from a female member here who adapted the last name Dru, as she says she'd married with Drupal.
http://3cyb.org/Links#Drupal_upgrade_.26_general_problems
http://3cyb.org/Links#Easier_checking.2Funchecking_modules_on_core_upgra...
Some nice issues going on; hope that the developers are aware of eachothers input and can bring the mod's together; or at least that they are adapted to -& take advantage of- eachother, with some integration.
I am not sure what
I am not sure what "node-modules" means, but uninstalling modules (in addition to disabling them) is impossible, out of the question, during any kind of upgrade. That could cause data loss.
I am curious to see any specific reference to an issue where disabling a module during a minor update was required.
If disabling and re-enabling the contributed modules is really necessary for minor upgrades, I would consider it a serious usability issue, even (indirectly) a security issue because people would tend to postpone updates for a better time.
It's the equivalent of a
It's the equivalent of a "Please shut down all running programs before installing this software" notice.
9/10 you will not notice any adverse side-effects. BUT there are some situations where it could tie itself in knots. If we knew in advance what those combinations were - then they may be able to be worked around -but in the meantime it's ???
Very broadly -
expect trouble with access control modules
expect trouble with modules that cache their internal settings heavily. (views is one)
Usually quite safe -
block feature modules
filters, editors
CCK & CCK fields.
Node enhancements (extra fields or settings, eg image_attach, location, event)
3rd party integration
Possibly problematic -
node-type modules - may produce scary undefined content/content-types until cache is flushed
Performance modules and admin that do things to the system pre or post-load. Odd things may happen actually during the upgrade process. Leading to an unusable half-upgrade.
color.module may produce unthemed output temporarily - you'll need to navigate to the themes setting page and it auto-corrects.
That list is probably not explanatory enough for the uninitiated to grok - but it's just my gut summary.
.dan.
if you are asking a question you think should be documented, please provide a link to the handbook where you think the answer should be found.
| http://www.coders.co.nz/ |
.dan. is the New Zealand Drupal Developer working on Government Web Standards
I would still like to see at
I would still like to see at least one specific issue where a minor upgrade with no API or database changes fails because a contributed module was enabled. Sometimes people blame one thing while the cause of the problem is different, for example a failure to complete update.php.
I think that the equivalent of "not shutting down all running programs" is "leaving the site online".
still an early version "contrib toggle"
I dont know why, but when trying contrib_toggle for the real thing; upgrading 6.8 to 6.9, it refused.
Well, it didn't refuse, it just started unchecking at modules with a, b, c ...oeps, there it unchecked itself and many other modules were not unchecked. Tried to bring it back, but with the same results. So I had to do that by hand. I think it were 6 times I had to go through my very extensive modules list;one depens on the other and cant be unchecked before unchecking the other and processing that request first. Especially parts of the e-commerce module had something like 5 dependencies in a line! So it was near an hour work, but bringing them back will be many hours work + new errors of conflicts can happen (if not brought back exactly the way it was; how can I remember with 300 chckings + another 300 throttle on or off, who remembers that??!), in which case it could be full working days to repair.
http://3cyb.org/Links#Easier_checking.2Funchecking_modules_on_core_upgra...
Related thread
A related thread: Is there a way to save your enabled modules when upgrading?
It's true that disabling modules is necessary only when upgrading between major versions, and not when updating between minor ones (see for instance this post from that thread).