Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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!
Comment | File | Size | Author |
---|---|---|---|
#14 | execute-drush-fd.PNG | 43.85 KB | Mouna Hammami |
#14 | interface-features.PNG | 58.91 KB | Mouna Hammami |
Comments
Comment #2
ron_s CreditAttribution: ron_s commentedConfirming that we're seeing the same issue. Downgrading to 7.x-2.7 resolves the problem.
Comment #3
mpotter CreditAttribution: mpotter at Phase2 commentedI 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.
Comment #4
ron_s CreditAttribution: ron_s commentedWe 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: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.
Comment #5
_Geertje CreditAttribution: _Geertje at Pàu for Colruyt Group Services commentedI tried it too.
I did a drush fd featurename and got this:
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!
Comment #6
ron_s CreditAttribution: ron_s commentedI should have added, we are not using any non-English language settings.
Comment #7
mpotter CreditAttribution: mpotter at Phase2 commentedSo 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).
Comment #8
ron_s CreditAttribution: ron_s commentedI 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.
Comment #9
mpotter CreditAttribution: mpotter at Phase2 commentedI 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?
Comment #10
ron_s CreditAttribution: ron_s commentedThis 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.
Comment #11
mpotter CreditAttribution: mpotter at Phase2 commentedComment #12
_Geertje CreditAttribution: _Geertje at Pàu for Colruyt Group Services commentedHello
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!
Comment #13
mpotter CreditAttribution: mpotter at Phase2 commentedYes, 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"
Comment #14
Mouna Hammami CreditAttribution: Mouna Hammami commentedHi,
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?
Comment #15
interdruper CreditAttribution: interdruper at Interdruper commentedThe following workaround fixes the issue for me: add the following line to
drushrc.php
: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