One of the best and most-touted pieces of Drupal 8 is the new configuration management system. This system makes it really easy for developers to export configuration into code. Before that, developers had to rely on a complicated system of Features, Strongarm, UUID, Features & UUID plugin modules. Even for seasoned developers, this was often a nightmare. There were overrides and locking, crossing fingers and hoping that features would actually revert, having them not revert for no reason at all, etc. It was a mess. Not to mention trying to put all of the features in logically named and organized modules, which could grow and grow as the site got bigger and added more functionality and don’t even get me started on dependencies Configuration Management in Drupal 8 aims to solve all of these problems.
If you've been on the fence about moving from Drupal 7 to Drupal 8, as a developer, this could be a reason to switch. Here’s a breakdown of key differences and considerations:
UI or Drush?
Drush can make your features workflow a lot easier, but this also depends on your site. If you're adding a lot of things to a feature, the UI can be easier than listing and typing or copy/pasting/tabbing components into commands. Personally, I've fallen into a pattern of using the Features UI because many of the sites I work on have complex features. There is also a UI for config in D8, but the drush import and export is pretty near flawless. I've yet to find a reason to want to use the UI, though I appreciate its existence as a backup. However, we will go through both the UI and Drush for Drupal 7 and Drupal 8.
Exporting Configuration In Drupal 7
Ok, so you've made the changes you need to export for the existing feature.
Using the UI
- So now we need to navigate to Structure > Features and the appropriate feature.
- We click Recreate and wait for quite some time for the feature to load.
- We poke around all of the components, making sure we've found all of the appropriate bits of our feature.
- We might update the version number, if this is a major change.
- We set the file path and click generate, or download.
- If we downloaded the file, we find the file and extract it into the appropriate location.
- We go back into features and check that feature is in the correct state.
Now, if you are only updating existing components and not adding or deleting any components at all,
drush features-update myfeature will do the trick. You can then check the state of the feature with
When adding components, list components with
Add the components as an argument to
drush features-export, like
drush features-export myfeature mycomponent1 mycomponent2
The above example exports the image component into a new feature called
In Drupal 8
Using the UI
Go to admin/config/development/configuration to access the UI. In the Configuration UI in Drupal 8, you have a few options. You can Import, Export, or Synchronize. You can also view a handy diff of the changes. The screen looks something like this, with an "Import All" button at the bottom:
The Import tab allows you to import a full configuration archive from a file:
or a single configuration item from pasted code:
The Export tab similarly allows you to export the entire configuration into one file:
or export a single item into code that you can copy:
At first, I missed the ability to group configuration as you could in Features, but the interface is so much simpler, and the dropdowns are much easier to use - not to mention they are more reliable than the Ajax-dependent checkboxes of Features.
While Drupal 8's config UI is simple, drush is simpler still.
To export configuration:
drush config-export -y. You will see a list of exported configuration changes like this:
To import configuration:
drush config-import -y. You will see a list of imported configuration something like this:
That's it. It's one of my favorite things about developing in Drupal 8. It's quick and streamlined and only takes seconds. You don't need companion modules to help export everything. Doesn't matter if you're adding, deleting, updating, creating, whatever. In the 12+ months that I've been working with a Drupal 8 production site, I've only had a couple small instances of config not syncing correctly - much less frequently than features, and it was easier to troubleshoot.
Now that we've passed the first anniversary of Drupal 8's release, more and more people and companies are considering moving to Drupal 8. There are dozens of things to consider, and this is just a small one, but it's a great improvement to the developer experience.
What are your thoughts on configuration management in Drupal 8? Comments, questions, concerns? Reach out to us on Twitter - @ChromaticHQ and tell us what you think!