Features Information Architecture for Drupal 7 Site Builders

Features is a great module that lets Drupal developers export configuration normally stored in the database out to PHP code, which can then be committed to version control and deployed. It’s pretty much a required module these days, but what is the best way to use it when building a site? When should a developer create a new feature for their site? This post outlines a two approaches to Features information architecture.

There are 2 main approaches to managing configurables using Features – create one huge module, or create many smaller modules.

One Feature to Rule Them All

Creating one huge module can seem like a good approach due to its simplicity:

• You don’t need to worry about which feature should contain what settings.
• You avoid any dependency hell, which can happen with lots of Features.
• You can use Drush CTools Export Bonus to simplify creating and maintaining your single feature.

However, the single module approach has several downsides:

• No ability to disable a single part of the site quickly, which can be useful in debugging.
• Likelihood of a messy .module file for the feature if you put lots of hooks in there. Alternatively you will end up with a lot of custom modules.
• Really slow to rebuild the feature as you need to re-export everything – this is a massive downside on a complex site.

Divide and Conquer

Multiple Feature modules have the following benefits:

• Encourage modularity. Related configurables are kept together.
• Related custom code and hooks in the features .module file.
• Easier to turn a feature into something reusable (generally this will still require more work)

On the other hand:

• Listing all the features can be slow using drush fl
• It can take some time to remember where something is stored, or where it should be stored.

My current project’s feature directory looks something like this:

• projectname_settings (strongarmed variables)
• projectname_events (event content type, fields, views, panels, display suite)
• projectname_page (generic page content type, fields, views, panels, display suite)
• projectname_workflow (exportables for workbench moderation stuff)
• projectname_search (search_api exportables)
• projectname_theme (hooks for themes, panels layouts, generic display suite stuff)
• projectname_taxonomy (all the taxonomy vocabularies and fields)
• projectname_user (profiles, user settings, registration process)
• projectname_input (wysiwyg, contrib field modules, input formats)
• projectname_media (media module & submodules)

It’s a pretty big project with multiple devs working on it, maybe for a smaller project one feature would be fine.

Some other notes:

• Drush features commands make life a lot easier.
• Install diff module so drush fd works.
• If you are using git you can write a pre commit hook that checks that all features are exported before you commit.
• It’s easy to forget to add new configurables when updating the modules, not sure how to fix that apart from discipline.