An introduction to the Drupal Features module

The Features module is something of an enigma. Some Drupal developers get really excited about it, but it can be hard to understand why. Installing the Features module adds no new functionality to your site. From a visitor’s perspective, the module does not allow your site to do anything that it couldn’t do before you installed it. So what, exactly, is the Features module for?

Why use Features?

The Features module does one simple thing. It allows you to take site configuration settings and store them as in a file as a sort of mini-module¹. This might not seem like such a revolutionary thing, but Drupal developers get really excited about this. The reason is that storing configuration in code allows you to do two very important things:

1. Re-use configuration settings; and

2. Add configuration settings to version control.

Allow me to explain why these are such a big deal…

Re-using configuration settings

One of the most attractive features of Drupal is that by installing modules and using the administration menus, you can build a sophisticated website without writing a single line of code. Throw in a nice theme, and most of your website is done. The combination of views and the module formerly known as CCK are particularly powerful and can be used in any number of applications.

The trouble is that after you’ve developed a few Drupal websites, you will often start to repeat yourself. For example, in most new sites I develop, I find myself creating a ‘News’ content type (or similar) and then creating an associated view with block and page displays. And while the views module is great, it can get tedious doing this over and over again.

The beauty of the Features module is that it allows you to save your ‘News’ content type and associated view as a mini-module that can be re-used on another site. This is particularly useful if you have a development procedure where sites are built on a development server, then moved to a staging server for testing, before finally being moved to a production server. The Features module saves you having to go through all the clicking to re-create the content type and view.

Adding configuration to version control

Because the Features module saves your configuration as code in files, this allows you import your configuration into a version control system (VCS). Even if you have configuration settings that will only ever be used on one particular site, the Features module is still worthwhile simply for VCS. This isn’t the place to dive into all the benefits of using a VCS, so for now I will just mention a few.

Having something like a view saved in your VCS means that if someone does something silly (for example, if someone deletes the view), then you can get it back without starting from scratch. It also means that you can experiment with the configuration and break things (on your development server, of course) in the knowledge that you can go back to where you started with very little effort.

Having your configuration stored as mini-modules with Features reduces stress while you’re developing and can potentially save you from repetitive setup tasks. So let’s look at how to get started.

How to create a simple Features mini-module

Let’s assume that we have a new site and we’ve created a ‘News’ content type and an associated view. We will use Features to create a mini-module that stores these in code. If you’ve installed the Features module and enabled it, then when you visit the Features administration page, it will say something like:

No Features were found. Please use the Create Feature link to create a new Feature module, or upload an existing Feature to your modules directory.

At this point, you want to visit the Create Feature tab to begin creating the new feature.

You will need to enter a name and description for the feature, something like:

Name:
Latest News Feature

Description:
Provides the News content type and associated views

For the moment, we can ignore the Version and URL of update XML fields.

This is simply metadata for describing the mini-module. We build the feature by selecting components from the Edit components drop-down menu. To build our feature, we will first add the ‘News’ content type. To do this, we select ‘Content types’ from the drop-down, and select ‘News’ from the checkbox list that appears.

Once you do this, you will notice a table appear to the right. This shows you the components that make up your mini-module. Some of them will be ones you have selected deliberately (like the ‘News’ content type), and other will be things that the Features module automatically detect should be included (like the fields associated with your content type).

The next step is to add the view. We simply select ‘Views’ from the drop-down menu and check the box next to the view. The components display should look something like the following:

And the final step is to hit the ‘Download’ button to download the feature. The feature mini-module is supplied as a TAR file, that you will need to extract to one of the places that Drupal looks for modules. I would recommend creating a new folder called ‘features’ in either sites/all/modules or sites/default/modules.

Once you’ve installed the mini-module you should see something like the following in the Features admin page:

The final step is to enable the mini-module and it’s all done.

What things can be stored in a Features mini-module?

What can be stored in a mini-module depends largely on the modules you have installed. Without anything else installed, the Features module will store:

• Content types,
• Module dependencies,
• Fields (D7),
• Menus,
• Individual menu items,
• User Roles,
• Permissions,
• Taxonomies,
• Input flter Formats, and
• Image formats (D7)

Other modules that provide support for exporting to Features include:

