Since the release of Drupal 8, it has become tricky to determine what and where override configuration is set.
Here are some of the options for a better user experience.
Drupal allows you to override configuration by setting variables in
settings.php. This allows you to vary configuration by which environment your site are served. In Drupal 7, when overrides are set, the overridden value is immediately visible in administration UI. Though the true value is transparent, when a user attempts to change configuration, the changes appear to be ignored. The changes are saved and stored. But Drupal exposes the overridden value when a configuration form is (re)loaded.
With Drupal 8, the behaviour of overridden configuration has reversed. You are always presented with active configuration, usually set by site builders. When configuration is accessed by code, overrides are applied on top of active configuration seamlessly. This setup is great if you want to deploy the active configuration to other environments. But it can be confusing on sites with overrides, since its not immediately obvious what Drupal is using.
An example of this confusion is: is your configuration forms show PHP error messages are switched-on, but no messages are visible. Or, perhaps you are overriding Swiftmailer with environment specific email servers. But emails aren't going to the servers displayed on the form.
A Drupal core issue exists to address these concerns. However this post aims to introduce a stopgap. In the form of a contrib module, of course.
Introducing Configuration Override Inspector (COI). This module makes configuration-overrides completely transparent to site builders. It provides a few ways overridden values can be exposed to site builders.
The following examples show error settings set to OFF in active configuration, but ON in overridden configuration. (such as a
local.settings.php override on your dev machine)
// settings.php $config['system.logging']['error_level'] = 'verbose';
Hands-off: Allow users to modify active configuration, while optionally displaying a message with the true value. This is most like out-of-the-box Drupal 8 behaviour:
Expose and Disable: Choose whether to disable form fields with overrides display the true value as the field value:
Invisible: Completely hide form fields with overrides:
Unfortunately Configuration Override Inspector doesnt yet know how to map form-fields with appropriate configuration objects. Contrib module Config Override Core Fields exists to provide mapping for Drupal core forms. Further documentation is available for contrib modules to map fields to configuration objects. Which looks a bit like this:
$config = $this->config('system.logging'); $form['error_level'] = [ '#type' => 'radios', '#title' => t('Error messages to display'), '#default_value' => $config->get('error_level'), // ... '#config' => [ 'key' => 'system.logging:error_level', ], ];
composer require drupal/coi:^1.0@beta composer require drupal/config_override_core_fields:^1.0@beta
COI requires Drupal 8.5 and above, thanks to improvements in Drupal core API.
Have another strategy for handling config overrides? Let me know in the comments!
Where to run 'composer require' command if using distribution? There are 2 places where you find modules. One is the web folder containing contrib modules and second is the profile folder containing custom modules.
This post assumes you are running a Composer based site, which we'd recommend. The topic is much larger than this individual post, the Using Composer to Install Drupal and Manage Dependencies article on Drupal.org is a good starting point.