Managing Site Configuration in Code | Pantheon

Managing Site Configuration in Code

What Is Site Configuration?

Before we discuss why you should keep site configuration in code, we need to define what site configuration is first. Your site’s configuration includes any items configurable in the CMS dashboard not related to content.

Configuration is comprised of things like theme settings, widget/block placement, navigation menus and more. If you create a new blog post, that would not be configuration. If you added an area to display the top 5 blog posts or created a new navigation menu, that would be configuration.

The Idea

When working with a CMS such as WordPress or Drupal, the database is the canonical source for configuration and, as such, is where the site reads the configuration. To manage site configuration in code, the configuration in the database needs to be exportable so that it is converted to code and saved in the file system. The configuration must also be importable from the code in the file system back into the database.

Why Manage Site Configuration in Code?

Version Controlled Configuration

Once your configuration is in code, it can be version controlled just like any other piece of code in the project. Keeping your configuration in code, and version controlling that code, will provide visibility by letting you see what configuration has changed, who changed it, and when it was changed. Keeping these changes in version control also becomes really powerful when you need to quickly revert configuration changes.

When configuration code is version controlled, developers can branch it to work independently, and configuration conflicts can be resolved as traditional merge conflicts. If your configuration changes clash with those of another developer, the conflict can be spotted, discussed, and resolved before the configuration ever makes it to production.

Configure Once

Configuration, once exported into code, can quickly be moved between environments and imported into the database. This is great if you have a dev, test, live workflow. You can make configuration changes in a development environment, commit them to code, deploy to a test environment and import the changes. This allows you to avoid having to remember what was changed on the dev environment and clicking through those changes in the dashboard on the test environment.

Easily Integrate Client Configuration Changes

Working with configuration management in code—coupled with dev, test and live environments—allows you to keep client configuration changes under control. Before you make configuration changes on dev, you can import the database from the live environment. This will bring the latest content and configuration changes from the client to the dev environment.

Now you can export the client’s configuration changes to code and commit them to version control. Then you’ll make any configuration changes you need, export them to code, and commit the code to version control.

Now your configuration changes and the client’s—both in code—can be deployed to the test environment and imported to the database there. Once everything looks good and you have approval on the test environment, you can deploy to production with confidence that your configuration changes—and any configuration changes the client made—won’t conflict.

This post is the first of a series on config in code, up next we'll dive into the specifics for both WordPress and Drupal.

Related Resources:

Topics Development, Drupal, WordPress

Let’s get in touch