I have a feature for a content type, where the field component is overridden. If I run a drush feature-revert on this feature it incorrectly empties field data.

The entity and field definitions are left in tact, but there's no data in the fields (with one exception). If I check the field_data_* tables in the database they're empty.

The one exception is a (file) field which is shared between content types. That data is left intact.

If I run the revert through the web admin I don't get the issue.
If I run "features_revert(array($module => array($component)));" from a test module there's no problem.

i've turned on mysql logging. The only thing of note it appears to be doing is writing to the cache_field table.

Any ideas on what could be doing this, or how to debug further? I'm at a dead end.

I can repeat the test easily and produce debug output on request.

Thanks

James

CommentFileSizeAuthor
#3 field-config.txt887 bytestunny

Comments

budda’s picture

budda
Primary language English
Location Cheshire
commented

It might be useful to log each $component to see at what point the destruction is caused?

in features.drush.inc the loop is:-

<?php
function drush_features_revert() {
  if ($args = func_get_args()) {
    module_load_include('inc', 'features', 'features.export');
    features_include();

    // Determine if revert should be forced.
    $force = drush_get_option('force');
    foreach ($args as $module) {
      if (($feature = feature_load($module, TRUE)) && module_exists($module)) {

        $components = array();
        // Forcefully revert all components of a feature.
        if ($force) {
          foreach (array_keys($feature->info['features']) as $component) {
            if (features_hook($component, 'features_revert')) {
              $components[] = $component;
            }
          }
        }
        // Only revert components that are detected to be Overridden/Needs review.
        else {
          $states = features_get_component_states(array($feature->name), FALSE);
          foreach ($states[$feature->name] as $component => $state) {
            if (in_array($state, array(FEATURES_OVERRIDDEN, FEATURES_NEEDS_REVIEW)) && features_hook($component, 'features_revert')) {
              $components[] = $component;
            }
          }
        }

        if (empty($components)) {
          drush_log(dt('Current state already matches defaults, aborting.'), 'ok');
        }
        else {
          foreach ($components as $component) {
            if (drush_confirm(dt('Do you really want to revert !component?', array('!component' => $component)))) {
              features_revert(array($module => array($component)));
              drush_log(dt('Reverted !component.', array('!component' => $component)), 'ok');
            }
            else {
              drush_log(dt('Skipping !component.', array('!component' => $component)), 'ok');
            }
          }
        }
      }
      else if ($feature) {
        _features_drush_set_error($module, 'FEATURES_FEATURE_NOT_ENABLED');
      }
      else {
        _features_drush_set_error($module);
      }
    }
  }
  else {
    drush_features_list();
    return;
  }
}
?>

Did you do --force to cause the problem?

hefox’s picture

hefox commented

Yea, it'd be nice to know when it's happening.

I think this is a duplicate, recall seeing something about if a month or 3 ago

tunny’s picture

tunny commented
StatusFileSize
new field-config.txt887 bytes

The destruction appears to be happening when field_update_field is called.

See the field_features_rebuild method in features/includes/features.field.inc, line 166.

If this line is commented out the data isn't lost.

I've attached a dump of $field_config. It appears correct. The config is identical when it's reverted through a browser, and no data loss occurs then.

So I've got a bit further, but I'm stuck again.

hefox’s picture

hefox commented
Status: Active » Closed (duplicate)

#1305226: Features install/revert/etc. sometimes emptying field data

Suspect it's a core bug

tunny’s picture

tunny commented

Thanks for pointing me at that thread, the explanation fits perfectly.

drush is running as anonymous and the access check being performed, whereas in the features UI I'm superuser and the check will be skipped.

arrubiu’s picture

arrubiu commented

Subscribe