Drupal upgrade instructions always say to disable all non-core modules before the upgrade and then to enable them again afterwards. If you have a lot of modules this is a real pain, especially because of dependencies many can't be enabled or disabled until others are first enabled or disabled. Not to mention the chances to make a mistake!

I'm unskilled at Drupal, at Drush, and at shell scripting, but nontheless I made a couple shell scripts that use Drush to disable or re-enable all my non-core modules. These scripts are guaranteed to be buggy and slipshod, so before you play with them back everything up and check that your life-insurance policy is up to date. Seriously, I'd love to get feedback about how to make these better, but they seem to work for me with my Drupal 6.13 system running on Ubuntu 8.10 (Ibex).

These scripts assume that Drush 2.0 is installed and running and that your Drupal root is at /var/www and that you are working with Drupal 6. Actually, the scripts probably assume a lot of other stuff too, but I'm too dumb to even know what.

Disable Script

The first script disables all the non-core modules. It uses the Drush "statusmodules" command which returns ALL modules, including the core ones - and woe be to you if you disable the core modules. So the script gets the list of all modules, then removes the 5 core modules (Block, Filter, Node, System, and User) from the list. Then it prepends the "drush disable" command to the front of the list, and saves that whole thing as a new shell script, makes the script executable, and then executes it.

cd /var/www
drush statusmodules --pipe  >originalmodulelist.txt

sed -e 's/ block / /g'  -e 's/ filter / /g' -e 's/ node / /g' -e 's/ system / /g' -e 's/ user / /g' originalmodulelist.txt >trimmedmodulelist.txt
sed 's/^/drush disable /' trimmedmodulelist.txt >disablemodules
sudo chmod 777 disablemodules
sudo ./disablemodules

Re-Enable Script

The second script is even simpler. It makes a copy of the shell script created by the Disable Script, changes the "drush disable" command to be "drush enable" and then pulls the same dopey trick of creating a new shell script and executing it. If for some reason you have lost or moved the earlier script you will be out of luck.

cd /var/www
sed 's/disable/enable/' disablemodules  >reenablemodules
sudo chmod 777 reenablemodules
sudo ./reenablemodules

My wish is that someone who knows what they are doing would help me to improve these scripts (and the instructions) to the point where they could be placed in the Documentation part of drupal.org.

Comments

xlyz’s picture

generate list

drush statusmodules -p | sed -e 's/\<block //g' -e 's/\<filter //g' -e 's/\<node //g' -e 's/\<system //g' -e 's/\<user //g' > modulelist.txt

disable

drush disable `cat modulelist.txt`

enable

drush enable `cat modulelist.txt`

enjoy

steve02476’s picture

That looks great, thanks, I'll try it out. -Steve

xlyz’s picture

btw, to put your site in maintenance mode:

drush eval 'variable_set('site_offline', 1)'

and to put it back on line

drush eval 'variable_set('site_offline', 0)'
moshe weitzman’s picture

Status:Active» Postponed (maintainer needs more info)

not sure what needs doing here.

xlyz’s picture

Category:support» task
Status:Postponed (maintainer needs more info)» Needs work

maybe put a note in the docs?

ChrisRut’s picture

:subscribe:

steve02476’s picture

Since I posted this, should I do something to "close" it? I don't know what's expected.

moshe weitzman’s picture

Status:Needs work» Closed (won't fix)

Such a rare event. Please add drush integration to the module that does this (I forget the name).

nedjo’s picture

See http://drupal.org/project/contrib_toggle (which looks to be discontinued for reasons noted on the module's page).

protoplasm’s picture

I couldn't get the methods in #1 to work. I believe it may because drush itself has changed.

You can drush pm-enable a list of modules separated by spaces, but with about 290 non-core modules this is more difficult than just checking things off. It would be nice if there was a method to extract the code names for the enabled non-core modules on the current site (maybe I missed something?). Not seeing a command to do that, I went to the update.php page, selected & copied my listing, removed the ' module:' with a replace command in a word processor and then replaced paragraph formatting with a space and that gave me a space separated list of most of my modules I wanted to enable. It worked for most. I got a couple of errors where it didn't work, but it did save me lots of time and enabled most of the files for me.

After almost 4 years, I decided yesterday to learn drush and boy-oh-boy it is a time saver for updating modules. Again, the only problem is finding the code names for the modules. Since I work off the update status page to upgrade my module versions, I kind of wish that 'they' would print out the code names for the file directly on that page.

Anyways, hats off to the developer(s) of drush. What an amazing tool!

protoplasm’s picture

Thanks for your reply. "mysql> select name from system where type = 'module' and status = 1 order by name"... Fantastic.

(The article is also on server bloat. It's a tribute to drupal that even with all the modules (I'm including the modules within modules in my count) and thousands of pages, pictures, and users--the site is reasonably responsive. The bloat does need to go).

