Search icon
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Learning Hub
Free Learning
Arrow right icon
Over 7,000 tech titles at $9.99 each with AI-powered learning assistants on new releases
Drupal 8 Configuration Management
Drupal 8 Configuration Management

Drupal 8 Configuration Management:

$25.99 $9.99
Book Mar 2015 148 pages 1st Edition
$25.99 $9.99
$15.99 Monthly
$25.99 $9.99
$15.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now
Table of content icon View table of contents Preview book icon Preview Book

Drupal 8 Configuration Management

Chapter 1. Understanding Configuration Management

In this first chapter, we will give you a quick overview of Drupal 8's hottest new feature: Configuration Management. You will learn what types of configuration exist, why managing configuration is a good idea, and how to get started with it. We will introduce you to version control and show some best practices. We will also provide a look at the several ways in which configuration was managed in Drupal 7, and then show how Drupal 8 approaches the problem.

An introduction to Configuration Management

The general definition of the term "Configuration Management" is somewhat different from the definition of Configuration Management in Drupal 8. To make things easier, we will focus on explaining what Configuration Management is in Drupal terms.

Configuration Management in Drupal 8 aims at making configuration manageable across different environments by allowing us to store configuration in files instead of the database.

Let's start by defining what configuration is, and what other types of information exist in Drupal 8.


Configuration is the information about your site that is not content and is meant to be more permanent, such as the name of your site, the content types, fields, and views you have defined.


Content is the information meant to be displayed on your site, such as articles, basic pages, images, files, and so on.


This is the information about an individual user's interactions with the site, such as whether they are logged in.


This is information of a temporary nature about the current state of your site. Examples include the time when Cron was last run, whether node access permissions need rebuilding, and so on.

Why manage configuration?

It's simple to explain why configuration that is only saved in the database is bad. You can't keep track of any changes (who made what change, and when); it's hard to work with a group of people (you simply can't get their changes without using their SQL dump, and using their dump would delete your work); and, if you build something on a development environment, how do you get it to the live site? You get the gist. We want our configuration in files, and Drupal 8 gives us just that.

Before Drupal 8, a variety of methods were used to transport configuration from one environment to another—for example, from a development environment to a production environment.

These included some rather bad methods such as writing down the process to manually recreate the same configuration, which is error-prone; dumping the development database in the live site, which loses all content created in the meantime; and some better but rather time-consuming methods, such as writing update hooks or using the contributed module Features to export configuration to a module. The latter is one of the most used methods in Drupal 7 because it works well most of the time, produces well-arranged files, and can be used without having to write any code, which is good because anyone can create a Feature without having to know how to code.

Even though you can use the new Configuration Management system without a version control system such as Git, it's at its best when used with one. Version-controlling your configuration allows you to track document changes. Later in this chapter, we will show you how to get the best out of version-controlling your configuration. Version-controlled Configuration Management is crucial to developing and maintaining quality in a Drupal project, especially when working with a team of developers. Exposing all developers to the same code and providing a history for the code increases efficiency a lot.

At first, it might seem frustrating to have to learn something new. However, software tends to change over time, and changes are hard to track using just your memory. This is really one of the best ways to improve your project and save your time and money, so make sure you learn it!

Tracking configuration changes

Drupal 8's new Configuration Management system can be used without a version control system, but if you want to really improve your process, you should use it in combination with version control. Having organized and versioned code helps prevent mistakes and duplicated efforts between multiple developers; it serves as documentation of the project's history and can show who worked on what and, very importantly, why.

There are others, but we are going to talk about Git as our example version control tool because it's used by the Drupal community and offers everything we need in terms of functionality, scalability, and ease-of-use.


Use a version control tool such as Git to get the best out of the Configuration Management system!

The best time to start with versioned Configuration Management is at the beginning of the development. However, it's never too late, even if your project has been started or even finished for a while. Check your Drupal site configuration, organize it, and put everything in a Git repository. Now, you have a good starting point from which to manage and document any changes that will be made to the project in the future.

Some version control best practices

So let's see what will really improve the development process when using version control.

Using a project management tool

You will achieve the best results if you put your work tasks in a project management tool such as the free and open source tool Redmine. If you're not used to working with a project management tool, it might take some discipline to keep track of your work this way, but it has so many advantages. The ticket holds information about what needs to be done and you can use the ticket's comments to discuss requirements, give status updates, or report problems.

Most project management tools also have some sort of ID for each ticket. You can use the ticket ID in your Git commit messages, which is a very good way to know why a commit was made.

Meaningful commit messages

Commit messages are a very important part of your code documentation when working with version control. When looking for something that was done in the past, you will first scan through the commit messages, as shown in the following screenshot:

