Last updated February 17, 2016. Created on December 2, 2010.
Edited by vrwired, lanceh1412, nedjo, Harry Slaughter. Log in to edit this page.

Users of Features have identified several scenarios in which a feature might not revert (i.e. the Manage Features page or drush features shows the feature in the state of "Overridden"), even when all 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. Attempted to revert the production feature so the new feature settings are deployed.
  5. Feature simply won't revert and remains overridden.

This page lists various solutions to this problem, starting with general fixes and procedures and moving on to information about specific modules and ways in which they might not be working with Features, and how to diagnose this.

Table of Contents:

Disable and re-enable (the Silver Bullet Solution)

Read on to learn more specific scenarios and solutions, but often, 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 the Devel module, devel-reinstall (dre) disables, uninstalls, and enables the module. See heading on Dependent Modules below for more info.

Missing include()

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


Missing feature module files

Check your codebase

If you are pushing your custom feature modules by using source control, be certain that all required files have been checked in and exist in the problem environment. When updating and downloading features, additional files may be generated that must be added to source control.

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:
     Line 1
    '0' => $view = new view; 
  • Running drush fu on the feature results in no file changes to the feature.

Resolution (ex#1)

View not available to select to featurize

  • If view is not available to select, it may be that another feature already holds that view
  • However, if that is not the case, a workaround to this case would be to clone the view you are trying to featurize.

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' versions 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.

Problem with: Missing Dependencies

Missing dependencies can be caused by a number of reasons. Common causes are: a) dependent modules were installed since feature was enabled or b)a module requirement for an exportable is not detected.

a) 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.

b) Features automatically detects ctools exportables and add the modules containing those exportables to the dependency list. However, if a contrib module builds on user entered data (for instance, content_taxonomy on a specific vocabulary), You can export the vocabulary or the term reference field but features doesn't detect content_taxonomy as a requirement. If you don't enable the content_taxonomy module the field will remain overridden and unrevertable. This issue is likely to occur when creating features related to user generated content with extensions on its widgets such as menu links, vocabularies and terms or entities with UUID's.

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.

Problem with: Exported translatable strings

With many exportables translatable strings are generated for multilingual sites. These are exported in features.*.inc as t('english string') calls. However, if you're administrating your site with a different default language than en_US the feature might seem overridden. This is especially prevalent in views exports with translatable labels.

Resolution:Change the administrator account's default language to english or change the current user's session language to english when running a features-diff in the UI or via drush.

Problem with: PHP cache

Remember to clear your PHP cache (e.g. APC) after updating the code and before doing the feature revert.

Problem with: Apache cache

If you are using Apache web server then clearing the cache may fix the problem. I.e restart apache.

NOTE: This page is a summary of things raised in issue #744450: Why would a feature not revert?. It is incomplete — earn yourself some karma points by continuing to transfer relevant situations from that issue. Thanks!

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


OsamaBinLogin’s picture

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?

alex.designworks’s picture

With features you have 2 options:

  • Update = DB -> File
  • Revert = File -> DB
dnmurray’s picture

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

eworwa’s picture

Hi, I'm facing the problem related with fe_block module. I try the solution posted here but without success. I had enable/disable the bartik theme (that I think it's causing the problem) but without effect. I also try enableing/disabling all other core themes with the same result.

I had try the solution posted here in comment #12 but didn't work neather. I have updated all the modules related before doing all the test.

Any sugestion would be very apreciated.


vpshah86’s picture

Disable and re-enabling the feature worked for me

Daniel Wentsch’s picture

I'm about to go crazy on a Feature that stays overridden. It's the views part that keeps telling me, it's overridden. It's happening locally (so no syncing issues), it doesn't matter if I update or revert my Feature. Immediately after doing so it's again displayed as overridden. I did both, reverts and updates via Drush as well as the UI, cleared caches multiple times, disabled and reenabled the Feature – without success. I also removed the view from my Feature and re-added it. Same same.
The real fun part is that when I review overrides it's telling me "No changes have been made to this feature". Git confirms this: absolutely no changes after recreating the feature.

The view is newly created, not an overridden one from a module. It displays Nodes that act as Product Displays for Commerce.

I'm kinda desperate here, any ideas?

Update: Just found out something rather strange: I again removed the view from the Feature and tried to put it in a separate one. That's not possible! The entire Views fieldset is not showing up in the Feature UI, so I can't select it.

Update 2: I also can't delete the said view without first disabling the Feature. Despite the view now being removed from the Feature.

Daniel Wentsch’s picture

After somehow getting rid of the above problem by removing the view from the feature completely the same trouble starts again with a rather simple view.

Just don't get it. A table style view that displays nodes of a certain type and has a views bulk operations field attached. Always overridden, no changes on fu in code, and also still overridden on feature revert.

kenorb’s picture

If you're stuck at efault state (especially with Rules), check the differences using this code:

module_load_include('inc', 'features', 'features.export');
// $overrides = features_detect_overrides($feature);
$module_name = 'MYMODULE';
$def_objects = (array)features_get_default('rules_config', $module_name, TRUE); // Change rules_config into your component name.
$norm_objects = (array)features_get_normal('rules_config', $module_name);
// _features_sanitize($def_objects); // Does not work when sanitized (no difference).
// _features_sanitize($norm_objects); // Does not work when sanitized (no difference).
file_put_contents(__DIR__ . '/defaults.txt', features_var_export($def_objects));
file_put_contents(__DIR__ . '/normal.txt', features_var_export($norm_objects));

Then run again with _features_sanitize, and compare the changes.

See: #2701957: Feature revert doesn't detect overridden rule changes.