The features module

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.

A Drupal site is composed of many parts, often similar to a puzzle. Just like a puzzle, you need to be able to control the pieces at any time. In the software development world, where software exists in the form of source code files, this is handled by a version-control system (such as CVS, Subversion or git - naming just the ones we use for Trellon). By using a VCS, you're able to check-in and check-out all the PHP files that make up Drupal and all the contrib and custom-made modules that compose a site. You could even extend the VCS to handle all the content-related files such as images, media and other data files which make up your site. The missing part is all the work that you did for the site, which exists only in the database. Databases, by nature, are not susceptible to being controlled in a VCS. This integral part of your site which is part of the software development process, and as such should be controllable includes content types, CCK fields, Views, imagecache presets, and many others. Ideally, it should be possible to export all of these as source code and to transform them into code which can then be committed to your choice VCS. The solution for this is to use the features module.

The old way

Wait a minute, one can already create custom content types in code via hook_node_info. Or, if using CCK, one can export the content type and all associated content fields as code which can then be cut-and-pasted into a .module file. You can do the same with Views and imagecache, so what's the use of the features module? Speaking from experience, that's not a path that I would recommend to anyone. Any minor change to a content type that has an impact on multiple Views will force you to re-export all those items, deleting hundreds of lines of code, and pasting the new versions back. The probability of forgetting something in this chain of events through human error is non-negligible.

The pros of features

Using the features module, you can group functionally-related items on your database into a 'feature' which can be composed of several different types of exportables:

  • Content types
  • CCK fields
  • CCK fieldgroups
  • Input filters
  • User roles and permissions
  • Views
  • Imagecache presets
  • Module dependencies
  • Many others...

What the features module does is package all the different elements which make up your feature into a set of files grouped into a normal Drupal module, which you can download to your local filesystem and install in your Drupal site. Once the module is installed and enabled, your feature can be in the following states:

  • default, where the current configuration in the database is the same as the exported code;
  • overridden, where there have been changes to configuration that are only in the database;
  • disabled, where the module and the configured features are not present in the database;

This way, while building your site, you can export these important configuration changes as a feature module, and easily revert to the version stored in the filesystem or, when desired, re-create the feature so that any modification can be propagated to the PHP files. One important note: Features is VCS-friendly and will maintain file and function names as well as the order of these within a file. That way, you can use the usual diff command to study the changes being applied before committing them to the repository.

This capability is very helpful when staging your site from the development server to the live server. In theory one would be able to create an export of the completed site from the VCS repository, and simply install that site on the live server. Then, by enabling the feature module, the site would be ready to receive it's content and go live.

It is even more helpful when supporting an existing live site, where the live database can't simply be overwritten by an upgraded version. In these cases, one usually exports and re-imports the changed elements back into the site, which is fine when there have been a limited number of changes, but can lead to errors when multiple changes to the configuration were performed. In the case of the features module, it's simply a case of replacing the feature module with the latest version, and through the module interface updating to the new configuration.

The cons of features

Unfortunately, two of the most common parts of a Drupal site that reside in the database are not covered by the features module: Variables and blocks. However, there are some extra modules which help you to overcome these.

In the case of variables, through the use of the Strongarm module, variables can become exportable entities. For blocks, it is possible to use an alternative blocks system, the Boxes module , or the Features extra module to export normal Drupal blocks.


Although imperfect (what is perfect?), the features module helps Drupal developers and site integrators to maintain most of the parts that make up the site, while still allowing them to be modified via the normal Drupal UI. It can help to simplify the task of staging a site from development to live and to support that site once live.

Coming soon: an in-depth look at the building of a complex feature.