Developing any kind of enterprise site typically involves multiple environments, for example Development, Staging, and Production. A very common scenario developers run into is that a site is developed locally (on the developer’s own machine) and then the code changes get pushed to a repository (version control using Git, Subversion, Mercurial, etc). But what about database changes? Those aren’t code … but they can be.
What is considered configuration?
Module configuration (set via Drupal’s UI), content types, fields, Site Information settings, basically any kind of settings that you can control from Drupal’s UI. Content (nodes, terms, users or any sort of entities) is not part of this and does not get exported.
How to copy configuration from one site to another:
Keep in mind this will only work for the same site, existing in two different environments. The typical way this would go is you create a site in one place (some cloud server e.g. Amazon Ec2, RackSpace CloudServer, Linode, Acquia Cloud, Pantheon, etc), do some initial commits after getting Drupal set up there, and then clone that locally in your computer. There you can go to town and add all the modules and code you want, configure everything, then export it and import it back into the remote dev site.
Before attempting to export your configuration, make sure to commit all your code changes, push them to the repo, and make sure the remote dev environment has pulled those changes. You don’t want to try and change settings for modules that don’t yet exist in code – that can lead to all kinds of nasty things!
In Drupal 7 this was accomplished using the Features module, which is a pretty complex beast to work with, but very powerful too. The Features module has been made part of Drupal 8 core and is now known as Configuration Synchronization. This can be accessed from the Configuration > Development > Configuration Synchronization menu (/admin/config/development/configuration):
(Drupal core’s admin menu does not have dropdowns by default. Install the Admin Toolbar module for that awesomeness.)
Next, click Export (/admin/config/development/configuration/full/export) you can export:
This gathers up all your settings and downloads a gzipped tarball for you. Now go to your remote dev environment, log into Drupal, and go to Import (/admin/config/development/configuration/full/import):
As you can see, it provides you an overview of the new/changed items it will import. In this case I had added a single text field called “Sample text field” to the Basic Page content type. Click “Import all”:
This does not always complete without error. Sometimes it will fail with obscure-looking fatal errors (500 – Internal Server Error), but so far I’ve found if you re-run the import it will usually complete without further issue. Such errors can be useful for ironing out configuration issues though, so pay attention and see if you can fix whatever is triggering those.
And that’s it! My field was created. Here’s a screenshot of the Basic Page content type’s fields on the remote dev site:
Multiply the above by a zillion for the number of other settings a complex Drupal site can have, and you can see how incredibly useful the Configuration Synchronization in Drupal 8 is. It has made great strides in becoming easy to use. The UI is admittedly very simple, and for a full-site export that’s a good thing. If you want more fine-grained control in order to export only certain things, this too is possible. Have a look at /admin/config/development/configuration/single/export:
This allows you to export specific settings, for example for a content type, a field, text format, menu, etc. This does not yet allow you to select multiple such settings and export them together, so you have to either export EVERYTHING or export just one thing at a time. When you do export one item, you’ll need to copy the resulting code, then go to the destination site and import a single item… there you can paste this. Make sure you select the same “Configuration type” option from the pulldown menu as when you exported it:
This aspect of Drupal 8 is a real time-saver, and takes a lot of human error out of the equation. We’re excited to take advantage of this in our current and upcoming work!