In this series of tutorials you'll learn all about the new configuration system in Drupal. Explore key concepts in configuration management and important skills, such as moving configuration from a local development environment to production and using the configuration system in a module. Find out how to use command-line tools such as Drupal Console, Drush, and Git, as well as GUI tools as an alternative for tasks like cloning a site and importing and exporting site configuration.
Developers can use the demo module provided with the exercise files, Transcode Profile, to explore default configuration, custom configuration entities, administrative forms, and working with configuration entity data in a form. By the end of the course, you'll understand how you can manage configuration between instances of your site and leverage the Drupal configuration system in a module.
Skill Level Intermediate
(music) - [Narrator] Drupal's Configuration System helps to solve the problem of moving changes and configuration from development to production. It does this in two ways: by providing a unified way to store configuration, and by providing a process by which configuration changes can be imported and exported between instances of the same site. In this introduction, we'll provide an overview of Drupal's Configuration System and key concepts that you should know about.
Drupal's Configuration System is designed to facilitate the process of moving configuration between instances of the same site. Each site has a UUID, or Universally Unique Identifier in the system.site configuration item. When a site imports configuration changes, the import files must match the sites UUID. Because of this, new environments for the site should be created as clones. Because the contributed module Features was used so extensively in Drupal 7 to move configuration changes from dev to live, it's a common misconception that configuration management in Drupal 8 works in a similar fashion, and thus now, replaces the Features module, but this is not the case. The Features module enables you to package configuration into modules that you can install or uninstall on another site.
For example, if you had a great set of configuration for a blog that you wanted to reuse on a site that needs a blog, you could use Features to package that configuration related to the blog feature. While the Features module leverages the configuration system in Drupal 8, it is meant to be used to package configuration, not deploy configuration for a whole site. While modules can and do add default configuration to sites, once that configuration has been imported into the sites active configuration, it is now owned by the site.
This means that the module can provide default configuration, which is provided to the site, but once installed, the site, not the module owns the configuration and can make changes to it without interference from the module. This also means that updates to a module's default configuration need to include changes to the yammer files in config/install or config/optional for new users of the module, but the module also must implement an update hook for existing users in order for the configuration changes to be loaded.
This is because config/install is not read again after installation of the module, and configuration and config/optional may also already be active if dependencies on the site were already installed. It is a common misconception that the configuration system stores all configuration in code and not in a database. Well, default configuration is defined by modules in code, and during export and import operations, configuration is staged in files.
The active configuration storage is defined by the site, and it's the database by default. But the configuration system is flexible and configurable and switching to a file based storage MongoDB, Redis, or other key value store are all technically possible. The configuration override system enables you to override sensitive data in settings.php that you don't want stored in the database. Drupal 7's $confglobal variable was renamed to $config and is accessible to the configuration system by default.
Note, however, that configuration forms will display values from the site's active configuration, which may be the default, the database, and not values from $config and settings.php. While there are some sensible and usable defaults in place for the configuration system, site administrators, developers, and teams are encouraged to utilize a work flow that best suits their particular situation. For some small sites, the administrator might not ever use the configuration manager module to import and export configuration.
Some teams will only use Drush and Git to manage configuration, and never will use the UI provided by the configuration manager module. It's even possible to disable the configuration settings forms on the production site, for example, using the contributed module configuration Read-Only mode. This can be desirable in cases where you want to limit configuration management to developers using Drush with files managed in version control systems like Git. While the tutorials in our series on configuration management demonstrate a couple of possible workflows, there are certainly other workflows possible as you get more and more familiar with the configuration system, you will be able to better utilize its flexibility and configure it to meet your site and your team's needs.
In this presentation, we introduced key concepts regarding Drupal's Configuration System. Explore the rest of the tutorials in this series to learn more.