Drupal Planet

PreviousNext: Configuration Override Inspector: Removing the Config Confusion

6 dni 1 godzina ago

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.

by Daniel Phin / 12 March 2018

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', ], ];

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 8.5 and above, thanks to improvements in Drupal core API.

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

Tagged CMI, Contrib Modules

Jeff Geerling's Blog: Two MidCamp Sessions: Local Dev for Dummies, Jenkins and Drupal

6 dni 1 godzina ago

MidCamp 2018 wrapped up with a bang today, as there was another year full of great training, sessions, and my favorite aspect, the 'hallway track' (where you go around and network between and during some sessions with tons of excellent Drupalists from the Midwest and around the country).

This year, I presented two sessions; one a co-presentation with Chris Urban titled Local Dev Environments for Dummies, the other a solo presentation titled Jenkins or: How I learned to stop worrying and love automation.

Embedded below are the video recordings of the sessions (recorded as always by the excellent Kevin Thull of Blue Drop Shop!):

Dries Buytaert: That "passion + learning + contribution + relationships" feeling

6 dni 3 godziny ago

Talking about the many contributors to Drupal 8.5, a few of them shouted out on social media that they got their first patch in Drupal 8.5. They were excited but admitted it was more challenging than anticipated. It's true that contributing to Drupal can be challenging, but it is also true that it will accelerate your learning, and that you will likely feel an incredible sense of reward and excitement. And maybe best of all, through your collaboration with others, you'll forge relationships and friendships. I've been contributing to Open Source for 20 years and can tell you that that combined "passion + learning + contribution + relationships"-feeling is one of the most rewarding feelings there is.

Matt Glaman: Flush and run, using Kernel::TERMINATE to improve page speed performance

6 dni 10 godzin ago
Flush and run, using Kernel::TERMINATE to improve page speed performance mglaman Sun, 03/11/2018 - 11:00

At DrupalCon Dublin I caught Fabianx’s presentation on streaming and other awesome performance techniques. His presentation explained how BigPipe worked to me, finally. It also made me aware of the fact that, in Drupal, we have mechanisms to do expensive procedures after output has been flushed to the browser. That means the end user sees all their markup but PHP can chug along doing some work without the page slowing down.