Last updated October 7, 2015. Created on September 20, 2009.
Edited by nedjo, gaele, mgifford, RobW. Log in to edit this page.

Once you've got a feature installed and running, chances are that you'll want to fiddle and change in some of its settings. This is quite natural, and nothing to be afraid of. The Features module will notice any changes made to a component of any features and signal this with an Overridden state on the Features administration page.

Moreover, the Features module will allow an administrator to inspect the changes, revert to the original state and also to update the feature by applying the new changes to it (thereby possibly branching the feature). Here's how it works:

  • The View option displays a crude list of all the settings in the feature. If you have the Diff module installed, you can also use the Compare option to see what has been changed in a more convenient way.
  • The Revert option presents a list of the changed components in the feature, allowing the administrator to uncheck any of them before reverting the rest to its original state.
  • The Update option is identical to the Create feature page (read more), with the exception that fields and component list is pre-populated.

"Revert" vs "Update"

Use one of these operations if the configuration on your site (living in the database) differs from the definitions in your feature module (living in code).

This operation changes your site configuration (living in the database) to match up with the definitions in the feature module code.

In some cases (e.g. views), the revert operation will delete the respective configuration in the database, so the system will instead use the default configuration that is defined in the feature module's code.

Update / Recreate

The update operation will produce a modified version of your feature module, which matches up with the configuration found in the database.

What happens with this modified code, depends on whether you do this with drush or with the web-based interface.

If you update the feature via drush ("drush features-update [name]"), the modified code will replace your existing feature module in the filesystem.

The "recreate" button in the web-based administration interface is the equivalent to "update". However, the modified code will be provided for download as a .tar archive, instead of overwriting the existing feature module. It is up to the site builder to manually unzip and re-upload the modified module, replacing the original.

The different states of a featureLocking

The 2.x branch of Features introduced a UI for "locking" either individual component types of a given feature or the feature as a whole by clicking on a lock icon. Clicking the icon again will unlock the feature or component type.

While component types can be locked in a given feature, there is no way of locking individual items. For example, you can lock all views in feature_x, but can't lock only a single view.

A feature or component that is "locked" may show as overridden but will not revert, even if features revert is called. Thus, locking is a simple way to protect specific changes from being lost when features are reverted.

features.png76.37 KB

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


donquixote’s picture

If you do any of these operations, it would be interesting where the "modified" feature module goes. Is it downloaded? Or does it overwrite the existing modules in its location in the filesystem?

donquixote’s picture

I changed the documentation text, to make the fundamental things more explicit. For me it was not obvious until I tried it myself.
The phrasing and structure of the text, however, needs some improvement. Feel free to change it.

OsamaBinLogin’s picture

what does 'recreate' do? Seems to do something similar to 'update', rewrite code from db.

donquixote’s picture

I changed the documentation text.
Recreate is the web-based equivalent to update, just that it provides the modified code for download, instead of replacing the original.

enboig’s picture

And I think it is good if you add code to it.

I think it could be added to documentation so people don't waste time backing up its feature before running drush and copying back myfeature.module file after.

La vida és una taronja, què esperes per exprimir-la?

candelas’s picture

Thanks for the whole documentation. I am learning Features and I found "Needs review" in the state column. I searched in internet and found a good explanation in this comment by ianmthomasuk.
My English is not good to touch the documentation, so I prefer to put it as a comment :)

Both "needs review" and "overridden" statuses mean that the feature in the database does not match the feature in code. [...]

My workflow when this happens is as follows:

  1. Make sure the existing feature code is committed to version control.
  2. Run "drush fu feature-name" to replace the code for feature-name with the configuration from the database
  3. Diff the file with the version in version control so you understand the changes and can pick and choose which you want.
  4. Commit you changed feature code and/or revert the feature in Drupal

//trying to answer one question for each one that i make.
//this way, drupal will be more friendly and strong

tomas.teicher’s picture

"...It is up to the site builder to manually unzip and re-upload the modified module..."

What does it mean to reupload module? I don't expect it means just to upload feature files. Should I uninstall current version of my featrure and install new one? Or should I update website using update.php script?
I tried to do both ways but it doesn't updated my feature. I install new version of my features and it has status overriden, and no changes are applied.

Itangalo’s picture

It does mean that you should upload the feature files, and replace the old ones.

That a feature is marked as "overridden" means that the configuration in the database doesn't match the ones described by the feature files. If you revert the feature, it should reflect the changes in the files.

Not 100% intuitive, I know.

tomas.teicher’s picture

I tried it using reverting too.
But I have some other mistake, with reverting views. I will write an issue, if I don't find my problem.

anniewang’s picture

Am I missing something, or does it seem like going the Update route rather than Recreate saves a ton of grunt work involved in downloading and replacing all features module files each time meaningful changes are made to a feature?

agerard’s picture

Thanks for this detailed explanation of feature updates/overrides/reverts! I was finally able to feel confident in updating a complicated view, and the features status for this module now shows as 'default' instead of overridden. However, in the views page, 'view name' column, it's still listed as "Database overriding code." Would it now be correct to execute the available views operation of 'revert' to make sure the view is all in code? I'm a bit hesitant to try this on a production site without being sure that's the right way to go.