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.
11 Answers
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:
- Split off some configuration to dedicated folder
- Blacklist configuration
- Ignore a set of configuration
- 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.
-
2I 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. Sep 17, 2018 at 8:09 -
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.
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
-
I had very similar experience as @GiorgosK following suggestions above. This solution worked perfectly for me and contains well thought out advice as well. I also noticed core.extension false negatives but it did indeed NOT change status for git so all is well. Thanks– vrwiredJan 30, 2019 at 22:58
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.
-
1+1 for config split, I always use that to have Devel and other modules like Field UI and Views UI disabled in prod. See Disable modules using config split.– leymannxJan 31, 2019 at 9:16
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.
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.
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:
- Main site config (enabled everywhere; dev and staging and production)
- Staging config (enabled in dev and staging) - includes reroute email module
- Dev config - includes devel, kint... but not reroute email as that comes with having the staging config enabled in dev.
-
1You 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. Sep 14, 2018 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? Sep 17, 2018 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. Sep 17, 2018 at 14:26
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
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.– bmunslowApr 27, 2018 at 13:20
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.
*/
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
- Remove devel related configuration yaml files
- Add
$settings['config_exclude_modules'] = ['devel'];
to your settings.php or, even better, your settings.local.php.
drush
acceptable? I found out the other day aboutdrush config-export --skip-modules=devel
. There might be something similar without using drush, but I do not know.