Managing your site's configuration

Last updated on
16 December 2016

Drupal stores site configuration data in a consistent manner: everything from the list of enabled modules, through to content types, taxonomy vocabularies, fields, and views.

Making configuration changes on a live site is not recommended. The system is designed to make it easy to take the live configuration, test changes locally, export them to files, and deploy to production.  Your site's configuration can be stored as part of your codebase and integrated with version control.

By default, the "active" configuration is stored in the database ("config" table). This is for performance and security reasons. This is the complete configuration for the entire site at that moment. Configuration can be exported and imported as YAML files, either in it's entirety, or a single piece of configuration, using Drush config commands or the Configuration Manager. (See below for more details.)

Exporting and importing configuration changes between a Drupal installation in different environments, such as Development, Staging, and Production, allows you to make and verify your changes with a comfortable distance from your site's live environment. 

This allows you to deploy a configuration from one environment to another (as a precaution, Drupal checks the site is the same before importing, by comparing its UUID).

Module and theme configuration files

Default configuration shipped with modules, distributions, and themes are imported into the active configuration store when the extensions are enabled. An extension's default configuration is found in the config/install directory.

How to import, export and synchronize

With the Configuration Manager core module, you can import, export, and synchronize site configuration via Manage > Configuration > Development > Configuration Synchronization (admin/config/development/configuration).  Changes can be reviewed before you import them.

Either a single object can be imported or exported using a copy/paste workflow. This is useful if, for example, you wanted to just move a newly created view from one environment to another.

Or the full site configuration can also be dumped as yml files to a tar.gz file. This only works if you're moving configuration between two copies of the same site (e.g. dev and production) and for that reason the sites UUIDs must match.  

To check a site's UUID:

drush cget system.site

Full synchronization example workflows:

After synchronization is complete, all changes will be applied, such as enabling new modules, fields or content types. In short, all configuration changes made on the development site should now be live on production.

More Information

If you're looking for more in-depth information about the Configuration Management system in Drupal 8, you can check the handbook pages for Configuration API.

Do's and Don'ts

DO'S

  • It's strongly recommended that you do a database-dump before each synchronization of the staging and the active directory. The database-dump "could save your life" on a potential needed rollback-strategy.

    Drush archive-dump (drush ard) and archive-restore (drush arr) are convenient ways of doing this.

DON'TS

  • Try to change the active configuration on your site by changing files in a module's config/install directory.
    This will NOT work because Drupal will only read from that directory when the module is installed.

    To edit "live" you'd need to use drush config-edit