Automating Drupal module activation

When upgrading a large Drupal site between major revisions, I find myself doing the update over and over again. Since one site I maintain has 149 modules, and a few more that come packaged with other contrib that are not activated, I decided I don't want to click all those checkboxes every time I do a trial upgrade. While I could have probably come up with some way to just activate every module easily, I really wanted selective activation.

Thanks to Greasemonkey, a Firefox addon, I have automated the activation of all the modules I want.

First, make a list of all the modules you want to activate. You can do this by viewing the HTML source of your modules page and looking for the name of your modules in the form input fields named something like status[coder]. You'll just want the coder part. I recommend putting each module on its own line so if you change your mind on one module, you can just comment out that line.

var modules = new Array();
modules = Array(
// REMOVE DEVEL MODULES BEFORE LIVE LAUNCH
// Development
'coder',
'devel',
'reroute_email',
'cache_disable',
'simpletest',
// END DEVELOPMENT MODULES

// Core - optional
'help',
'menu',
'path',
'syslog',
'tracker',
'update',
// Other
'advanced_help',
'cvs_deploy'
);

The working part of the Greasemonkey script is a loop that examines the name of all the checkboxes on the page.

var chkboxes=document.getElementsByTagName('input');
for (var i=0; i < chkboxes.length; i++) {
  if (chkboxes[i].type=="checkbox" && in_modules(chkboxes[i].name, modules)) {
    chkboxes[i].checked=true;
  }
}

Then the part that finds the name of the module is similar to PHP's core in_array() function, with a change to wrap the status[] input array around the string of the module name you're searching for to activate. Remember, the name of each checkbox is actually something like status[coder], not just the module name as we have in the modules array at the start of the file.

function in_modules(needle, haystack) {
  var found = false, key;

  for (key in haystack) {
    if ('status[' + haystack[key] + ']' == needle) {
      found = true;
      break;
    }
  }
  return found;
}

The nice part about how this script works is that you can keep the same list of modules as you add modules back to your contrib modules directory during your upgrade. In the case of 149 modules, I have to activate them in groups when I add them back during the update.php process. First I activate and update core optional modules as a group, then cck, views, and workflow as a group, then two groups of the remaining contrib modules. I'm positive that I experience weirdness when activating and updating all 149 modules at the same time, especially with CCK widgets. Since in this process you're only checking the available checkboxes against a list of valid ones to check, there is no error if you have not yet added all the modules in your Greasemonkey array.

Best of all, you can be sure you're checking the correct checkboxes each time. Just be sure to make the included pages URL in your Greasemonkey configuration appropriate to your environment so you don't accidentally activate your development modules on your live site. It's a good idea to keep those development modules in a separate block for easy disabling when going to production.

The attached script should get you started with a long list of popular modules as an example.

Attachment	Size
example greasemonkey script for checking Drupal modules	2.28 KB

Submitted by deekayen on Sat, 02/21/2009 - 12:19am

deekayen's blog | Printer-friendly version

Great Trick! I can't believe

Submitted by SiNGH (not verified) on Thu, 04/30/2009 - 11:34am.

Great Trick! I can't believe nobody's ever said that!

For some minor updates, I'm too lazy to disable, & more importantly 'selectively' re-enable (after taking the time to make note of what's enabled), as this is painful. Now instead of skipping this step (AFTER backing up just in case ^_^), I don't mind doing it! Great news for me as this will avoid headaches & wasted time if things should go pear shaped.

BTW, a module is currently in development that will make this task a 1-click affair. It's called 'Contrib Toggle' (http://drupal.org/project/contrib_toggle)

It's still a work in progress. & is lacking some nice features like recording what modules are currently enabled (e.g. before update) in order to easily re-enable them with a single-click!, However this feature & many more are planned!

^_^

SiNGH

Oops!

Submitted by SiNGH (not verified) on Thu, 04/30/2009 - 11:37am.

I should add that I was refering to guix's past (Sat, 02/21/2009 - 7:47pm):

" open the modules page - open the modules page in a new tab - disable the contrib modules in this tab - in this tab go to update.php and process - go to the first tab, all the modules are still checked, just valid ;)

I'd take a process for disabling all the contrib modules at once, though ! "

or don't disable them at all

Submitted by pivica (not verified) on Sun, 02/22/2009 - 4:19am.

I know that Drupal readme.txt suggest that we should disable all contrib modules, replace old modules with new ones, run update.php and then enable all previously disabled modules.

But couple times in the past I just tried to skip boring part of disabling/enabling all contrib modules - just to see what will happen. And everything was fine. After that when doing upgrade I am always skipping disable/enable part and I never had any problems.

And if you think a little about it, this should be fine in most cases (skipping disable/enable part) - when you run update.php drupal will only load all enabled modules and then it will run all update functions it need to run.

Off course doing it in the right way (disabling/enabling contrib module) is the most safest way. But there is no harm to try without disable/enable part if you always do next two points before updating: - always backup your entire site and database. - bring your site to maintenance mode.

good if done correctly

Submitted by deekayen on Mon, 02/23/2009 - 4:11pm.

I don't specifically disable them anymore, but I do rename the modules directory. The next time bootstrapping tries to load the activated modules and doesn't find them, it'll toggle them to be off again. Then I add them back to the modules directory in groups and activate them as I go.

I'd take a process for disabling all the contrib modules at once, though !

Very nice trick! Now why

Submitted by bochokoy (not verified) on Thu, 03/12/2009 - 10:09am.

Very nice trick! Now why didn't I think of that before? Thanks for sharing this :)