It makes no sense at all to just use a commit message such as stuff or even asdf. You might laugh, but we've seen both of these in real-world projects. When you start out with version control, it will take some discipline to write meaningful commit messages, but it's really worth it when you come across a bug and are looking for code that might have caused it. Make sure you always use the ticket ID that your project management tool provides and put it at the beginning of your commit message. When you find the commit that causes the problem, the ID will give you more information about what was done there and for what reason.


Small and well-structured commits are more effective.

Also, make commits small! Do not wait until your workday is over to commit everything you did on that day. This will make it more difficult to go through the changes in that specific commit. For example, make each new contributed module you add to your project a separate commit; do not add 5 modules at once or a module together with other code or configuration.

Meaningful branches

Tickets that require a lot of work should be worked on in a separate branch. When you name that branch, make sure you use your ticket ID at the beginning—for instance, 1234-publications, as shown in the following screenshot:

A look back at Drupal 7

Configuration Management in Drupal 7 isn't as simple as its equivalent in Drupal 8. In Drupal 7, almost the entire configuration set on a site is stored in the database by default. This includes simple variables, content types and field configuration, settings from custom or contributed modules, and so on.

Using the database to store settings makes it really hard to track configuration changes or roll back a bunch of settings to a state defined earlier.

Unfortunately, there is no real standard for Configuration Management in Drupal 7, but there are several ways to manage site and module settings in the code.

We will take a short look at the following five different approaches:

  • Manual Configuration Management

  • The hook_install() / hook_update_N() function

  • The Features module

  • The Configuration Management module

  • Storing configuration variables in settings.php

Manual Configuration Management

Many users of Drupal manage their configuration manually. They try to remember each setting they've made in the local development environment and then recreate every step on the live site. At first sight, this seems to be very fast and easy, but if you have to manually set permissions for some roles multiple times, you'll never want to do this manually again after hearing there are much better ways.

Additionally, you will never know if a setting has changed and all of your configuration will not be version-controlled (because it only exists in the database). Also, it makes working in a team much more painful than necessary.

If you ever want to share configuration between two or more instances of a site, don't do this.


Don't use manual Configuration Management!

The hook_install()/hook_update_N() function

Install and update hooks are the simplest way to manage configuration on a Drupal 7 site in code. The basic idea behind this approach is to set configuration values while installing a module or running update.php. Within the .install file of a custom module, you implement hook_install() and/or hook_update_N(), and add the code needed to set the configuration to these functions:


 * Implements hook_install().
