Configuration and Features in Drupal 8

June 25th, 2016 Updates information about features and updates drush commands

About this article

I hope to use this article as a place to document some of the things I've learned about configuration management in Drupal 8. So far, it isn't organized very well. The plan is to make a good blog post about all this soon. In other words, this is a very rough draft.

Using the Features module in Drupal 8

Features uses the core configuration system and is a lot less buggy. It still helps to keep track of changes, just like it did for Drupal 7. Features will allow you to see if configuration is overridden and revert it. You can see when a particular piece of configuration doesn't exist on the site but does exist in a module. The only time it can create new configuration variables instead of just updating existing ones is on module installation. But, the Configuration Update Manager (config_update) module can be used to import configuration. There are also drush commands that can import changes: drush features-import-all (or drush fia) will import any changes and additions, all in one swipe. There are other drush commands available to have more fine grained control.

Basically, if you add some configuration to a feature module, then push the changes to a remote server, if the module is already enabled you'll need to either use the Configuration Update Manager or drush to import the new config. In other words, the Features UI can only be used to update configuration that already exists in the active store (which is the database by default) but doesn't allow for creating new configuration; you need the Configuration Update Manager or drush for that.

One possible features workflow to get updates from one environment to another

  1. On a personal computer, a new content type is added with some new fields and updates are made to an existing field's configuration.
  2. Features is used to create and update the necessary configuration .yml files.
  3. For local testing:
    1. All changes to the local environment are reverted by importing a current backup of the remote site's database.
    2. The Features UI is checked to confirm that there are missing/changed features and that the changes are the expected ones.
    3. The drush command drush fia is used to import all updates and changes.
    4. The Features UI is checked to confirm that no configuration is overridden.
    5. Confirm that the updates worked; in the case of the example above, check to see if the new content type and fields are added correctly and that the existing content type's fields are updated.
  4. Commit to a git repository and push to a remote server like Pantheon, Acquia, or Hostmonster.
  5. On the remote server, the process is similar to testing locally:
    1. Check the Features UI on the remote server, run the drush command, check the Features UI again, do QA on the new and updated functionality.

Some configuration-related commands for Drupal 8 that come with Drush

There are some helpful drush commands for settings config variables:

  • drush config-edit --editor=nano
  • OR
  • drush cedit --editor=nano
    • just use the command above to get a list config entries, you pick one and get an editor to edit a yml file. When you save the yml file, it updates the config for you.
    • You don't need to use --editor=nano if you want to use the default editor for the terminal session (usually vi, I think)
  • drush config-get
  • OR
  • drush cget
    • this gets a particular config variable's value
    • ie., drush cget system.performance
  • drush config-set
  • OR
  • drush cset
    • use --format=yaml if the value you are setting is not a string. For example if you want to set a boolean:
    • ie., drush cset system.performance --format=yaml --value=true

Internal References

Article Type