As I have written and talked about before, my favorite feature of Drupal 8 is Configuration Management. In a world where the size and scope of the average Drupal site is increasing, it is important to be able to include your site’s configuration, along with your contributed modules and custom code, in version control. This allows developers to easily audit, test, and deploy their work in an automated and predictable fashion. While this development practice is something that was doable on previous versions of Drupal, it wasn’t simple, and that was the problem.
For those who have followed features.module in Drupal 6 and 7, you have seen a great tool for exporting configuration to code. I know features.module gets a lot of flack for its many weird quirks and idiosyncrasies, but as Molly Byrnes and I talked about at Drupalcon Bogota, features.module was not initially designed to be a tool that exports configuration to code and has to do many workarounds, because it is not part of Drupal core. For these reasons, the tool is not simple to use and this is the problem that Configuration Management fixed.
Here at Pantheon we want to make following best practices for web development as easy as possible. We designed our dashboard and related tooling with this philosophy in mind and it is great to see the new Configuration Management features in Drupal 8 work in the same way. Instead of relying on features.module to use workarounds to export all the different types of configuration from all the different ways you can store configuration, Drupal 8 requires all configuration to be stored in the same way so it all can be exported to code. Unless you do something really crazy, any kind of configuration you enter to Drupal can be simply exported and deployed.
To highlight this shift, we can look at two popular Drupal 7 functions: variable_get() and variable_set(). While these functions might look simple, there was a lot of complexity in the way they were used. For example, to handle “default” configuration it was required that you provide that default value in EVERY usage of variable_get(). This is complex! Drupal 8 simplifies this by storing all configuration as declarative values in YAML files. This means there is only a single value per configuration item and it is stored in a version controlled file. Additionally, modules can easily include their own default YAML configuration by providing a YAML file in the config/install of the module directory. Consider the difference:
$x = variable_get(‘modulename_things_value’, ‘default_value_same_everywhere’);
$x = \Drupal::config('modulename.settings')->get(‘things.value');
While this may not look like a radical change, the possibilities this much better system provides are extensive. Defaults will now be consistent across your site. Configuration can be reviewable in code for end users. Deploys can be done as dry runs without breaking the admin UI. Most importantly, the configuration system in Drupal 8 unifies the various ways configuration is defined and deployed. This allows us to have a single, powerful system that also is flexible enough to meet complex developer needs. For more on doing complex things, check out the second part of this blog post!
The latest stack + the latest Drupal: See how Drupal 8 reaches its full potential on Pantheon.Topics: Development, Drupal, Drupal Hosting