After a lot of working with features at the command line, drush feature reversions don't appear to actually do much in the way of reverting a feature. This is true of both fr [feature name] and fra. In all instances I've found myself having to open up the actual user interface and manually reverting from there.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | default_rings.png | 171.81 KB | lise.perceives |
| #10 | normal_rings.png | 172.28 KB | lise.perceives |
| #9 | articles-7.x-1.0.tar_.gz | 2.09 KB | lise.perceives |
| #9 | articles-7.x-1.1.tar_.gz | 2.45 KB | lise.perceives |
| #9 | overridden.png | 52.51 KB | lise.perceives |
Comments
Comment #1
westbywest commentedI seem to have this problem as well with Drupal 7.0, Views 7.x-3.0-beta3, and Features 7.x-1.0-beta2, only even the Features UI doesn't revert overridden views.
Comment #2
eclipsegc commentedYes, sorry, same issue, I'm reverting in the respective interfaces (views, page_manager, et al)
Comment #3
febbraro commentedI had a fix that is included in the most recent version of views for fixing the not reverting issue. Are you using beta3?
Comment #4
febbraro commentedI think this was fixed as a part of #1157048: Feature-packages appear overridden when they are not reopen if not.
Comment #5
firebus commentedReopening - this is the opposite of the duplicate proposed in #4
I've got this issue with Features 6.x-1.1 with a CCK feature.
If I make a change to MODULE.features.content.inc, `drush fd MODULE` should report an override, and `drush fr MODULE` should apply the changes to the site.
Likewise, if I go through the Features UI, I should see that the component is overridden, and I should be able to revert it.
Instead, most of these functions are unreliable, and revert does not work at all.
`drush fd` seems to always work, showing the override
`drush fr` sometimes claims to work, but does not actually revert the feature
`drush fr` sometimes claims that there's no override (immediately after `drush fd` has shown it!)
The Features UI sometimes shows the override, sometimes does not. If it does show the override, reverting through the UI does not resolve it.
The specific change I'm having this issue with is for 'allowed_values_php' on a field, so maybe this bug is specific to that?
Comment #6
czigor commentedI had the same issue and it turned out to be caused by #1316154: Features truncates file names without notification that the machine name is too long. Check if you have any truncated filenames in your feature. If so, choose a shorter machine name.
Comment #7
mpotter commentedClosing this for lack of activity. Please re-open this issue if you can reproduce it in the latest version.
Comment #8
lise.perceives commentedI think I am seeing this error.
Find 2 versions of a feature attached.
I enable version 0, then replace the code with the code from version 1. This gives me overridden in the list of features. Reverting the feature doesn't change the screen.
Drupal core: 7.17
Features: 7.x-1.0
Comment #9
lise.perceives commentedFiles attached.
Comment #10
lise.perceives commentedIs this component of this feature overridden? This decision is made by calling features_get_signature() a couple of times, and comparing the results. In this case $default and $normal are compared. See pictures attached of these 2 structures.
As md5 is calculated based on these objects, and the structures (when seen as text) are different, we end up with a status of overridden. When there's actually no practical difference.
See pictures attached of the 2 structures. The difference? In one case the weight is given with quotes, in the other without.
Comment #11
mpotter commentedSounds like this is now a dup of #1721926: Field Instance Export "weight" - brings me in a Override ping/pong - quotes and no quotes