Drupal configuration

Drupal's modular system allows for all kinds of additions to be added to your site through plugins, entities and configuration.

Thanks to Drupal's modular configuration system you can also inject custom configuration into existing configuration entities. This allows you to extend the functionality of an existing entity and ensure that any customisation are saved in the system configuration. Any configuration entity can be augmented without changing the existing configuration schema of the entity, which might cause knock on effects to other modules.

I'm not a fan of the summary option on body fields in Drupal. I've never really got on with how users interact with it or the content is produces.

The field type I'm talking about is called "Text (formatted, long, with summary)" and it appears as an add-on summary field to a normal content editor area. It comes as standard on Drupal installs and appears on all body fields. The field type has it's uses, but I often find that the content it produces is unpredictable and doesn't have a great editing experience. I have even written articles in the past about swapping the summary field to a fully fledged wysiwyg area for Drupal 7, which worked on the project I implemented it on.

Let's look at the body summary field in Drupal and see why I have a few problems with it.

Drupal configuration is normally changed or removed through the configuration import and export process. For example, the process I follow is to make the change in the configuration locally, export the configuration into the source code, deploy the source code to a remote server and import the configuration. Using this mechanism, configuration changes that were exported locally are imported into the site and are ready to use.

There are certain situations where using update hooks to update the configuration is necessary. This means that you would change the configuration in your system directly using code in update hooks, rather than following the export and import process. These situations are rare, but necessary from time to time in order to maintain a consistent configuration on your site.

Installing a Drupal site from configuration is useful when running tests or if you don't have a copy of the database. You'll get a copy of the Drupal site without any content that will act in the same way as the live site. You can use modules like default content to add content into the mix so your newly installed site acts a little bit more like the live version.

Since there are some prerequisites to get this up and running I thought I would run through what is needed to get this working and how to run it.

A change that was snuck into Drupal version 8.8.0 and wasn't mentioned in the 8.8.0 change notes was a small change to the setting that controls the placement of the configuration directories. The alteration deprecated the $config_directories setting from the settings.php file and move the configuration into the $settings array. You can see the detail behind this change on the Drupal change record.

The fix for this is very easy and only needs a single line of code to change in your settings file.

Change this:

$config_directories['sync'] = '../config/sync';

To this:

I recently wrote a post about setting up a multi-site configuration setup using the Configuration Split module. That post was written after I did research into how to set up configuration splits and use them to create multi-site setups in Drupal. One thing I realised when doing that research was that although it's quite easy to get setup with that kind of setup, it's also easy to get it wrong and create a setup that really doesn't work.

Setting up a Drupal 8 site for a multi-site environment with a common configuration isn't too hard, it just requires a little bit of forethought and some planning to get things right. You need to have a default configuration in mind, and then think about how each site can override this configuration in different ways. I have seen it done wrong a few times recently and once you go down the wrong path, getting things back in line again can be a difficult.

The default configuration covers things like content types, vocabularies, fields, views, enabled modules, or anything else that would make up the structure of the site. Each sub-site would override this by adding configuration for theme components, custom block placement, or anything else that is custom to that site.