Limitations of Features

Features is great, and together with Strongarm it takes care of at least 95 percent of the configuration you need to export. But some settings just aren't exportable by Features – since they aren't stored/exposed in a standardized way – and sometimes you get problems with the things that you managed to export.

Here are some more or less common problems.

• Exporting content. Features is made to export configuration, not content. There are attempts to allow Features to export content having UUIDs (universally unique identifiers), but I haven't tried it and can't vow for them. (http://drupal.org/project/uuid_features) If you want to move content between different sites you should check out the Deployment module.
• Blocks can't be exported. There are attempts to make block configuration exportable, but usually Drupalists use other modules to replace the standard block functionality (such as Boxes, Context, Panels everywhere or Rules Bonus Pack).
• Menu items are tricky to export. First of all, the target page for the menu item must be available on the target site – and it should be the same as on the source site. Secondly, you risk end up with two components exporting the same menu item – for example a view creating a menu link, and another feature exporting the same menu link. This often leads to one of the features being marked as overridden, and it may be difficult to revert that override.
• Sometimes Strongarm variables (or other components) gets marked as overridden, even though the settings are exactly as defined in the feature code. Sometimes this override only shows on the Features overview page – and everything is in default mode when viewing the feature details. One explanation for this is that while the settings in the database correspond to the feature code, the structure of the variables in the database might be slightly different. Usually this can be helped by re-exporting the feature, but not always.

When stuck with settings that can't be captured by Features, and you want to have all configuration stored in code, a common approach is to write an update hook. These are functions being run on module updates, and allow doing custom changes in the database – for example to move blocks around or turn on or off certain settings. Writing updates hooks is not covered here, sorry (but see links below for more information).