Closed (duplicate)
Project:
Drupal core
Version:
7.x-dev
Component:
system.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
9 Nov 2008 at 23:52 UTC
Updated:
19 May 2009 at 18:22 UTC
When upgrading between major Drupal releases, you have to switch to Garland, and disable all contrib modules. Disabling all contrib modules is a real pain - manually unchecking checkboxes, and then having to refresh the page for every level of dependencies.
So, I'm suggesting we add a checkbox to the maintenance settings page, to optionally disable all contrib modules and reset the theme to garland when you put your site into maintenance. We could also store a list of those modules in a variable and print them back to that page as a reference when you've finished the core upgrade.
This'd save quite a bit of time when doing an upgrade (re-enabling manually is sensible, and takes less time since you can do dependencies and required modules at the same time). Very, very useful for testing upgrade paths. Fairly useful for anyone who might have to upgrade more than one site.
Comments
Comment #1
lyricnz commentedWhere would you expose this saved-list of modules? Would it be "feature creep" to have a checkbox against each old module, so an upgrader could "check off" as they migrate/enable modules to the new version? And a "clear saved list" button.
Comment #2
catchI hadn't thought about where to expose the list yet - that was your idea in the first place in #drupal ;) A 'clear saved list' button - definitely. Checkboxes I'm less sure about.
Comment #3
kbahey commentedWhy not make that happen in update.php, when the initial button is pressed?
It would save the list of enabled non-core modules (a variable seems the easiest place), then turn on maintenance mode automatically.
After update.php is done, we give them the option to turn off maintenance mode (or just do it?)
Comment #4
catchWe'd need to re-enable modules when this is done on a minor version upgrade - 6.5-6.6. Additionally, we'd also need to ensure that if you don't have a certain contrib module installed when upgrading from d7-d8 that your site wouldn't get hosed hitting update.php in the first place (like a WSOD on update.php itself).
Comment #5
sunAs stated in #173570: Add link to disable non-required core modules for upgrading, disabling modules has no effect to the upgrade. Module updates are executed anyway.
However, +1 for the proposed idea in general.
Comment #6
guillaumeduveauVery good idea, I hope this makes it for D7 !
But is it really a good thing that the disabled module still update ?
Comment #7
catch@sun, thanks for the reminder, I even reviewed that D6 patch.
Opened #450540: Upgrade instructions recommend enabling stark in D6 since we should really fix the upgrade docs.
Comment #8
catchAlso - there's probably still some valid use cases for disabling all contrib modules in one go - i.e. for troubleshooting, and I think CCK requires certain modules to be re-enabled in a particular order for 5-6. So we might still want to do this - but need to clarify exactly why.
@guix - if you use a module in Drupal 5, then disable it, then switch it on again in Drupal 7 - then you'll lose a year or two's worth of updates - so to prevent serious database inconsistencies we started running updates for disabled modules.
Comment #9
guillaumeduveau@catch : Thanks, indeed I forgot the updates that are kept in each module are only for one stable Drupal release !
Comment #10
sunSome time ago, I started to work on an Upgrade Assist module (that ships with http://drupal.org/project/upgrade_status), and in the meantime, I've thought about turning it into a upgrade.php that needs to be placed in Drupal's root directory.
The new Direct Acyclic Graph (DAG) maths that core performs in D7 to calculate module requirements will prevent the mess we had with D6 though -- recursive dependencies are handled properly now, so updates that must come first, do come first in D7.
Comment #11
catchThis is a duplicate of #249609: Prepare for upgrade button