Where to do what when working with Features?

When developing a Drupal site using the Features module, it's important that everyone is clear on what kinds of changes are done where.

Features is used to store a website's configuration in code. Configuration is done on a development site, saved to features, and then commonly brought on to a staging site and finally the live site. Making this work requires careful documentation and education about which site specific types of changes should be made on.

The workflow for configuration changes often looks like:

1. Make configuration changes on dev, test, and confirm.
2. Push these changes to features and commit to a versioning system like Git or SVN.
3. Update the code on the dev site and revert the updated features on dev.
4. Update the code on the staging site and revert the updated features on staging.
5. Test stage, make any needed fixes, retest on stage.
6. Update the code on the live site and revert the updated features on staging.

For this system to work, some types of data input must be done on the development site and then pushed to features, but other work needs to be done directly on the live site and from there pulled by the dev site (via database syncing). What goes where?

The general question to ask when deciding if something should be done on the development site or on live is: is this configuration, or is it content? Configuration goes on dev, so that it can be developed, added to features, pushed to stage for testing, and finally pushed to live. Content editing goes on live. But, like any guideline, there are exceptions, so here's some more detailed explanation.

Specifics

Configuration that goes in features and should be done on the dev site

• Boxes (custom blocks)
• Contexts
• Content types
• Menus and menu items
• Panels and mini-panels
• Settings for modules
• Spaces presets, including:
  • Dashboard configuration
  • Space-specific overrides
• Taxonomy vocabularies
• Views

Content editing that should be done on live

• All content entry (creation of new nodes--pieces of content)
• All taxonomy terms
• Content administration--e.g., mass application of terms to content
• Custom translations done through the translation interface
• URL aliases

Exceptions and special cases

While most configuration is done on a development site and pushed to features, there are usually exceptions--either types of configuration that don't have Features support or configuration that isn't appropriate to Features.

Custom block titles

Overrides of block titles (click the link to edit a block and enter a custom title) cannot currently be saved to features. If these are used, they must be manually repeated on stage and live.

Specific settings that should be excluded from Features

There are certain cases where settings should not go into features and should instead be managed through manual configuration on each site. These are settings that either (a) need to be different in different environments or (b) are needed early in the page load process, before Strongarm (the module that handles variables in features) is available to set variables.

For example, cache settings often need to be set differently on the live site vs. a development environment. So some variables that might be left out of features and instead handled manually might include:

• block_cache
• cache
• cache_lifetime

Summing up

Features is a powerful tool but can blur some traditional divisions--between code and configuration or between geek and form submitter. Keeping clear on where to do what is a key part of effective features-based site development. Accomplishing this will require working with your whole team to make sure everyone's clear on protocols, so the configuration changes they make and the content they enter don't disappear into some netherworld of lost checkboxes and incorporeal node bodies.