Last updated April 28, 2014. Created on September 20, 2009.
Edited by gaele, mgifford, RobW, donquixote. 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).

Revert
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 feature

AttachmentSize
features.png76.37 KB

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

Comments

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.

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

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

thanks
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.