Thanks again!

ben4asterisk’s picture

Links at post 13 by xjm explain getting a list of all the enabled modules.
drush pm-list --pipe --type=module --status=enabled

Again this works fine for getting all enabled modules including Core-required modules. Going by the recommended way of upgrading, it would be good to disable all non-Core-required modules.
drush pm-list --type=module --package="Other"
can be used to get a list of all package types. But this is painful to list different types.
It would be good if drush has a feature to not include certain packages. I am not sure if such a thing already exists.

So as of now, am using this script to disable all non-Core-required modules (slight change in the scripts above).
#] drush pm-list --type=module --status=enabled | awk '/\(/ && /\)/ && ! /[Cc]ore.*-.*[Rr]equired/' | sed 's/.*(\(.*\)).*/\1/' > ModulesWoutCore
#] drush pm-disable `cat ModulesWoutCore`

Enable back when rest of upgrade is complete.
#] drush pm-enable `cat ModulesWoutCore`

HIH for ppl who are looking for this.

xjm’s picture

Re: #14, I proposed an option for this (without all the awk craziness) in #888480: drush pm-list: way to exclude rather than include a package (patch available there), but it was marked "won't fix." If you'd like a simpler way of excluding packages, I'd say follow up on that issue.

alecis’s picture

Here is my version without awk (also i really don't like backticks...) and it generates a sorted list, which is nicer for checking the list before firing the disable part:

drush pm-list --type=module --status=enabled | sed '/\((.*)\)/!d;/[Cc]ore.*-.*[Rr]equired/d;s/.*(\(.*\)).*/\1/' | sort > noncoremod.txt
drush pm-disable $(cat noncoremod.txt)
drush pm-enable $(cat noncoremod.txt)
drupalpeter’s picture

Great! Thanks - this will probably save me a lot of headaches.

pumpkinkid’s picture

Might be good to note that this also disables the Core Optional modules...

This would only disable everything not included in core (which is what is needed for Drupal Upgrades).

drush pm-list --type=module --status=enabled | sed '/\((.*)\)/!d;/[Cc]ore.*-.*[Oo]ptional/d;s/.*(\(.*\)).*/\1/' | sort > noncoremod.txt

Note that you will get a notice that says some modules are "a required module and can't be disabled." This should be fine.

eosrei’s picture

Disable non-core in one line with:

drush pml --no-core --type=module --status=enabled --pipe | xargs drush -y dis
BassPlaya’s picture

I've tried #16 and #18 on a Drupal 6 install with drush_version=4.5 and those worked for me!
Thanx!

aiphes’s picture

#19 works like a charm

rurri’s picture

#19 worked great although I would definitely send the module list to a file first.

drush pml --no-core --type=module --status=enabled --pipe > modules.txt
xargs -a modules.txt drush -y dis
xargs -a modules.txt drush -y en
Kyle Skrinak’s picture

Mac Lion's xargs (as does BSD's) lacks the --arg-file (-a) parameter. This worked for me on Mac:

(first command as is)
cat modules.txt | xargs drush -y dis #since you can batch uninstall no problems
cat modules.txt | xargs -L 1 drush -y en #may choke without the "one line at a time" command

If you run the drush disable command one at a time, (-L 1) you could prevent dependent modules, later in the list, from uninstalling. It seems passing module list as a batch is both quicker and more effective.

HighwayofLife’s picture

There may be some modules which don't properly get enabled (or disabled). If you use `xargs`, it will die before properly enabling/disabling all of these modules.
Instead, you could use a for loop, though this will take longer:

drush pml --no-core --type=module --status="disabled,not installed" --pipe > modules.txt
for module in `cat modules.txt`; do drush -y en $module; done

Why enable all modules, you ask? One of our CI boxes needed to enable all modules so that we could run the update module against all our modules we provide so that we can easily determine if we need to take any module updates. I would NEVER recommend or condone the enabling of all modules on a production system.