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

UPDATE: For Drupal 8.8+ and simple 2 environment configuration (dev,live) consider using the core config setting described in another answer by me below.

drush cex --skip-modules was removed in favor of config_split as explained in this issue thus the solutions here based on drush have not worked for me.

Here is the solution based on Duncanmoo solution using config_exclude module

1. Install config_exclude using Composer require --dev and configure it

$ composer require --dev drupal/config_exclude
$ drush en config_exclude -y
$ nano sites/default/setting.php

allow settings.php to be used on your local dev environment

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

Add config_exclude settings in local file

$ nano sites/default/setting.local.php

here is some sample settings

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

NOTE1: config_filter is a config_exclude dependency so if you don't need it production you can exclude it above

NOTE2: The settings.local.php is not a requirement. It depends on if is controlled by your VCS or not.

2. 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 site WITHOUT your dev modules you use:

$ composer install --no-dev

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

3. use drush cex as you normally use

$ drush cex 

will not not export any of the excluded modules settings

NOTE: I have noticed core.extension settings appear to have been modified after running the command above but the corresponding .yml 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 config_exclude module

Answer 4

Configuration Split 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.

https://www.drupal.org/project/config_split

Answer 5

For Drupal 8.8.0 and up there exists a core setting to exclude without any contrib modules needed.

Just add in your web/sites/default/settings.php or equivalent file

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

If you are using drush to import export configuration you will need drush 10+

drush cex

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

NOTE: For having more than 2 environments/configuration sets (dev, stage, live) this simple setting will probably not be enough. But for this simple case most other answers in here are probably outdated.

Answer 6

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 7

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 8

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 9

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 10

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 11

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.