Last updated March 7, 2013. Created by texas-bronius on December 2, 2010.
Edited by neerajskydiver, dooug, axel.rutz, alex.designworks. Log in to edit this page.

(This is a summary of issue queue #744450: Why would a feature not revert? for ease of access and declutter of the queue)

Users of Features have identified several scenarios in which a feature might not revert (Manage Features page or drush features shows the feature in the state of "Overridden"), even when certain that all the steps were taken to revert the feature to the version on file.

Typical workflow:

  1. Made config changes locally (to a view).
  2. Updated the associated Feature locally.
  3. Migrated the updated feature code to production.
  4. Attempting to revert the production feature so the new feature settings are deployed.
  5. Feature simply won't revert and remains overridden.

(rageguy)

Silver Bullet Solution

Read on to learn more specific scenarios and solutions, but 9 times out of 10 [need citation], disabling and reenabling the exported Feature module will do it for you. Quickest path to victory, therefore is the drush one-liner:
drush dre your_module -y
The command, provided by devel module, devel-reinstall (dre) disables, uninstalls, and enables the module. See heading on Dependent Modules below for more info.

Example symptoms / scenarios...

Below is a list of scenarios (by module) which cause problems reverting their data with diagnostic information.

General

Many Problems simply arise from a missing include in [myfeature].module:
If it does not contain this line, re-add it:

<?php
include_once('[myfeature].features.inc');
?>

Problems with: Views

Example #1

  • View created that has multiple pages which are added within the view as local tasks.
  • View added to the feature & exported correctly.
  • Enabled the Feature and reverted all components.
  • Site cache cleared.
  • View still shows as Overridden in admin/build/features but shows as Default in admin/build/views.
  • In admin/build/features/myfeature/diff the Default column shows a near-complete export of the view while the Overrides column starts with the following:
    <?php
    Line 1
    array(
    '0' => $view = new view;
    ?>
  • Running drush fu on the feature results in no file changes to the feature.

Resolution (ex#1)

Problems with: Table Wizard & Migrate

Example #1

Description needed...

Problems with: Blocks (via fe_block)

Example #1: Check the theme

Original site (local dev perhaps) shows Default state, when staged to remote shows Overridden. Feature contains features_fe fe_block item(s), and features-diff shows a block config with a theme name in it.

Resolution: Enable and disable core themes to match originating environment: fe_blocks captures block settings per-theme.

Problems with: Features namespace change

Feature name-spacing is used throughout a feature's files. If folder names are changed the feature will remain available and enabled but overridden and unable to revert.

Resolution: Change the folder name back to the original name-space found within the files as function names, filenames, etc.

Problems with: Modules version changed

Feature was created with earlier version of core/dependency module(s) and some parts of feature will remain overridden. This is usually a case of transferring features between websites, when it is easy to miss modules versions compatibility.

Resolution: Recreate all features that use new core/module(s) version and clear cache.

Problems with: Dependent modules installed since Feature enable

Feature was created with some set of dependent modules, shared, and later an additional module dependency was added. In terms of Feature as a module, this dependency does go into the .info so any new installations/enables of the Feature will work as expected, but for preexisting Feature implementations (dev/staging environment for instance), these dependencies will not automatically become enabled from a feature revert. This is very likely when sharing Features between development environments and Git branching.

Resolution:Either disable the Feature and reenable it, or manually enable any dependencies not enabled (see Feature Diff to expose them).

Problem with: Feature with Rules not reverting (in 6.x)

#1462546: Rules marked as "custom", won't revert using features

Resolution: Delete all the Rules that are marked as "Custom" status and are also "Overridden" by the Feature. It will change their Rules status to "default" and the Feature will also be "Default" state.

Note: Remove this when that issue is fixed in Rules.

------------

NOTE: This is an incomplete page, earn yourself some karma points by continuing to transfer relevant situations from #744450: Why would a feature not revert?. Thanks!

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

near the top:
> even when certain that all the steps were taken to revert the feature to the version on file.

to revert the database version of the feature to the version in the export file? Or revert the feature export file to the version 'on file' in the database?

the man may be gone, but the heroic struggle to mock him continues

With features you have 2 options:

  • Update = DB -> File
  • Revert = File -> DB

I'm not having any luck viewing the image linked above (img.skitch.com). AWS access denied error (in XML).