The result otherwise can be a bit surprising

john-robenss-macbook-pro-2:hottopics_feature johnrobens$ drush fd hottopics_feature
drush cc all
Code: drush features-revert will remove the overrides.
Overrides: drush features-update will update the exported feature with the displayed overrides

Component: info
features[field][] = node-hottopics-field_is_visible
features[field][] = node-hottopics-field_leading_text
< features[field][] = node-hottopics-field_spreadsheet
features[field][] = node-hottopics-field_summary
features[field][] = node-hottopics-field_summary_of_papers

Component: field
'type' => 'text_textfield',
'weight' => '1',
< ),
< ),
< ),
< 'node-hottopics-field_spreadsheet' => array(
< 'field_config' => array(
< 'active' => '1',
< 'cardinality' => '1',
< 'field_name' => 'field_spreadsheet',
< 'indexes' => array(
< 'name' => array(
< 0 => 'name',
< ),
< ),
< 'module' => 'sheetnode',
< 'type' => 'sheetfield',
< ),
< 'field_instance' => array(
< 'bundle' => 'hottopics',
< 'display' => array(
< 'default' => array(
< 'label' => 'hidden',
< 'module' => 'sheetnode',
< 'type' => 'sheetfield_default',
< 'weight' => '14',
< ),
< 'notifications' => array(
< 'label' => 'above',
< 'type' => 'hidden',
< ),
< 'teaser' => array(
< 'label' => 'above',
< 'type' => 'hidden',
< ),
< ),
< 'entity_type' => 'node',
< 'field_name' => 'field_spreadsheet',
< 'label' => 'spreadsheet',
< 'settings' => array(),
< 'widget' => array(
< 'module' => 'sheetnode',
< 'type' => 'sheetfield_spreadsheet',
< 'weight' => '17',

john-robenss-macbook-pro-2:hottopics_feature johnrobens$ drush cc all

'all' cache was cleared in /Users/johnrobens/NetBeansProjects/ecolsoc/web#johnrobens [success]
john-robenss-macbook-pro-2:hottopics_feature johnrobens$ drush fd hottopics_feature
drush fr -y hottopFeature is in its default state. No diff needed. [ok]


This seems like a bad idea. Clearing the cache is very expensive and is something you want to avoid, especially on large sites. I can imagine plenty of use cases where you would want to revert one particular feature and do not want to clear your entire cache.

Don't you have to refresh every time anyway? In my example feature-revert certainly doesn't work if you don't.

Wouldn't you want to take the instance of the application you are updating offline/out of your cluster if you are doing a feature update?

I was working on the principle of least surprise. I was thinking that the functionality would not work without a refresh, and therefore, rather than surprise people with something that doesn't work it was better to refresh cache.

Maybe there is a smarter way - one that would not be available from people just running feature interfaces. Like keep an list of all the items changed and address caching issues more specifically. Certainly that would even go one better if the surprise could be taken out and a more efficient way of addressing the functionality could be found.

No you don't need to ;) Not the entire cache in any case, maybe a specific cache bin, and maybe a static cache or two. There are many different caches in use in a typical Drupal site :)

The most important thing though is that this should only happen when you are ready to. Say you are deploying a new piece of functionality, and you need to revert a number of components in different features, as well as import some data and perform some other updates. It would be very wasteful to clear the cache after the features are reverted, because your deployment is not ready yet. You would typically do a cache clear event at the end of the deployment script.

Just read the last paragraph of your comment. It seems I have misunderstood you. I thought you wanted to clear the entire cache (ie. drush cc all) at the end of any feature revert, but you suggest a smart way to this. Indeed, if a component of a particular module is reverted then by all means the module should clear its own caches if necessary. This is something that is already done in most Features implementations.

Here is an example for the function that reverts nodes. At the end it calls node_types_rebuild() which also clears and reinitializes the node type cache, as well as menu_rebuild().

* Implements hook_features_revert().
function node_features_revert($module = NULL) {
  if (
$default_types = features_get_default('node', $module)) {
    foreach (
$default_types as $type_name => $type_info) {
condition('type', $type_name)

Sounds like good stuff. I'll see if I can poke through the specific example I have and create a patch.

In this case feature-diff thinks that 'field' is not updated, so need to investigate that.