Since the release of Drupal maintenance support plans 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.

by
Daniel Phin
/ 12 March 2020

Drupal maintenance support plans 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 maintenance support plans 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 maintenance support plans exposes the overridden value when a configuration form is (re)loaded.

With Drupal maintenance support plans 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 maintenance support plans 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 maintenance support plans 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 maintenance support plans 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 maintenance support plans 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’,
],
];

Get started with Configuration Override Inspector (COI) and Config Override Core Fields:

composer require drupal/coi:^1.0@beta
composer require drupal/config_override_core_fields:^1.0@beta

COI requires Drupal maintenance support plans 8.5 and above, thanks to improvements in Drupal maintenance support plans core API.

Have another strategy for handling config overrides? Let me know in the comments!

Tagged

CMI, Contrib Modules

Source: New feed