In this article, by the authors, Stefan Borchert and Anja Schirwinski, of the book, Drupal 8 Configuration Management,we will learn the inner workings of the Configuration Management system in Drupal 8. You will learn about config and schema files and read about the difference between simple configuration and configuration entities.
(For more resources related to this topic, see here.)
The config directory
During installation, Drupal adds a directory within sites/default/files called config_HASH, where HASH is a long random string of letters and numbers, as shown in the following screenshot:
This sequence is a random hash generated during the installation of your Drupal site. It is used to add some protection to your configuration files. Additionally to the default restriction enforced by the .htaccess file within the subdirectories of the config directory that prevents unauthorized users from seeing the content of the directories. As a result, would be really hard for someone to guess the folder’s name.
Within the config directory, you will see two additional directories that are empty by default (leaving the .htaccess and README.txt files aside).
One of the directories is called active. If you change the configuration system to use file storage instead of the database for active Drupal site configuration, this directory will contain the active configuration. If you did not customize the storage mechanism of the active configuration (we will learn later how to do this), Drupal 8 uses the database to store the active configuration.
The other directory is called staging. This directory is empty by default, but can host the configuration you want to be imported into your Drupal site from another installation. You will learn how to use this later on in this article.
A simple configuration example
First, we want to become familiar with configuration itself. If you look into the database of your Drupal installation and open up the config table , you will find the entire active configuration of your site, as shown in the following screenshot:
Depending on your site’s configuration, table names may be prefixed with a custom string, so you’ll have to look for a table name that ends with config.
Don’t worry about the strange-looking text in the data column; this is the serialized content of the corresponding configuration. It expands to single configuration values—that is, system.site.name, which holds the value of the name of your site.
Changing the site’s name in the user interface on admin/config/system/site-information will immediately update the record in the database; thus, put simply the records in the table are the current state of your site’s configuration, as shown in the following screenshot:
But where does the initial configuration of your site come from? Drupal itself and the modules you install must use some kind of default configuration that gets added to the active storage during installation.
Config and schema files – what are they and what are they used for?
In order to provide a default configuration during the installation process, Drupal (modules and profiles) comes with a bunch of files that hold the configuration needed to run your site. To make parsing of these files simple and enhance readability of these configuration files, the configuration is stored using the YAML format.
YAML (http://yaml.org/) is a data-orientated serialization standard that aims for simplicity. With YAML, it is easy to map common data types such as lists, arrays, or scalar values.
Config files
Directly beneath the root directory of each module and profile defining or overriding configuration (either core or contrib), you will find a directory named config. Within this directory, there may be two more directories (although both are optional): install and schema.
Check the image module inside core/modules and take a look at its config directory, as shown in the following screenshot:
The install directory shown in the following screenshot contains all configuration values that the specific module defines or overrides and that are stored in files with the extension .yml (one of the default extensions for files in the YAML format):
During installation, the values stored in these files are copied to the active configuration of your site. In the case of default configuration storage, the values are added to the config table; in file-based configuration storage mechanisms, on the other hand, the files are copied to the appropriate directories.
Looking at the filenames, you will see that they follow a simple convention: <module name>.<type of configuration>[.<machine name of configuration object>].yml (setting aside <module name>.settings.yml for now). The explanation is as follows:
- <module name>: This is the name of the module that defines the settings included in the file. For instance, the image.style.large.yml file contains settings defined by the image module.
- <type of configuration>: This can be seen as a type of group for configuration objects. The image module, for example, defines several image styles. These styles are a set of different configuration objects, so the group is defined as style. Hence, all configuration files that contain image styles defined by the image module itself are named image.style.<something>.yml.
The same structure applies to blocks (<block.block.*.yml>), filter formats (<filter.format.*.yml>), menus (<system.menu.*.yml>), content types (<node.type.*.yml>), and so on.
- <machine name of configuration object>: The last part of the filename is the unique machine-readable name of the configuration object itself. In our examples from the image module, you see three different items: large, medium, and thumbnail. These are exactly the three image styles you will find on admin/config/media/image-styles after installing a fresh copy of Drupal 8. The image styles are shown in the following screenshot:
Schema files
The primary reason schema files were introduced into Drupal 8 is multilingual support. A tool was needed to identify all translatable strings within the shipped configuration.
The secondary reason is to provide actual translation forms for configuration based on your data and to expose translatable configuration pieces to external tools.
Each module can have as many configuration the .yml files as needed. All of these are explained in one or more schema files that are shipped with the module. As a simple example of how schema files work, let’s look at the system’s maintenance settings in the system.maintenance.yml file at core/modules/system/config/install. The file’s contents are as follows:
message: '@site is currently under maintenance. We should be back shortly. Thank you for your patience.' langcode: en
The system module’s schema files live in core/modules/system/config/schema. These define the basic types but, for our example, the most important aspect is that they define the schema for the maintenance settings. The corresponding schema section from the system.schema.yml file is as follows:
system.maintenance: type: mapping label: 'Maintenance mode' mapping: message: type: text label: 'Message to display when in maintenance mode' langcode: type: string label: 'Default language'
The first line corresponds to the filename for the .yml file, and the nested lines underneath the first line describe the file’s contents.
Mapping is a basic type for key-value pairs (always the top-level type in .yml). The system.maintenance.yml file is labeled as label: ‘Maintenance mode’. Then, the actual elements in the mapping are listed under the mapping key. As shown in the code, the file has two items, so the message and langcode keys are described. These are a text and a string value, respectively. Both values are given a label as well in order to identify them in configuration forms.
Learning the difference between active and staging
By now, you know that Drupal works with the two directories active and staging. But what is the intention behind those directories? And how do we use them?
The configuration used by your site is called the active configuration since it’s the configuration that is affecting the site’s behavior right now. The current (active) configuration is stored in the database and direct changes to your site’s configuration go into the specific tables. The reason Drupal 8 stores the active configuration in the database is that it enhances performance and security. Source: https://www.drupal.org/node/2241059.
However, sometimes you might not want to store the active configuration in the database and might need to use a different storage mechanism. For example, using the filesystem as configuration storage will enable you to track changes in the site’s configuration using a versioning system such as Git or SVN.
Changing the active configuration storage
If you do want to switch your active configuration storage to files, here’s how:
Note that changing the configuration storage is only possible before installing Drupal. After installing it, there is no way to switch to another configuration storage!
To use a different configuration storage mechanism, you have to make some modifications to your settings.php file.
First, you’ll need to find the section named Active configuration settings. Now you will have to uncomment the line that starts with $settings[‘bootstrap_config_storage’] to enable file-based configuration storage. Additionally, you need to copy the existing default.services.yml (next to your settings.php file) to a file named services.yml and enable the new configuration storage:
services: # Override configuration storage. config.storage: class: DrupalCoreConfigCachedStorage arguments: ['@config.storage.active', '@cache.config'] config.storage.active: # Use file storage for active configuration. alias: config.storage.file
This tells Drupal to override the default service used for configuration storage and use config.storage.file as the active configuration storage mechanism instead of the default database storage.
After installing the site with these settings, we will take another look at the config directory in sites/default/files (assuming you didn’t change to the location of the active and staging directory):
As you can see, the active directory contains the entire site’s configuration. The files in this directory get copied here during the website’s installation process. Whenever you make a change to your website, the change is reflected in these files.
Exporting a configuration always exports a snapshot of the active configuration, regardless of the storage method.
The staging directory contains the changes you want to add to your site. Drupal compares the staging directory to the active directory and checks for changes between them. When you upload your compressed export file, it actually gets placed inside the staging directory.
This means you can save yourself the trouble of using the interface to export and import the compressed file if you’re comfortable enough with copy-and-pasting files to another directory. Just make sure you copy all of the files to the staging directory even if only one of the files was changed. Any missing files are interpreted as deleted configuration, and will mess up your site.
In order to get the contents of staging into active, we simply have to use the synchronize option at admin/config/development/configuration again. This page will show us what was changed and allows us to import the changes. On importing, your active configuration will get overridden with the configuration in your staging directory. Note that the files inside the staging directory will not be removed after the synchronization is finished. The next time you want to copy-and-paste from your active directory, make sure you empty staging first.
Note that you cannot override files directly in the active directory. The changes have to be made inside staging and then synchronized.
Changing the storage location of the active and staging directories
In case you do not want Drupal to store your configuration in sites/default/files, you can set the path according to your wishes. Actually, this is recommended for security reasons, as these directories should never be accessible over the Web or by unauthorized users on your server.
Additionally, it makes your life easier if you work with version control. By default, the whole files directory is usually ignored in version-controlled environments because Drupal writes to it, and having the active and staging directory located within sites/default/files would result in them being ignored too.
So how do we change the location of the configuration directories?
Before installing Drupal, you will need to create and modify the settings.php file that Drupal uses to load its basic configuration data from (that is, the database connection settings). If you haven’t done it yet, copy the default.settings.php file and rename the copy to settings.php. Afterwards, open the new file with the editor of your choice and search for the following line:
$config_directories = array();
Change the preceding line to the following (or simply insert your addition at the bottom of the file).
$config_directories = array( CONFIG_ACTIVE_DIRECTORY => './../config/active', // folder outside the webroot CONFIG_STAGING_DIRECTORY => './../config/staging', // folder outside the webroot );
The directory names can be chosen freely, but it is recommended that you at least use similar names to the default ones so that you or other developers don’t get confused when looking at them later. Remember to put these directories outside your webroot, or at least protect the directories using an .htaccess file (if using Apache as the server).
Directly after adding the paths to your settings.php file, make sure you remove write permissions from the file as it would be a security risk if someone could change it. Drupal will now use your custom location for its configuration files on installation.
You can also change the location of the configuration directories after installing Drupal. Open up your settings.php file and find these two lines near the end of the file and start with $config_directories. Change their paths to something like this:
$config_directories[‘active’] = ‘./../config/active’;
$config_directories[‘staging] = ‘./../config/staging’;
This path places the directories above your Drupal root.
Now that you know about active and staging, let’s learn more about the different types of configuration you can create on your own.
Simple configuration versus configuration entities
As soon as you want to start storing your own configuration, you need to understand the differences between simple configuration and configuration entities. Here’s a short definition of the two types of configuration used in Drupal.
Simple configuration
This configuration type is easier to implement and therefore ideal for basic configuration settings that result in Boolean values, integers, or simple strings of text being stored, as well as global variables that are used throughout your site. A good example would be the value of an on/off toggle for a specific feature in your module, or our previously used example of the site name configured by the system module:
name: 'Configuration Management in Drupal 8'
Simple configuration also includes any settings that your module requires in order to operate correctly. For example, JavaScript aggregation has to be either on or off. If it doesn’t exist, the system module won’t be able to determine the appropriate course of action.
Configuration entities
Configuration entities are much more complicated to implement but far more flexible. They are used to store information about objects that users can create and destroy without breaking the code. A good example of configuration entities is an image style provided by the image module.
Take a look at the image.style.thumbnail.yml file:
uuid: fe1fba86-862c-49c2-bf00-c5e1f78a0f6c
langcode: en
status: true
dependencies: { }
name: thumbnail
label: 'Thumbnail (100×100)'
effects:
1cfec298-8620-4749-b100-ccb6c4500779:
uuid: 1cfec298-8620-4749-b100-ccb6c4500779
id: image_scale
weight: 0
data:
width: 100
height: 100
upscale: false
third_party_settings: { }
This defines a specific style for images, so the system is able to create derivatives of images that a user uploads to the site.
Configuration entities also come with a complete set of create, read, update, and delete (CRUD) hooks that are fired just like any other entity in Drupal, making them an ideal candidate for configuration that might need to be manipulated or responded to by other modules. As an example, the Views module uses configuration entities that allow for a scenario where, at runtime, hooks are fired that allow any other module to provide configuration (in this case, custom views) to the Views module.
Summary
In this article, you learned about how to store configuration and briefly got to know the two different types of configuration.
Resources for Article:
Further resources on this subject:
- Tabula Rasa: Nurturing your Site for Tablets [article]
- Components – Reusing Rules, Conditions, and Actions [article]
- Introduction to Drupal Web Services [article]
