4

What would be the best solution to enable/disable modules depending on the site environment (dev, stage or production)?

  1. Created a database dump containing the system table for each installation. Then when deploying I use mysql -uuser -ppass database < dump-<type>.sql where the type reflects the kind of environment.
  2. Created a shell script for each environment, that uses drush to enable or disable needed modules and set specific site settings.
  3. Wrote a small deploy script for each site that looks something like this:

    // change working directory to drupal installation path
    chdir('public_html');
    
    // define root, include bootstrap.inc and start drupal
    define('DRUPAL_ROOT', getcwd());
    require_once(DRUPAL_ROOT . '/includes/bootstrap.inc');
    drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
    
    // modules that should be disabled/enabled on stage site
    $modules = array(
       'field_ui' => 1,
       'toolbar' => 1,
       'update' => 1,
       'overlay' => 0,
       'feeds_import' => 0,
       'feeds_ui' => 0,
       'feeds' => 0,
       'menu' => 1,
       'advanced_help' => 1,
       'job_scheduler' => 1,
       'wysiwyg' => 1,
       'views_ui' => 1,
       'dblog' => 1,
    );      
    
    // enable/disable modules and set site specific variables
    foreach ($modules as $module => $state):
      if ($state == 1):
        if (!module_exists($module)):
          module_enable(array($module), FALSE);
        endif;      
      else:
        if (module_exists($module)):
          module_disable(array($module), FALSE);
        endif;
      endif;
    endforeach;     
    
    variable_set('error_level', ERROR_REPORTING_DISPLAY_ALL);
    variable_set('preprocess_css', 0);
    variable_set('preprocess_js', 0);
    variable_set('cache', 1);
    variable_set('page_compression', 0);
    variable_set('block_cache', 0);
    

Does anyone have a better solution?

6
+25

One possible answer is the Environment module (the 7.x dev release works just fine). It allows you to define arbitrary environments (comes configured with "Development" and "Production", but you can have more if necessary). It then provides drush environment-switch to switch between environments. You can then implement hook_environment_switch() to do anything you want when the environment is switched. There's no built-in support for enabling and disabling modules, but that's easy enough to do in code, as you demonstrate above. It's also convenient for doing things like changing variable values and blocking development users.

You then put something like drush environment-switch production in your deploy steps.

This also has the benefit of being able to switch back to Development easily. For instance, I have views_ui disabled in Production, but enabled in Development. If I need to urgently check a view in the ui on the production site, I can switch the environment to Development, do what I need, and switch back.

It's also nice that since it's implemented in hooks, you can keep different types of functionality in different modules, and you can keep these things in the code base and under version control.

  • This is essentially what we do, though we don't use the Environment Module. We have a standard global module we drop into every new project with a starter skeleton for this. See thirdandgrove.com/… – Justin Mar 17 '15 at 14:33
2

The Habitat module offers another option. Upon clearing the cache, specified modules are enabled and disabled based on a variable you set in settings.php

1

Use Drush make and other Installation profile utilities to create separate installation profiles.

  • I think the deploy process (It's not me managing this part) just moves the the content and the database to a different server, removes the cache files. Will I still be able to use an installation profile? – Cyclonecode Sep 20 '12 at 10:45
  • 2
    Installation profiles are only used during the initial installation. To move content, I use Node export. To move configuration changes, I use Features. – Oswald Sep 20 '12 at 11:02
1

Have a look at https://github.com/donquixote/drupal-drux

Create a number of "seed modules" with dependencies[] in the *.info file:

  • mysite_dependencies with shared dependencies
  • mysite_dev_dependencies with dependencies only for dev.
  • mysite_prod_dependencies with dependencies only for production (often this will be empty).
  • mysite_krister_dependencies for localhost stuff you don't want to see enabled in any other environment.
  • etc.

Now on each of production, dev and local, you only enable those seed modules applicable for this environment.

Drux provides a number of useful drush commands for this work flow, to fill the *.info files with dependencies[], and to enable the required modules after git pull:

drush obs mysite_dependencies mysite_dev_dependencies
drush obs-gen mysite_dependencies mysite_dev_dependencies
drush dep
drush dep-en

(see the github page / README.md)

1

I prefer to use the Master module and put all the dependencies in Features. Master module allows enabling and disabling modules specific to environments via Drush. With this and a few shell/drush scripts you should have everything you need.

-1

For Drupal 7 you can use Tadaa

Tadaa! is a module aimed at simplifying the process of enabling/disabling modules and altering configuration when switching between different environments, e.g. Production/Staging/Development.

The environments and the corresponding configuration is completely configurable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.