Drupal Features Module abridged

Drupal Features Module abridged


This post is part of our Abridged series, which aims to explain the basics of some of the more ominous yet awesome Drupal projects in simple and practical terms. We hope these posts will help demystify some of these projects for people who have been hesitant to try them out!

Here, we'll take a look at the Features module, created by the fine people at Development Seed, including a review of the challenges that led to its creation, the current state of the module, how to start using it, resources, and a note on how we've been using it ourselves.


Everyone who's spent hours doing the same site configurations over and over again, for one site and then another, knows how repetitive config tends to be.  Install profiles have been the main tool for avoiding this work for the last couple years, but even with the (now defunct) install profile wizard, many people found them to be a bit overwhelming to figure out and start using at a production level.  Yet install profiles have grown to be fairly well used, especially since they can be customized and reused for certain types of sites - sport teams, churches, radio stations, languages, etc. - there's a big list of them here.

As great as install profiles are - personally I've saved a lot of time using them, and with a minimal understanding of PHP was able to get one exported using the wizard, and then use it to set up sites - they didn't fill all the needs for automating config.  There was no good way to use them to add on other chunks of config after the initial install, and without the wizard, they are not very accessible to those who are PHP illiterate.

There had been an ongoing discussion in the Drupal community about how best to approach this automated config of additional features, contrib modules, and post-installation add-ons, largely advocated for by Boris Mann (especially of note, the conversation in comments of this post), who's started some heated debates about best approaches at many a conference.  He has always been one of the members of the community who's seemed to have a meta-narrative about both what works for developers and what will help make Drupal more accessible for non-developers running through the back (or front) of his mind.

There had never been a real consensus on what the best way forward was, but along with the smallcore movement which advocates shipping Drupal core with minimal add-ons, it was certainly agreed upon that a better and more efficient way to manage config and replicable site features was needed.

Then something started brewing over at Dev Seed.  There seemed to be a turning point within Young Hahn's blog post on how to package up pieces of Drupal sites built with Spaces into individual reuseable features that could be enabled/disabled per Space without enabling/disabling the modules.  This is not intended to replace install profiles, but can be used in conjunction with them, or instead of them depending on your needs.

Current State

From the time of this initial conceptual use, in a matter of months, the Features module was developed, which provides the groundwork of a solid module and a suprisingly user friendly interface for building and exporting Features.  From the project page:

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. A feature module is like any other Drupal module except that it declares its components (e.g. views, contexts, CCK fields, etc.) in its .info file so that it can be checked, updated, or reverted programmatically.

Currently, Features is only compatible with some core modules, spacescck, context, ctools, imagecache, and views. It can also be used via Drush (the Drupal shell); it's pretty advisable to install Drush before hand, as it makes a lot of things quicker once you get the hang of it.

How to Use It

In all honesty, aside from reading the info on the project page, this extremely helpful post on the Dev Seed blog is the best way to get a crash course is to install the Features module, and then follow along with the screencast on the blog post (also at and go through the steps to export a Feature of your own.  The interface has changed a bit since then, but I was able to figure it out with just a tiny bit of poking around.

The idea is that you pick a certain bundle of config that allows you to build a piece of a site - for example, I tested this out with a very simple use case, of the Team page of the AB blog.  When I selected the node type "profile" to be the inital item I wanted to build the Feature around, it autodiscovered some of the related parts of the site's config and module dependencies.

Then you can use the "add components" dropdown to add anything that was not auto-detected that you know is related to the functionality you want.  When you're done you hit the "Download feature" button, and get a tarball that you then upload into the sites/all/modules folder of the site you want to add the feature too (make sure you have all the dependent modules installed).

When you unpack the tarball there are a bunch of files inside the new Feature (treated as a module):

Then you just go to Admin > Site building > Features and enable the features you want to add - it will be listed as "Default" state, because the config is as it was imported.

If you change anything, the state will change to say "Overridden" and you can opt to revert or update - you can re-export the Feature with any changes you've made on one site, and then upload it back to another site that had that Feature previously and update it there as well.  I tried this with adding a new field, and like a charm it appeared on the other site once I updated the feature:

Taking it a step further, Dev Seed has developed the idea of a distributed features server which would allow various people or shops to share the Features they've built.  They also posted a great how-to on quickly setting up your own Features server.


In relatively chronological order, since it's been developing so quickly:

How We've Used Features at Affinity Bridge

We've only gone as far as doing some R&D on Features to date, but they seem to work great and will only get better as more configuration and contrib becomes supported.  Obviously the idea of the Features server would be the ultimate goal, as then internally we would have a library of features at our disposal to use and reuse within various separate projects, which would make every new build and much of our maintenance processes more efficient.