Drupal Features

The Drupal Features module is a way of packaging site components with the ultimate aim of easing migration. For example, an events section in Drupal doesn't just contain a node type called events, it also contains all of the configuration settings around comments, fields added to the node type, permissions available to users, menu items created and any views used to aggregate or search the events. Features can integrate module dependencies so that all functionality that has been packaged along with the feature is available on the other system.

The main thing to realize about Features is that they are not meant to transport content, just blocks of functionality. The idea is that if you create a "blog" feature then you can package that and deploy it to multiple sites.

There are various sections available within the Features admin interface so I thought I would go through these one by one and detail how each works and what I discovered whilst using the module.

Available Features Sections

CCK

This will be a list of any CCK fields created on the system, each one associated with a content type. You probably won't want to use this as the fields associated with a content type are automatically selected when you select them in the Content types section.

Features will not package any default images for your image fields, you will have to provide these files yourself.

Contexts

If the context module is installed and at least one context has been created then this section will be available. It will use the context module import export options to copy the context.

Dependencies

Use this section to select any modules that your feature will require in order to function. One neat feature here is that if you select things like contexts and views from the other sections then Features will automatically select them from this list for you.

Features doesn't select other modules that depend on modules you have selected. For example, clicking ImageCacheUI doesn't automatically include ImageCache or ImageAPI. You won't be able to enable the feature you create until these modules are in place, so the chances are that you will enable dependent modules whilst setting things up.

I should point out that Features won't package up the dependent modules, it just won't allow you to enable the feature without having these dependencies in place.

Imagecache presets

Features includes built in support for including ImageCache presets; just select the ones you want from the list. It might be a good idea to also include the ImageCache modules if you haven't done that already in the feature.

Menus

This will allow you to include any menus that your Drupal install contains. I should point out that it will only include the code needed to create the menu, which doesn't include the actual contents of the menu. This might seem a bit redundant but menu items definitely lie within the realm of content and not functionality, you can also select the links you want from each menu in the menu links section.

Menu links

You can select one or more menu links to be included in your feature. Currently, Features will not automatically select the menu item(s) pertaining to the menu link(s) you select; you will have to do this yourself.

There is no point in selecting every menu link that has ever been created as lots of menu items are created by modules and content entry and might therefore create broken links. The chances are that you will only need to select one or two menu items per Drupal project. These will probably be very specific menu entries, at which point you might want to ask yourself if Features is the best course of action for this.

Content types

These are the different types of node available on your Drupal install. This includes node types created by modules and those created by users and it makes no distinction between the two. For example, you can include the Webform node type, but Features makes no attempt to include the Webform module to allow this node type to work.

Selecting content types will also include fields and field groups that have been defined. Field groups wouldn't otherwise be available if just the individual fields were selected so this is how they are included.

Taxonomy

Including taxonomy in a feature will only include the taxonomy definition (ie, the vocabulary) and not the contents (ie. the terms). This means that everything about the taxonomy will be used (including the content types it is associated with) but not the actual contents of the taxonomy. This is a tricky one as some taxonomy terms are used by modules to map out functionality (Taxonomy Access Control being an obvious one) so these terms must be copied across separately.

Permissions

Selecting this from the feature components list will allow you to select which permissions you wish to include with your feature. This will be both roles that have been given access to a permission and those that have not, which creates a full permissions picture within your feature.

Any permissions selected are based on their roles so roles not created on your new site will be ignored. It is therefore important to use this in conjunction with the roles setting if you want to make sure that everything is copied across. Any permissions that are dependent on modules will also be ignored if the module is not enabled so it might also be prudent to include module dependencies when setting up permissions.

Roles

This allows you to select user roles to include in your feature.

Views

Any views that you have defined will available for inclusion in your feature here. I should point out that any views created by modules (even if you have overridden them) will not be available in this list. I think that leaving out overridden views is a bit of a glaring hole in the way Features works. I can only assume that there was a really good reason as to why this was done, but it does mean that if you want to use a default view you will need to copy it and make sure that your site uses that before you set up the feature. I don't think this will be a big issue most of the time, but for things like organic groups (OG) it means making sure that the right views are being used by both Features and OG itself.

When you create a feature all of the components are kept in different files so it is easy to see what sort of things have been included by taking a look at the source code.