25

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.

  • Is using drush acceptable? I found out the other day about drush config-export --skip-modules=devel. There might be something similar without using drush, but I do not know. – mradcliffe Feb 1 '16 at 17:28
  • So I'd have to do that every time I export the config? There has to be a better way :| – cambraca Feb 1 '16 at 18:06
  • Maybe you can add some config files to your .gitignore. – digitaldonkey Feb 4 '16 at 12:05
  • 1
    This is related: drupal.stackexchange.com/questions/185536/… – Les Lim Feb 5 '16 at 21:58
  • 1
    I think this question is too broad in retrospect. There are probably many good answers because it depends on what the build and development process is for the site. – mradcliffe Jan 23 '17 at 17:37
17
+250

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.

  • 1
    I really don't like having all the library dependencies for the devel module on my production servers, so I add it to composer using composer require --dev drupal/devel. Added bonus is that composer install is faster, making prod deploy faster. – Duncanmoo Sep 17 '18 at 8:09
5

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.

3

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.
  • You really shouldn't be using dev dependencies in this way. They are more for tools, such as code sniffer, that you wouldn't need to run in production. If they are enabled and Drupal is expecting the module to be installed and the code isn't there then this could lead to instability of the site. Drupal/Composer might still attempt to load a file that is not on the file system if it is a dev dependency. – Frank Robert Anderson Sep 14 '18 at 16:24
  • @FrankRobertAnderson you do not propose any better solution? I do not want devel module or dependent libraries on my production server, what do you propose? – Duncanmoo Sep 17 '18 at 8:11
  • Drupal doesn't really provide a good option for this. Your plan isn't horrible, but it will lead to issues if you are not careful. The issue I have with your plan is config_split becomes the pin that your whole site then hinges on. I would vote yours up if not for the dev dependency thing, which wasn't even a question in the OP. – Frank Robert Anderson Sep 17 '18 at 14:26
2

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.

1

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
1

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

1

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?

  • The Config Ignore module isn't suitable in this case. From the module page: Do not ignore the core.extension configuration as it will prevent you from enabling new modules with a config import. Use the Config Split module for environment specific modules. – bmunslow Apr 27 '18 at 13:20
1

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.
 */
1

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 the site WITHOUT your dev modules you say:

$ 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

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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