Features - Structured and Organised Site Building

Deploying a new Drupal site is generally not a big problem, especially if it is a small site with not to many complicated features. An easy way is to simply use the Backup and Migrate module, take a backup of the database, upload the whole site repository and then restore the database and job done.

However, when you later want to add new features, the problems start to mount up. You need to really test things before you start making changes on the live site and at the same time document everything to create a step-by-step guide on how to make the new feature live. Depending on how much is involved, this could mean that you need to have the live site in maintenance mode for quite some time.

The problems with deploying changes or new features to existing sites stems from that everything is stored in the database, both content and configuration. Adding to it is that there is no easy way to know what is content and what is configuration, with the sole exception being the variables table. Until Drupal 8 and the Configurations Management initiative, lead by Greg Dunlap (heyrocker), is available this is going to remain being a pain for us.

There exists many ideas, solutions and modules for making this more streamlined, one such method is using the Features module, which is the method I am focusing on in this post.

What is the Features module?

From the project page on drupal.org:

The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.

Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module.

Simply speaking, Features let you collect configurations for both Drupal Core and contributed modules and export them to code in a module that can be installed like any other module on the live site. Even better, it also provides an UI where you can manage all your Features modules.

Benefits this includes are:

• Integrates with the CTools export API which enables configuration export from many modules, including Views, Panels, Context, etc.
• Supports Strongarm to allow you to export configurations from the variables table.
• Configuration in code.
• Possibility to add custom code to each feature module created.
• Version control management of configurations.
• Much easier and quicker to deploy updated/new features.

This all sounds fantastic, and to much degree it is really making things much easier. Unfortunately it is not the complete solution you may think it is at first glance. Below I will go over how it works today, as well as what is really important to have in mind when using it.

Planning Ahead

Before you start creating your features it is important that you understand a few concepts and restrictions. Especially important to understand is that features doesn't fix the underlying problems with that configuration and content is mashed together in the database, it only tries to do the best it can of a bad situation. Also, not all configuration is possible to export with it, it depends on how it is stored and whether needed support in a contributed module exists or not.

Therefor you need to carefully plan ahead before starting to create your features. A couple of rules I have created for my features are:

1. Separate site features into separate features modules that can be maintained individually.
2. Avoid adding configurations that are likely to be changed on the live site.
3. Document everything, especially what is in the features and what other steps are necessary when deploying them.

It would be easy to mash all settings for a site into one gigantic features module, but the result will only be that maintaining it will be more and more difficult. Instead, try and make each module focused on a particular feature on the site, such as the Contact Form or the Image Gallery. That will not only make them easier to maintain, it will also make them reusable for other sites.

For my site projects I usually have one Foundation feature module. Its purpose is to enable all the basic, not feature specific, modules needed on the site as well as contain all the static settings for them. With static settings I mean those that are very unlikely to change on the live site.

Then I will create a bunch of other feature modules that are focused on specific features or sections of the site. I will avoid adding configurations to a feature module that are also going to be needed for other features. For example Image Styles, those will be used by many different features, therefor they will have their own module.

While developing my features I am also documenting everything. Each feature will have its own document where I list all dependencies as well as other steps necessary when deploying the feature on a live site. Then I will also have an overall site administration document. It will both list all features the site is utilising, as well as what settings that are free to change and all other administration tasks on the live site.

Then, before deploying a new, or updated, features module, I always test it on a staging site containing a copy of the live sit. During these test I also go over my documentation and write a step by step guide on how to deploy, including any other changes needed.

Doing it this way has helped to both make development of sites easier, but more importantly given me a much more flexible and easy way of deploying changes on the live site. It has also resulted in that the sites are easier to maintain and administrate, not only by myself, but also for any other site administrator.

Companion Modules

As described above, the Strongarm module allow you to add configurations from the variables table to your features. Not using it would restrict your possibilities so I recommend you use it.

Another very useful module to add is Diff. It is especially useful on the live site. There is nothing that prevents you from overriding a setting from a feature module, which will happen at some stage. With the Diff module installed, the Features admin page will list those features as having overridden settings and also let you view what those changes are. It is extremely handy to have so I strongly suggest you instal it too.

Very Important Oddities!

Before I end this post I would like to share some very important oddities I have noticed while working with this module. It is important that you understand these and make sure that you follow my suggestions for how to avoid getting into problems, or in worst case render the live site unusable.

Updates to existing enabled features will be automatically applied!
As soon as any page on the live site is fetched, Features will apply the new settings without asking.

This can cause all sort of problems if your not careful. Especially if the update adds dependencies on modules that the old version didn't have and that was not installed before you uploaded the new features version. In worst case your site will be rendered useless and create extra work for you to fix this.

Make sure that you first upload any new modules that the feature needs!

Disabling a feature might remove some settings!
Since features can be disabled, Features tries to also remove its settings. This to can have unwanted results if your not careful.

My best advice here is that you test what happens when you disable a feature on a copy of the live site.

Features with only dependencies does not show up on the Features admin page!
You will rarely create a feature module that only enables a bunch of modules, but its good to keep this oddity in mind if your new feature isn't showing up on the admin page after you upload it.

I have filed some issue tickets about these oddities and hopefully future versions will be improved to sort them out.

Conclusion

Using the Features module has not only helped me to both better structure my development process and deployment of features on live sites. It has also made me better understand how Drupal works, where stuff are stored and better plan new development. As a bonus the end result has been sites that are both easier to further improve and administrate.

Features does not solve the underlying problems with having configuration and settings mashed together in the database, but it does give us much better control over it. Until Drupal 8 and the complete separation of content and configuration is in place, this is one of the best solutions we have.

Of course, the way I am using Features is just one way, I'm sure many of you use it differently. Therefore it would be interesting to know more about your experiences using it. Feel free to share your experience in the comments below, I'm looking forward to hear about them.

Resources

• Features project and download page
• Strongarm project and download page
• Diff project and download page
• List of modules supporting exportables via the Features module