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.