function my_module_install() {
  // Set site name.
  variable_set('site_name', 'Configuration Management');

In this example, we simply set the variable site_name to the Configuration Management value, so the name of our site will be updated to this value after enabling the module. The possibilities given here are nearly endless. In addition to setting simple variables, you might add new roles, update block settings, or even create new content types. However, while it's technically possible, it is not recommended and not very simple to export complex configuration (think of fields or views). Also, you need a developer to actually write the code.

Unfortunately, this is one-way configuration management, so there is no way to automatically save changes that you have made on the site's configuration back to code. You have to update the code manually with the new settings (for example, add a new implementation of hook_update_N()).

Additionally, you do not have any chance to see which settings were changed by a user. If you want to save the current state of configuration, you need to go through all settings set in hook_install() or hook_update_N() and compare them with the current settings on the site.

The Features module

To manage configuration in Drupal 7, most people use the Features module ( If you need a simple tool to export your configuration and put it under version control, Features is the module to work with in Drupal 7.

What is the Features module?

To quote James Sansbury from Lullabot:

"The Features module is a module that creates other modules called features."

In other words, Features helps you to put your site's configuration into code so that you can keep track of changes and simply share it with other sites. It was originally created to serve another purpose: to group multiple configurations for one use-case so you could package actual site features and use them in different sites. However, due to a lack of alternatives, it ended up becoming popular as a tool to manage Drupal configuration.

Features works by using so-called components that hold information about configuration objects provided by Drupal itself or contributed modules.

Features uses different types of components: configuration objects that live in code without the need for an instance in the database (exportable components) and so-called faux-exportable components that must exist in the database. Exports of faux-exportable components are used to synchronize configuration objects in the database, so the settings are always up-to-date.

To make an object exportable, you can write a module and use your own default hook handling and export generation. The default hook provides a default state of your configuration object that is directly used on the site or synchronized with the database (depending on the needs of this object).

A very simple example of an object exported using a default hook is a content type. Custom modules can provide their own content types using hook_node_info():


 * Implements hook_node_info().
function cm_blog_node_info() {
  return array(
    'blog' => array(
      'name' => t('Blog'),
      'base' => 'blog',
      'description' =>t('Use for multi-user blogs.'),

This simple example (taken from defines a new content type with the machine name blog. Additionally, it sets the human-readable name to Blog and adds a short description to the type, so users know about its purpose.

A better way to make custom configuration objects exportable is to integrate the module with the CTools Export API.


The CTools Export API has been designed to provide a standardized way to export and import objects in Drupal. Developers simply add some special keys to the object's schema and implement a load function as well as a save function.

Using the CTools Export API, Features will automatically integrate with your module and handle the export and synchronization of your components. Prominent representatives of contributed modules that implement this in Drupal 7 are Views and Panels.

Creating a Feature

Creating a Feature is very easy. Using the user interface of the Features module, you simply add the components you would like to export to the newly created module. While generating the new module, Features uses the defined default hooks or the CTools Export API to save the information about the components to code so you don't need to write the code yourself. While writing the code may be fairly easy for content types (as shown previously), writing down the complete configuration of a field, an image style, or even a view is not so simple, and you do not want to do this manually. With Features, you only need a few clicks to get the configuration into code. Take a look at the following screenshot:

In the preceding example, we selected the content type Blog along with some permissions. As you can see, Features automatically added the required dependencies to other modules along with the information about the fields of the content type and common variables related to the type.

After adding everything you want to include in the export, you can download the feature or let Features directly create the files on your disk.


If you create a new Feature, make sure you use a unique machine-readable name that does not conflict with any existing module. The best practice is to prepend the machine name with an abbreviation of your project or site name (in our example, cm_blog).

After downloading the Feature and enabling it in the same way as any other module, you are able to track changes to components in the Feature. For example, if you change the label of a field included in the Feature, the Feature will be shown as overridden. With the help of the Diff module, it even displays each modified component as follows:

You can then choose between reverting the Feature to its default state (that's what you have in the code of your Feature), which would undo the change you made to your field label, or you can update the Feature, which gives you the modified values in code, so you can share it with others or distribute it to another environment.

Both tasks can either be done using the Feature UI or Drush, which is much faster.

The settings to export with Features

Basically, all components that rely on the CTools Export API, or on modules that define default hooks, may be exported.

These include the following:

  • Variables: These are exported using the Strongarm module, which implements the CTools Export API for all entries in the variables table of Drupal

  • Views: These are exported using the default hook: hook_views_default_views()

  • Content types: These are directly exported by the Features API using Drupal's hook_node_info()

  • Field definitions: These are exported using default hooks defined by Features itself

  • And many more: These include text formats, image styles, and rules (

The settings to not export with Features

While some components may theoretically be exportable, it is not always sensible to do this. For example, exporting cache variables or variables that store timestamps such as cron_last, which stores the date when the last cron was run, would result in constantly overridden Features. There is also no benefit in having components such as this in code, because you can't actively change it, and you don't need to know its value for anything.

As a general rule of thumb, you should never export components that change often, such as timestamps or status variables.

The Configuration Management module

The Configuration Management module is the latest approach we will take a look at here. While Features was never really intended to do real Configuration Management, the Configuration Management module takes some core concepts from the Drupal 8 Configuration Management Initiative and makes them available for Drupal 7.

The main concept behind this module is the data storage architecture. It defines an activestore and a datastore to manage the configuration of a site. The activestore represents the current state of an individual configuration component (for example, a variable in the database) whereas the datastore is defined as the file that contains the default state of the component.

After changing the value of a component tracked by the Configuration Management module, you can save its value back to the datastore (the module updates the corresponding files for you) so that you can track the changes in your version control system.

Looking at the export of this configuration in the following screenshot, you will notice many similarities. This is due to the fact that both modules use the CTools Export API and nearly the same default hooks to import/export the data.

The main advantage of the Configuration Management module in comparison to Features is the reduction to pure Configuration Management. There is no possibility for a developer to extend the export with custom code (that is hook_form_alter() or hook_menu()) as is done often when exporting configuration objects with Features. The export simply contains the components you want to put under version control and nothing more.

Storing configuration variables in settings.php

There is one more way to store settings back in Drupal 7: your site's settings.php, which you know from storing your database details in it. The Drupal installation process and Drupal modules use the variables table to store different types of information that will be used at runtime. The values of these variables can be overridden in the settings.php file. Every module, when enabled, may add variables that can be altered in the configuration setting. One example is the variable named theme_default, which sets the default theme.

Variables stored inside your settings.php file's $conf array will override whatever is in the variables table of your database. This is really useful when you need different configuration for different environments, such as local, staging, and production.

There is a complete list of default variables available on a fresh installation of Drupal at

How Drupal 8 takes care of Configuration Management

Drupal 8 totally changes the way configuration is managed on a site. The configuration can be stored in files instead of the database, so it is not a problem to put it under version control.

All default configuration defined and used by a module must be able to be stored in special configuration files using the YAML specification and the .yml file extension. YAML is short for YAML Ain't Markup Language; according to its creators, YAML is a human-friendly data serialization standard for all programming languages. In short, it's easier to read and write. Each module provides its own default configuration files in a special folder named config, which makes it easy to see which configuration a module provides. Taking the core system module as an example, you will find several files in the config directory responsible for all configurations that the system module handles on the site.

How to start using Configuration Management

By default, Drupal 8 stores configuration in the site's database. During installation of your Drupal site, 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:

Using version control to keep track of configuration changes

Inside this config directory, there are two more directories: active and staging. Both contain no configuration files by default, but they each contain a helpful README.txt.

The contents of the active directory's README.txt are as follows:

If you change the configuration system to use file storage instead of the database for the active Drupal site configuration, this directory will contain the active configuration. By default, this directory will be empty. If you are using files to store the active configuration, and you want to move it between environments, files from this directory should be placed in the staging directory on the target server. To make this configuration active, visit admin/config/development/configuration/sync on the target server. For information about how to deploy configuration between servers, see

The staging directory's README.txt explains the following points:

In order to start using Configuration Management to keep track of your configuration changes, all you have to do is export your current configuration and place it inside the staging directory as follows:

  1. Go to /admin/config/development/configuration/full/export and use the Export button to download an archive of your site configuration, as shown in the following screenshot:

  2. Save the archive inside the sites/default/files/config_HASH/staging folder of your Drupal source files and extract the contents of the archive. The result should look something like this:


    If you're familiar with the Drupal command-line tool Drush, you can export configuration with a simple command. Check Chapter 9, Useful Tools and Getting Help for details.

You can find more detailed information in the next chapter, Chapter 2, Configuration Management for Administrators.

Types of configuration

There are two types of configuration in Drupal 8: simple configuration and configuration entities.

Simple configuration is basically the same as variables (that is, the site name or the number of nodes on the front page) and is used for single global settings.

Looking at the system module's configuration file, you see some examples for simple configuration. The file defines the default values for some of the main settings you will need on your site—that is, the site name or the default e-mail address:

name: 'Configuration Management in Drupal 8'
mail: ''
slogan: ''
  403: ''
  404: ''
  front: user
langcode: en

As you can see, configuration can even be nested, so you can group settings.

Configuration entities are more complex than a simple configuration, and are used for objects that can have multiple copies such as content types or views.

Configuration storage and deploying between environments

Earlier in this chapter, we learned about the directory named staging. In this directory, you put the configuration you would like to import into a copy of your Drupal site—for example, to copy changes from your local environment to your production site. Simply export the new configuration from your local environment, place it in the staging directory of your production site (preferably by using version control), and import it later at admin/config/development/configuration/sync.

Note that, at the time of writing this book, the active directory is not used as originally intended. Its original purpose was to store the site's currently active configuration but, since that is now kept in the database, the active directory remains empty. This might change in future versions of Drupal 8.


Now you have a very complete overview of what Configuration Management is in Drupal 8 and why you should make use of it. You read about some best practices that show you how to best keep track of your changes with version control. You also learned about all the different ways to achieve some kind of Configuration Management in Drupal 7 and were given a basic introduction to the way it works in Drupal 8. Read on to find out how site administrators with no programming knowledge can use this system.

Left arrow icon Right arrow icon

Key benefits

What you will learn

Product Details

Country selected

Publication date : Mar 23, 2015
Length 148 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781783985203
Category :
Concepts :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details

Publication date : Mar 23, 2015
Length 148 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781783985203
Category :
Concepts :

Table of Contents

16 Chapters
Drupal 8 Configuration Management Chevron down icon Chevron up icon
Credits Chevron down icon Chevron up icon
About the Authors Chevron down icon Chevron up icon
About the Reviewer Chevron down icon Chevron up icon Chevron down icon Chevron up icon
Preface Chevron down icon Chevron up icon
1. Understanding Configuration Management Chevron down icon Chevron up icon
2. Configuration Management for Administrators Chevron down icon Chevron up icon
3. Drupal 8's Take on Configuration Management Chevron down icon Chevron up icon
4. The Configuration Management API Chevron down icon Chevron up icon
5. The Anatomy of Schema Files Chevron down icon Chevron up icon
6. Adding Configuration Management to Your Module Chevron down icon Chevron up icon
7. Upgrading Your Drupal 7 Variables to the Drupal 8 Configuration Chevron down icon Chevron up icon
8. Managing Configuration for Multilingual Websites Chevron down icon Chevron up icon
9. Useful Tools and Getting Help Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Filter icon Filter
Top Reviews

Filter reviews by

No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial


How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to
  • To contact us directly if a problem is not resolved, use
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.