• Context,
• Strongarm,
• Boxes,
• CCK (D6), and
• Rules

These are just a few. You can find many others in the Featuers documentation.

Notably, Features does not (currently) allow you to save blocks or block placements. However, using the Context and Boxes modules you can achieve the same effect.

Reverting and Re-creating features

Once you’ve installed a mini-module, the Features module does not prevent you from changing settings through the UI. This means that it is possible for people to come in and make changes to the configuration provided by your mini-module. When this happens, the features module marks the mini-module as ‘overridden’.

When a mini-module is overridden, then you have a choice. You can either revert the feature back to its default state, or, you can re-create the feature. Either one is quite simple. To revert the mini-module, you hit the ‘Overridden’ button next to its listing. This will take you to a page listing all the components, and will allow you to revert individual components back to the default state. If you want to re-create the feature, you simply click on the 'Recreate' link, and the Features module will allow you to re-download the feature with the changes included.

Using Features Well

Like most powerful tools, using Features well requires some care and thought. Listed below are some ways to get the most out of Features.²

Store Features mini-modules in their own folder

When you’re developing a site with lots of functionality, then you can end up with quite a few different features. It can be helpful to keep your modules folder organised by grouping features together.

Whether you keep them in the sites/default/modules folder or the sites/all/modules folder depends on whether or not you are using a multi-site setup and whether features are needed across multiple sites.

Avoid putting anything in a mini-module that people will change through the UI

This is perhaps the most important advice when using Features. If content authors or administrators are able to edit block placements or menu items, then these are best left out of a Features mini-module. The reason is, that if you make modifications to a mini-module, then upload it to the server, then this will over-write changes made by other people, and this often makes them upset. It’s best to restrict the configuration included in a feature to things only developers are likely to change.

Avoid putting content in Features mini-modules

It is possible to add content to a Features mini-module, either by writing custom code or via a contrib module. This is best avoided, however, as content is something that people are definitely going to change through the UI. Even for a mostly brochure-ware kind of site, somebody is going to want to change some page, and Drupal is designed to make doing this easy. Putting content into a mini-module goes against the grain of what Drupal is designed to do.

That said, if you are desparate to have your content in some kind of version control, then the Backup and Migrate module can be used to dump parts (or all) of your database into a file where it can be backed up and versioned however you like. There are also some situations where it may be a good idea to put certain content elements into a mini-module, but, in general, it’s a bad idea.

Keep Features mini-modules in ‘Default’ state

If a mini-module is in an over-ridden state then one of two things must be true:

1. Either the change is not important enough to commit to code, in which case it should be reverted; or
2. The change is important enough to commit to code, in which case the mini-module should be recreated.

Either way, it’s best to keep Features mini-modules in the Default state.

Limitations of Features

While Features is a really useful module, it won’t solve all your Drupal woes. There are a couple of limitations:

• Features doesn’t work with native blocks: Now, this may or may not be an issue, depending on the permissions you give content authors, but there are a number of circumstances where it would be useful to fix a block in place with a mini-module.

• Re-creating Features requires messing about with TAR files: While it makes sense to package up a directory using a TAR file when you first create the mini-module, it would be nice to be able to re-create a feature and have Features simply modify the files for you. There are probably extremely good reasons why this is the case, but it’s still mildly irritating nonetheless.

Using Features with Drush

Features includes several useful Drush commands. The following are listed on the Featues module page:

• drush features
  List all the available features on your site and their status.
• drush features-export [feature name] [component list]
  Write a new feature in code containing the components listed.
• drush features-update [feature name]
  Update the code of an existing feature to include any overrides/changes in your database (e.g. a new view).
• drush features-revert [feature name] Revert the components of a feature in your site’s database to the state described in your feature module’s defaults.
• drush features-diff [feature name] Show a diff between a feature’s database components and those in code. Requires the Diff module.

References

• http://drupal.org/project/features The features project page
• Bundling site settings using Featues A getting started guide on Drupal.org
• Features Abridged A very useful introduction by Ariane Khachatourians of Affinity Bridge, with some very intersting information on the history of the project.
• http://chicago2011.drupal.org/sessions/advanced-features-usage Neil Hastings’ presentation, Advanced Features Usage at DrupalCon Chicago 2011]

---