Portable Configuration in Drupal

Error message

The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.

The Drupal community is hard at work delivering the next major release, Drupal 8. If you are already involved, your help is much appreciated. If not, but you would like to help with Drupal core development and are looking for a way to start, take a look at core mentoring hours. It's a great way for people to get involved, and there are several time slots each week that suit many people's schedules.

The list of new features in D8 is impressive and one of the major improvements is the Configuration Management Initiative (CMI), also sometimes called 'better features in core'. This is an effort to make it easier to export the configuration of your site through a UI using the features module.

So, what is the problem features module addresses? And why we do we need a “better” way to export configuration through features?

If your site is something bigger than a personal homepage, you probably have several copies of your site. Let's call them environments. We usually refer to environments by name, such as development, production, staging, etc.

Drupal is known for its flexibility when it comes to configuring different aspects of web sites. The problem that features solves is making your configuration portable. For instance, when a site builder creates a beautiful image gallery and wants to move it from his development server to a production server, can it be done in a way where we know that it's going to work on the new site?

Here's where the features module helps us. Instead of writing down all manipulations made in admin UI to achieve the final result (brilliant-looking image gallery, remember?), and manually repeating them on production server, we create a “feature” for that image gallery and move it to the production environment.

The idea is simple yet powerful – group a set of site settings around some functionality (image gallery, blog, whatever), and save them within the file system. The Features module has a wide range of supported settings out-of-the-box, and there's a robust API to allow other modules to declare “feature-able” settings. Every feature is exported to a Drupal module, so you can copy it to production server, enable it, and get exactly the same settings you defined during development.

It's a very nice tool to have, and it makes it much simpler to control how sites are configured. But what if you want to change the settings that are part of a feature? Maybe you need to reuse that feature across a range of websites, and you need to know that it's going to work even in environments that are different than the production environment you originally built it for.

It's possible to do this right now. The challenge is that, once you change some part of a feature, the feature itself is now overridden. When it comes time to update the feature, or install a new version, you are in a situation where your changes can be overwritten. You can “play” with the settings that are part of a feature, and then return to default state (revert feature), or save the new state as a new default.

There are caveats, of course. Otherwise, who would need “better” features?

First of all, it's a common situation that certain settings are always different on development and production. i.e. we build a page layout using panels or display suite, but want to always display some visual indication for development site (different logo / slogan / bold text 'dev' all over the place?) There is no simple way to do that using features.

Second, and most common, it is not always easy (or possible) to revert feature to default state. When it happens, feature is stuck in Overridden state, and you can do nothing about that.

I'm going to describe features usage in more detail in the next article, and talk about what makes for a better features set. Stay tuned!