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.

By Sam

Drupal developer from Perth, Western Australia. I love programming, gaming, the Internet, growing vegetables and hiking.

1 comment

  1. Great Article Sam, Ill be giving features a test run on a project I’m working on ,. I’m currently working with a couple of smart Drupal guys so hopefully Ill teach them a thing or two.


Leave a comment

Your email address will not be published. Required fields are marked *