After updating the module features to the new version (7.x-2.8), the command 'drush fra -y' is always giving us features to revert, although in the drupal interface the features are NOT overridden. We cleared the cache, we did a registry rebuild but the command is still reverting (unnecessary?) features.
New bug in the updated version of features!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

_Geertje created an issue. See original summary.

ron_s’s picture

Confirming that we're seeing the same issue. Downgrading to 7.x-2.7 resolves the problem.

mpotter’s picture

Priority: Major » Normal

I cannot reproduce this here. You'll need to give more information on exactly what kinds of features are being reverted and also do a "drush fd featurename" to see what the differences are that are being reported. Also report whether you are using any non-English language settings on your site.

If you are able to help debug this and can reliably reproduce the problem please try to use git-bisect to determine exactly which commit caused the problem.

Finally, it isn't uncommon to have "overrides" that persist even after reverting. However, those should still show as "overridden" and should show something with "drush fd" that would help determine the cause.

ron_s’s picture

We have a feature that is showing as "overridden", even though (a) there is no difference between the feature and the code stored in the database, and (b) the override disappears if we downgrade to 7.x-2.7. When running drush fd featurename, we see the same information that is shown in the Features diff:

Legend: 
Code:       drush features-revert will remove the overrides.
Overrides:  drush features-update will update the exported feature with the displayed overrides

Component type: info
Undefined index: counter DiffEngine.php:854                                                                                                                                               [notice]
Undefined index: x DiffEngine.php:854                                                                                                                                                     [notice]
Undefined index: y DiffEngine.php:857                                                                                                                                                     [notice]
  dependencies[] = date
  dependencies[] = ds
< dependencies[] = eck
  dependencies[] = eck
  dependencies[] = entity


Component type: views_view
                'hide_empty' => TRUE,
                'id' => 'field_contact_phone',
<               'label' => 'Phone',
                'table' => 'field_data_field_contact_phone',
              ),

The Views label that is being shown as out-of-sync definitely exists in the database. We even re-saved the View after checking that the label was present, and it still shows the feature and database as not being the same. Also if we clear full cache and rebuild registry, the same result still exists.

As soon as we downgrade to 7.x-2.7 and clear cache, the override disappears.

_Geertje’s picture

I tried it too.
I did a drush fd featurename and got this:

Legend: 
Code:       drush features-revert will remove the overrides.
Overrides:  drush features-update will update the exported feature with the displayed overrides

Component type: node
      'name' => 'Banner',
<     'title_label' => 'Title',
---
>     'title_label' => 'Titel',
    ),
  )

So, in this case, it has something to do with the title module. We are using a multi language site with English disabled.

It seems that (non-English) languages are an issue!

ron_s’s picture

I should have added, we are not using any non-English language settings.

mpotter’s picture

So this is two different issues:

1) On any non-English site, you will likely need to re-export your Features modules in v2.8 because of the regression that was fixed in the static cache clear involved in 2.7 that was trying to change your export language. Until you re-export your Features will be overridden if they were created in v2.7. Features exported prior to 2.7 should be fine. It was really v2.7 that was the problem.

2) The issue in #4 looks a bit different. Although I'd certainly try re-exporting the Feature to see what it changes in the code and whether that fixes it. Otherwise I'll need your help to do the git-bisect to determine which patch in v2.8 caused this. You don't really want to revert to v2.7 because of the bad static cache regression it contains that could break your site in weird ways depending on what other modules you have. (also a bit concerned about those DiffEngine notices too).

ron_s’s picture

I tried re-exporting the feature, and there was no difference in the code. Then I ran a test that involved making a change on the problem View that was not related to the label. I modified the Phone field format from "Default" to "Plain text", saved the View, re-exported the feature, and pushed the update to our test environment.

Taking these steps fixed the issue. I did not have to perform a revert or any other changes... the feature was automatically in sync. Still seeing the DiffEngine notices, but that could just be from our PHP settings being more verbose than typical.

It does show a dependency difference, but we regularly see this. I'm assuming that's something to do with the ECK module. It does not cause the feature to display as overridden.

Legend: 
Code:       drush features-revert will remove the overrides.
Overrides:  drush features-update will update the exported feature with the displayed overrides

Component type: info
Undefined index: counter DiffEngine.php:854                                                                                                                                               [notice]
Undefined index: x DiffEngine.php:854                                                                                                                                                     [notice]
Undefined index: y DiffEngine.php:857                                                                                                                                                     [notice]
  dependencies[] = date
  dependencies[] = ds
< dependencies[] = eck
  dependencies[] = eck
  dependencies[] = entity
mpotter’s picture

I wonder if the View was actually overridden in the DB and not using the code before. Your steps above would have updated this. I always forget that Views has it's own "overridden" setting when the view is coming from the DB instead of directly from code.

So, correct me if I'm wrong, but is 2.8 working for you now?

ron_s’s picture

This was a new View we had added via the feature, and I'm fairly sure it was not overridden in the DB. The behavior was different than we've ever seen in the past with Features, which is why I decided to post on the thread.

Yes, just checked again and looks like it is now in sync with 2.8.

mpotter’s picture

Status: Active » Fixed
_Geertje’s picture

Status: Fixed » Needs work

Hello

For me this issue is not fixed yet.
I recreated (drush features-export NAME) ànd updated (drush features-update NAME) the features, but they still stay overridden in drush (in the interface they are shown as standard). The message at drush fd NAME stays the same as #5.
I don't know which steps to take now, i'm sorry!

mpotter’s picture

Status: Needs work » Postponed

Yes, please see discussion in issue #2603578: _features_set_export_language is clearing drupal static cache too aggressively breaking search and possible many other modules that led to the change in v2.8.

Basically, v2.7 attempted to fix this issue with non-English Features being overridden. However, because Views has a static cache of the labels, v2.7 was doing a full clear of all Drupal static caches (minus some hardcoded exceptions). While this allowed non-English Features to work, it caused a load of critical problems with other modules.

So in v2.8 we have essentially reverted this fix. Now Features only changes the language to English during export but it does not clear any static cache. So it's now up to each module (like Views) to clear their own static cache in their own export function. It's not the place of Features to try and handle these module-specific issues.

If the problem is only showing up in drush, maybe we missed something that can still be fixed. But honestly, this is a very complex issue and I'm much less likely to mess around with this now that it has caused so many problems in the past few months. Sometimes we just need to live with overridden features in D7. There are lots of reasons a feature can be "stuck" as overridden and this non-English Views case is just another one.

I welcome any constructive patches to address this situation cleanly. But I'm tempted to mark this as "Wont fix"

Mouna Hammami’s picture

FileSize
58.91 KB
43.85 KB

Hi,
I used features 2.7 in my website which is multi-language. and its default language is Frensh.

I have recently decided to update features version to 2.10
But, i get the same issue described here but only with drush command.

Infact, the features drush commande features-diff shows me that there are features that are overriden (supplanté). while, when i visit structures/features in the drupal interface, all my features are in default status.

I tried to execute drush fr, but nothing has changed.
When i execute drush fu-all, i get many files update that are mostly translations of code comments or strings.
In this case if i execute drush fd, i have always the same table of overriden features as if i did nothing. In the drupal interface, as well as in the interface, features are always in the default status.
I don't understand why the interface dosen't show the same thing in the drush fd command?

Have you any idea about this?

interdruper’s picture

The following workaround fixes the issue for me: add the following line to drushrc.php:

$options['variables']['language_default']->language = 'en';

If you are not using drushrc.php, create one and place it in a suitable location. See details in:
https://github.com/drush-ops/drush/blob/master/examples/example.drushrc.php