How to prevent Devel module to be installed on production environments

Question

Using the new Drupal 8 Configuration manager, how can I prevent it from installing the Devel module on certain environments? As far as I know, installing it on my local means the next time I export the configuration and move it to my other environments (dev, test, prod), it will automatically be enabled.

Answer 1

Method: Drush

• Drush can ignore the enabled states of extensions when synchronizing configuration.

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• With Drush CMI tools you can operate with a list of configuration to ignore.

  drush cexy --ignore-list=/path/to/config-ignore.yml

  drush cimy --delete-list=/path/to/config-ignore.yml

Method: Modules

• You can use the Configuration Split module that allows you to:

  1. Split off some configuration to dedicated folder
  2. Blacklist configuration
  3. Ignore a set of configuration
  4. Configured by configuration entities

• Configuration Read-only mode module

  This module allows to lock any configuration changes done via the Drupal admin UI. This can be useful in scenarios where for example configuration changes should not be done on the production environment, but only on staging or local environments.

  $settings['config_readonly'] = TRUE;

• And another module is the Environment Config that allows you to override configuration on a per-environment basis.

Answer 2

Update: The feature described below was removed lately https://www.drupal.org/project/config_split/issues/2926505

---

If you are using drush in your deployment process you can do the following:

Create a drushrc.php file in the same directory as your settings.php (for example: docroot/sites/default) and put the following:

$drush_ignore_modules = array(
  'devel',
  'webprofiler',
  'devel_generate',
  'kint',
  'yaml_editor',
);

$command_specific['config-export']['skip-modules'] = $drush_ignore_modules;
$command_specific['config-import']['skip-modules'] = $drush_ignore_modules;

This means, that you can manipulate the drush cex / drush cim commands to skip modules, during their process.

You can read more about Using the Configuration Module Filter in Drush 8.

Answer 3

For Drupal 8.8.0 and higher releases, there is a core setting to exclude configuration values without using any contributed module.

Just add the following line in your web/sites/default/settings.php file.

$settings['config_exclude_modules'] = ['devel', 'webprofiler'];

If you are using Drush to import/export configuration, you will need Drush 10+.

Run drush cex.

Read more on the change record, the documentation, or a discussion with people having problems using it.

NOTE: For more than two environments / configuration sets (dev, stage, live), this simple setting will not probably be enough.

drush cex --skip-modules was removed in favor of the Configuration Split module as explained in drush cex --skip-modules was removed in favor of config_split, but config_split is not feature-equivalent; thus, the solutions based on Drush have not worked for me.

For Drupal releases before Drupal 8.8.0, this the solution I suggest.

• Install the Config Exclude module using composer require --dev, and configure it.

• Add the following lines in the settings.php file.

  if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
    include $app_root . '/' . $site_path . '/settings.local.php';
  }
  

• Add the Config Exclude module settings in the settings.local.php file, for example the following lines.

  $settings['config_exclude_modules'] = [
    'devel', 
    'config_exclude',
    'config_filter',
    'stage_file_proxy',
  ];
  

  The settings.local.php is not a requirement.

• Require the modules you need on the development environment with composer require --dev (for example, composer require --dev drupal/devel). To install the site without the development modules, you use composer install --no-dev. (On your staging and production environments, you should always use --no-dev.)

• Use drush cex as you would normally do. It will not not export any of the excluded modules settings.

###Note

I have noticed that the core.extension settings appear to have been modified after running the command above, but the corresponding .yml file is never written on the hard drive (even after confirming will be deleted and replaced with the active config), so there is nothing to be commited. I guess it depends on the internals of the Config Exclude module.

Answer 4

The Configuration Split module might be a viable solution for some.

The Drupal 8 configuration management works best when importing and exporting the whole set of the sites configuration. However, sometimes developers like to opt out of the robustness of CM and have a super-set of configuration active on their development machine and deploy only a subset. The canonical example for this is to have the devel module enabled or having a few block placements or views in the development environment and then not export them into the set of configuration to be deployed, yet still being able to share the development configuration with colleagues.

Answer 5

There's an interesting issue for Drupal 8.3.x: Allow development modules to opt out of config-export. The general concensus is that Configuration Split is currently the best solution.

Comment by swentel:

Just wanted to briefly document how config_split works: The config split config entity defines what is blacklisted, allowing you to blacklist modules and/or config objects. The canonical example, being devel, already has an interesting use case: it comes with system.menu.devel which, in case you blacklist devel, the menu config file will not be removed since there's no dependency. While it's not a major problem, config split allows you individually select that as well so it's removed on the environment.

Comment by geerlingguy:

I've tried a few different methods of managing environment-specific config, and config_split seems to hit the right usability vs. extra overhead balance the best so far. It's simple and lightweight, but allows me to mark (and continue to use) certain configuration only in certain environments.

Answer 6

There is a neat way of doing this, where you end up with your dev modules committed in composer for convenience and those modules' config is not added to your config export (there are 2 parts):

1. Composer require --dev When enabling a module which is purely for development then use the --dev flag:

$ composer require --dev drupal/devel

This results in those dependencies being added into the composer.json file under require-dev:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

So if you install the the site WITHOUT your dev modules you say:

$ composer install --no-dev

NB: On your staging and prod environments you should always do --no-dev

2. Use the config_split module

Configuration split module allows you to create groupings of configuration export which can be enabled or disabled in an environment.

I actually have 3 splits:

1. Main site config (enabled everywhere; dev and staging and production)
2. Staging config (enabled in dev and staging) - includes reroute email module
3. Dev config - includes devel, kint... but not reroute email as that comes with having the staging config enabled in dev.

Answer 7

I made a small script to do it all in one shot.

#!/bin/bash

drush pm-uninstall devel -y
drush pm-uninstall field_ui -y
drush pm-uninstall field_name_prefix_remove -y

drush config-export

drush en devel -y
drush en field_ui -y
drush en field_name_prefix_remove -y

Answer 8

You can also see Config Ignore module.

This module is a tool to let you keep the configuration you want, in place.

Lets say that you do would like the system.site configuration (which contains that sites name, slogan, email, etc) to remain untouched, on your live site, no matter what the configuration, in the export folder says.

Or maybe you are getting tired of having the devel.settings changed every time you import configuration?

Answer 9

You can use a deployment override module for this. Read the following link for detailed description:

http://dcycleproject.org/blog/46/continuous-deployment-drupal-style

However, Best way to do this would be to disable your module on local and then export the configuration.

Drupal provides a way to override the configuration settings in settings.php, but they are not valid for disabling/enabling modules.

From default.settings.php:

/**
 * Configuration overrides.
 *  * To globally override specific configuration values for this site,
 * set them here. 
 * 
 *
 * blah..blah...blah
 *
 *  
 * There are particular configuration values that are risky to override. For
 * example, overriding the list of installed modules in 'core.extension' is not
 * supported as module install or uninstall has not occurred. Other examples
 * include field storage configuration, because it has effects on database
 * structure, and 'core.menu.static_menu_link_overrides' since this is cached in
 * a way that is not config override aware. Also, note that changing
 * configuration values in settings.php will not fire any of the configuration
 * change events.
 */

Answer 10

Introduced in Drupal 8.8 there is a setting for that: How does the new config_exclude_modules setting work exactly?

To have the devel module excluded you

1. Remove devel related configuration yaml files
2. Add $settings['config_exclude_modules'] = ['devel']; to your settings.php or, even better, your settings.local.php.