Original report
Made config changes locally (to a view).
Updated the associated Feature locally.
Migrated the updated feature code to production.
Attempting to revert the production feature so the new feature settings are deployed.
Feature simply won't revert and remains overridden.
Why would that be? Is this just weirdness? Is it due to views?
I love features -- but it seems like there's lots of little hiccups like this that are hard for the mere mortal to diagnose. Obviously I could make a small config change on production via the views UI, but that kind of defeats the one of purposes of features, no?
Attached is a diff of the relatively simple changes I was making to a view...Any suggestions/pep talks are greatly appreciated.
Reporting guide: Please be specific!
The issue title is quite broad. Whoever has this kind of problem, should do further steps to investigate.
What do you mean by "does not revert"?
A: The intended/desired/relevant functionality changes were not applied.
B: There is some unrelated noise causing the feature to be reported as overridden after the revert.
Use features diff (drush fd) to investigate what is overridden.
Or recreate the feature or use drush features-update (but only if the previous version is tracked in git) and then compare.
Which components are affected?
Please describe the components you were trying to change.
Which method did you use to revert the feature?
Did you use drush fr or did you revert with the UI? Does it make a difference how you do it?
Does flushing caches make any difference?
NOTE: Even if this is fixed after flushing the cache, we might still consider it a bug.
Are there changes between the environments?
Are there any modules enabled/disabled in the destination environment, which are not enabled/disabled in your local environment where you exported the feature?
Are there any other configuration changes which might affect the feature?
Do some contrib modules have different versions on different environments?
Comment | File | Size | Author |
---|---|---|---|
#86 | 744450-fix-revert-feature-contexts.patch | 585 bytes | eugene.ilyin |
#10 | Screen shot 2010-08-27 at 4.07.00 PM.png | 49 KB | texas-bronius |
#10 | Screen shot 2010-08-27 at 4.07.06 PM.png | 56.87 KB | texas-bronius |
#8 | Features Page.png | 127.49 KB | kenorb |
features-wont-revert.png | 23.99 KB | mpaler |
Comments
Comment #1
mpaler CreditAttribution: mpaler commentedWhen using views in your features, make sure you clear your views cache AFTER you revert.
Comment #2
loze CreditAttribution: loze commentedThis is happening to me with content types/fields, and contexts.
They will not revert, and "overridden" stays next to the component, along with the checkbox.
I only have one feature enabled, so I dont think its conflicting with another feature.
any suggestions?
Comment #3
cedarm CreditAttribution: cedarm commentedAt first I was reverting twice, which did work. It seems flushing caches immediately after doing the revert does the trick. This shouldn't need to be done manually, therefore I'm reopening this issue. See also #801088: views in a feature still say 'overridden' after I revert them
Comment #4
mikemccaffreyI am having the same problem when recreating a module to include a new context.
Even after revert attempts and cache clearing, it is still determined to show the Feature as overridden and the diff showing the code as being removed.
Comment #5
cedarm CreditAttribution: cedarm commentedIt'll probably be useful to include some more information in our statements, like what types of things are in the feature.
My feature that reverts after the cache flush is only a content type with cck fields. Things get a little weird when changing display order of cck fields and other fields because lots of weight attributes get updated, not all of which belong to the feature, but I understand what happens. (Making that more intuitive is another task, and is a general problem with exportables and drag-n-drop weights.)
I haven't used context so maybe I'm way off, but perhaps something similar is going on? Post the diff?
Comment #6
mikemccaffreyUpgrading to beta8 actually resolved this problem, but only after I had to actually recreate the feature with the new context for to be imported properly.
Comment #8
kenorb CreditAttribution: kenorb commentedThe same problem.
Tried 10 times, clear the cache, etc.
Overrides column has additional fields in info:
See screenshot for details.
Comment #9
xurizaemonI was seeing similar behaviour with features built and deployed on 6.x-1.0-beta6. Even deploying, then recreating on the deployment server and "re-deploying" (ie, uploading the files I'd just generated) didn't resolve it.
I was also seeing issues where CCK fields didn't appear on the node create form after deployment (though they did appear when editing the content type, just not when editing content).
I installed diff module in order to inspect the differences between the features, which was informative and may clarify the "differences" features module is seeing between your feature and the current state of your DB.
I just now bumped up to beta10 just now and regenerated my features; the issue seems to have been resolved with this latest Features beta.
Comment #10
texas-bronius CreditAttribution: texas-bronius commentedThought I'd follow this one, too. I too have the "unfixable overridden status" issue but of a different flavor, likely.
Shown in my attached screenshots are two completely unrelated features, both with the same snippet in "Default" that has nothing to do with either of the diff'd Features that I am certain is causing my woes.
Note: I suspect it has something to do with having recently installed and performed a data import with table wizard + schema + migrate.
[edit: I also just tried "drush fu ..." followed by "drush fr ..." and still have those overrides exactly as before]
[edit: I relinquish git merge of any blame, favoring migrate instead (see #12 below)]
Comment #11
texas-bronius CreditAttribution: texas-bronius commentedUpdate: My great un-revertable Features are revertable once again! I didn't stick around to confirm that they were in fact being reverted just not being detected as being no longer Overridden, but my culprit was something with Table Wizard (or migrate or migrate_extras-- but the Overridden diff suggests the former). I disabled tw (and with it migrate and migrate_extras) and my Overridden status vanished :D
fwiw, here's a capture with proof when repeated on staging:
Comment #12
obarillet CreditAttribution: obarillet commentedtexas-bronius: I experienced the exact same issue you did, and I tried to fix the same way (drush fu.. fr..) with no luck.
In my case, simply disabling migrate and migrate_extras modules did the trick, no need to disable table wizard.
Comment #13
cedarm CreditAttribution: cedarm commentedI'm also using table wizard, migrate, and migrate_extras. Haven't yet tried disabling those. drush fu, drush cc all works for me. Does anyone have ideas as to what in any of those modules would cause issues with Features?
Comment #14
texas-bronius CreditAttribution: texas-bronius commentedIf we're documenting things here, I'll add that a most odd thing is happening to me in a new way: I had been happily developing locally, updating features export code, moving the updated codebase to remote staging, and features-reverting to the new code. Tonight, however, this stopped working for me: I have verified that I am looking at the updated code and the changes are there, but Features will not recognize these as different ("Overridden") and still shows me Default (and prevents me from trying to feature-revert to the new codebase).
[edit:]
Just discovered
drush fr <feature_name> --force
, but it gave me no joy.[edit: Was able to resolve my issue somehow, but unfortunately am not sure how-- it involved a db export from staging back to dev where my features changes were originally made (and exported), running features-revert there (where one field was flagged "needs review"), then dumping db back to staging. Looks like all is well again .. for now!]
Has anyone ever seen it where it appears that Features is just not reading the updated .inc code?
Comment #15
Dane Powell CreditAttribution: Dane Powell commentedI am using Open Atrium and wanted to override a CCK nodereference field to reference another content type. A very simple change - I just added one line to features.content.inc to match the new setting. However, the field still shows up as overridden! If I diff the "default" and "override", the "default" file does not reflect what's actually in the file on disk. If I revert, it reverts to the "original" default, not the default that I just defined in the file.
Comment #16
Dane Powell CreditAttribution: Dane Powell commentedWhat's odd is that if I run
drush feature-update [feature-name]
, the changes are picked up - even though the newfeatures.content.inc
produced by Drush is the same as the one I generated by hand.Comment #17
karschsp CreditAttribution: karschsp commentedI'm having this same issue using Features 1.0. I have a feature that contains a view, a couple panel pages and quicktabs, but no matter what I do, the panel pages (page manager) will not revert. If I look in mymodule.pages_default.inc, the code is correct, but when I view the panel, it is the old version. I've tried reverting both through the UI and via drush, but no dice. I've cleared all caches multiple times as well, and disabled migrate, migrate_extras and tw. I can't for the life of me get this feature to revert. Well, just the page manager portion of the feature I guess. Anyone else have this problem related to features and panels?
Thanks!
steve
Comment #18
Woggers CreditAttribution: Woggers commentedI am having this issue with Features 1.0 as well. My features package is just a bunch of block contents (boxes) and block-settings.
The blocks themselves become available deployments but the block-settings area remains Overridden no matter what I try.
Comment #19
mikebell_ CreditAttribution: mikebell_ commentedI'm having a similar issue to #18
My feature refuses to revert, here is a screenshot of the diff http://skitch.com/digital006/dayfr/site-page-structure
http://skitch.com/digital006/dayfm/site-page-structure-feature << Screenshot of the feature
All the modules listed there are up to date and enabled.
The Page Manager stuff also has the same issue, it refuses to revert.
Comment #20
Woggers CreditAttribution: Woggers commentedCan we programmatically revert?
I've created a feature package and deployed it. When generating a new site through a custom install profile I've created - I have the feature package I've created automatically enable itself through the install profile.
The problem is, all the Blocks (boxes) do get enabled and I can see them if I go to Admin -> Blocks. My issue is that the block SETTINGS in my feature package never get assigned to them.
(ie. they don't get placed in any region, although the settings are passed in the features package?!)
If I manually go to the new site and REVERT, then they get placed in their correct region - but why do I have to revert? Shouldn't it be automatic when the module is enabled?
This is what I get on my features page on the new site when using DIFF:
DIFF Analysis
What exactly does thsi mean again? the LEFT is what is in the code and the RIGHT is what is in the database?
If my feature package contains the regional (block Settings) INC file, why would it not get deployed when the module is enabled?
Thanks!
Comment #21
texas-bronius CreditAttribution: texas-bronius commented@Straddle- The issue you describe sounds similar to my confusion-- see my #14 reply above for more details and possible resolution. Iirc, the features actually _did_ revert, they just didn't get detected as such, and so rebuilding the feature from deployment allowed me to get a "fresh copy" of the feature to pull back into dev and continue thereon out as originally expected.
One word to the wise: Sometimes I reload from remote deployment to keep the freshest dev going, and I use git to ship things back and forth. I think at one point I had confused my workflow with differing versions and didn't really recall that when you do a rebuild from both a db dump and a site dump, you don't _need_ to revert features at the destination in the first place.
Comment #22
mrfelton CreditAttribution: mrfelton commentedI have issues with reverting too - but for taxonomies. See #921982: Features does not detect change to taxonomy when reverting
Comment #23
willieseabrook CreditAttribution: willieseabrook commentedI'm getting revert problems too.
Features 1.0
A feature with a role and a view.
I change my view, recreate feature, replace old code with new code, verify changes with diff.
Deploy to staging, click revert, nothing. (Try multiple times)
Clearing cache, disable/enable the feature, even deleting the view and importing it manually, NOTHING will get features to pick up the fact that the features code has changed.
Comment #24
chrisshattuck CreditAttribution: chrisshattuck commentedI had this issue with roles and context and was able to fix it.
The problem was missing lines in the feature module .info files. So for example, I had a context that was stored in the [feature]_context.inc file, but there wasn't a correponding line in the .info file. Somewhere along the lines it got lost, and I'm not sure where.
I was able to solve the problem by adding the line back in to the .info file. For the context, for example:
Then I ran a
drush fu my_feature
and it was good to go. I did the same thing with another feature module that had some role data saved, but didn't have any .info lines for it.I'm switching the version here to 1.0 since the latest discussion seems to be around that version.
Comment #25
hefox CreditAttribution: hefox commentedFor those that are having issues with views/panels, it'd be good if you checked that the view/panel is also appearing overridden on the views/panel listing page, and try to revert it there. If that doesn't work, it's likely a views/panels issue.
For example, Features uses view functions to delete the in database version of a view.
Straggle: left is sorta what is in code, with some complexities, while right is what is in the database, basically what would go into code if feature updated.
To my knowledge, enable a feature on a site that has had code will not automatically revert it, but it will rebuild, or rather cache clear will rebuild if feature is marked as needing rebuild. Features usually do not provide enable/disable/install/uninstall* hooks, so it does things during cache clear; things that were already existed are detected as needing revert, but won't revert themselves. If features did automatically revert, you'd loose all your customizations each cache clear before ya got a chance to features-update >.O.
A lot of what features provides are 'faux exportables,' which were designed to be exportables originally, so are a bit ugly to work with.
You can add enable/install/uninstall/disable/update hooks to your your module's install file (.install will stay in the folder on drush features-update) if you needed for deployment, or do a mass revert after install modules, etc. I use update hooks.
Using diff module will likely be useful for those that haven't.
#931782: _features_sanitize: Type casting in array comparison causes is_assoc to fail with 1 item assoc arrays may be effecting some, but shouldn't actually effect the feature reverting, just showing as needs revert when doesn't.
Comment #26
dafederYeah I'm having this problem too. Only way I've found around it is to just disable the feature, delete the page and then re-enable the feature. So far I've just been having problems when I use a new feature to override an existing page on the staging site - we'll see if it keeps happening after deleting the old instance of the page from the db.
Comment #27
DamienMcKennaSubscribe.
Comment #28
wizonesolutionsSubscribe.
Comment #29
DamienMcKennaI agree with greg_harvey when he says that this issue is "a) WAY to generic to be a useful issue title for maintainers
and b) not at all targeted towards a specific issue." Because Features has several different ways of handling exportables each one has to be bugtested separately, e.g. the code that handles CTools & Panels (greg_harvey's issue) is different to Views, Content Types and many other portions, so each needs its own issue to handle the problems with reverting.
Comment #30
dafederAgreed, DamienMcKenna. For those having problems with **ctools pages not reverting** specifically, please bring discussion over to #813760: CTools Page manager pages do not revert properly
Comment #31
Harry Slaughtersubscribe - all devs in my current shop see this problem regularly.
Comment #32
wundo CreditAttribution: wundo commentedComment #33
texas-bronius CreditAttribution: texas-bronius commentedIt sounds like we are describing several different ways in which a Feature might not revert. I think this might be better served as a wiki page, because nobody can follow the various scenarios and posted workarounds. I would also like to post another failure to revert scenario, but will wait for a wiki. How about this one:
http://drupal.org/node/986932
Unfortunately, it has sat untouched on my screen for several days, and I won't get back to finishing out in any reasonable amount of time. Please feel free to continue migrating this growing knowledgebase into that handbook page, if it is deemed appropriate to do so.
Comment #34
DamienMcKennaI added a scenario where a View is stuck showing as "Overridden" when it clearly isn't: http://drupal.org/node/986932
Comment #35
hefox CreditAttribution: hefox commentedOnly project issues are autocompleted tmk.
Please test #931782: _features_sanitize: Type casting in array comparison causes is_assoc to fail with 1 item assoc arrays for that views issue, DamienMckenna
Comment #36
DamienMcKennaI identified my problem. I had been using hook_views_default_views_alter() to override some existing views from other modules (e.g. OG) but wasn't first verifying the specific view was present in the $views array, I was just overriding them. My fix was to change this:
to this:
Once I made that change the view no longer listed as Overridden and life was good again.
Comment #37
quentinsf CreditAttribution: quentinsf commentedsubscribe
Comment #38
volocuga CreditAttribution: volocuga commentedSame here. Using features_revert() in own installation profile, new views were added, but nothing changed for overriden views (such as taxonomy/term/%)
My code sample:
Does anybody know how to solve this problem?
Comment #39
wizonesolutions@volocuga: If you have overriden default views, then you have to clone them in order to export them properly. Features should have displayed a note about this when you were creating your feature. Apologies if you have already done this, but from the sounds of it, this is the situation you are in.
Name the clone something like custom_taxonomy or whatever it is. In my experience, the cloned view's path/menu settings will take precedence over the default one's, so your site should continue working. If you are using blocks or putting the view in Panels, you will have to update those though.
Comment #40
hefox CreditAttribution: hefox commentedComponent name, not hook name, is what is used when problematically calling features revert.
Component name is the identifier in the .info, views I believe (or is it view? too lazy to look).
Comment #41
volocuga CreditAttribution: volocuga commented@wizonesolutions, @hefox
Thanks, very useful comments
Comment #42
volocuga CreditAttribution: volocuga commentedSay I have the following in my .info file:
The identifier, that meant @hefox shown between "features[" and "][]" and is "views", right?
Comment #43
volocuga CreditAttribution: volocuga commentedIf I cloned this default view, it becomes a completely different view. Then how will Features know that this newly created view has to override the source default view?
Comment #44
hefox CreditAttribution: hefox commentedwizeone was refearing to when you want to override a default view that another module supplies; for example, views comes with a disabled taxonomy_term view that supplies overrides for taxonomy/ paths. Since two modules cannot define the same view in hook_views_default_views, they were suggesting a way around that: create a new view and not use the default view.
However, if you're not using a view that is supplied by another module, that is not needed.
(In general to override other module views, I export my view manually and override it in hook_views_default_views_alter (or manually alter the view to my liking), but those are a bit more advanced.)
"views" is the correct component name for views
Comment #45
wizonesolutionsThanks hefox. Sounds hardcore :) But yes, that's what I meant.
Comment #46
volocuga CreditAttribution: volocuga commentedSounds not good. I've done many modifications based on the view name, for example css classes and template overrides
So I assume that Feature can not override default views at all and I should do that manually :(
Comment #47
DamienMcKenna@volocuga: Features cannot override a default view exposed by another module, just like you can't have the same view in two different features, it'll cause problems and the view will disappear. What you need to do is add an instance of hook_views_default_views_alter() to your feature and add the view there (or just tweak the few settings you wanted to change); you'll have to do this manually, but there are some tutorials on how to do it if you search around, e.g.:
Comment #48
Grayside CreditAttribution: Grayside commentedThere is an experimental module in automating that (I have not used it): Features Override
Comment #49
DamienMcKennaHere's an example usage for hook_views_default_views_alter().
Lets say I have a view named "awesomecontent" that's provided by the awesome.module, i.e. there's a function awesome_views_default_views() which contains the definition for the "awesomecontent" view. I want to change how this view works, so I make a few modifications via the UI and then on admin/build/views it says the view is "Overridden".
There are two ways of getting my changes into code:
Method #1 - Easy
In my own module, e.g. moreawesome.module, I add an implementation of hook_views_default_views_alter(), e.g.:
I then export the view and paste its contents into the above function, inside the if() statement. Note that I've added an if() statement to first ensure that the view actually exists, which helps avoid a bug seen elsewhere. Before I'm done, though, I need to tweak the code slightly, so it would end up looking like this:
A slight alternative is to export the view to a separate file, e.g. "override.awesomecontent.inc", and then load that file, e.g.:
If you do that, just make sure to add the normal PHP opening string (a '<' with '?php' after it) to the start of the file, otherwise it won't load.
After that's all done, just clear the site cache to make the changes get picked up and revert the version in your current site. All done.
Method #2 - Hard
In my moreawesome module I still add an implementation of hook_views_default_views_alter(), but this time I manually change individual settings in the existing view rather than just replacing the whole thing. The first thing to do is work out what to change, and to do this use the Devel module to output the existing data in a readable format:
Then I export the overridden view and compare the values I want with what comes out-of-the-box and make the necessary changes. FYI I've found the best way of doing this is to start recreating the variable hierarchy to get to the setting I want, and then changing the bit I want, e.g. to change the path to the first Page display it would be like this:
I left the dpm() in function so I can verify the change happened as I wanted, and once I'm happy with the changes I comment it out or just remove that line entirely.
Comment #50
Grayside CreditAttribution: Grayside commented@DamienMcKenna That's some of the better documentation I've seen for that hook. You should put it somewhere.
Comment #51
DamienMcKenna@grayside: thanks, I added a handbook page for it: http://drupal.org/node/1014774
Comment #52
volocuga CreditAttribution: volocuga commentedAwesome!
Damien, thanks, you posted exactly what I asked for
Comment #53
capellic#16 did it for me.. Drush saves another day.
Comment #54
pcambraThanks Damien!
Comment #55
greta_drupal CreditAttribution: greta_drupal commentedFirst-time Features user. I created a feature of 5 content types from Site A. Installed/enabled the feature on Site B, where those same content types currently exist.* Get only feature "overridden". Dumb question, not specified in Features documentation: Should I be deleting all of the content types of Site B first, before employing the content-type features? That doesn't sound right to me. But not clear about Features 'putting code in features rather than database'.
* Simply want my shared content type modifications to be updated on other sites. (Export/Import to existing content type always generates error.)
If this module works as I hope, I intend to marry it.
Comment #56
carn1x CreditAttribution: carn1x commentedsubscribe
Comment #57
carn1x CreditAttribution: carn1x commentedSubscribe
I'm having 2 features exhibit weird behaviour:
feature1: one that won't revert no matter how many times I select Revert checkbox, although the changes appear to be imported
feature2: one that features which do Revert when I check revert, however they are still marked as override although the revert checkbox disappears by itself
In both cases, neither is provide an override tab, nor does the URL feature1/diff provide any output of what exactly is being overridden.
Initially both features had the behaviour of feature1, however the feature2 I manually added an include for feature2.features.inc into the feature2.module which seems to have gotten me a little farther. This trick unfortunately won't work for feature1 as there is no feature1.features.inc to include.
Comment #58
mradcliffeWould the number of fields affect not being able to revert in Features 7.x?
I have a feature with around 50 fields attached to it amongst other things, and sometimes a field will revert and sometimes it won't. I also can't seem to change anything via the Ui in Manage Display / Manage Fields with the feature turned on. It prints out the changed value, but reverts on page load.
I think these two are related, but not sure how to test that.
If my issue is performance-related, then it would be a good idea to use Batch or Queue API for reverting features.
edit: i narrowed down my issue to the fact that at some point features installed a duplicate field_name so it was reverting the field, but that field was not being used because most searches are based off of field_name instead of field id.
Comment #59
Kevin P Davison CreditAttribution: Kevin P Davison commentedsubscribe
Comment #60
hermes_costell CreditAttribution: hermes_costell commentedI just had a similar issue with block settings and content stored in the Feature. It appeared that I had old blocks that were somehow conflicting with the blocks being tracked in Features. I deleted those blocks and could revert without problem.
Comment #61
kenorb CreditAttribution: kenorb commentedExample: #1101256: Exporting field without CCK cause non-revertible Overridden status
When Feature has non-revertible Overridden status.
Comment #62
mpotter CreditAttribution: mpotter commentedIf you have a View that will not revert, also try going into the Views UI (the list of Views) and in D7 you can select "Revert" from the action drop-down menu on the right. After doing this, the view should shows as "in code" on the left.
I had this issue with a specific view where a new display was added by another developer and after I did my "svn update" I could no longer revert the feature either through the Features UI or via Drush features-update. Using the Views interface fixed the view for me.
Comment #63
shadcn CreditAttribution: shadcn commentedAlso, i noticed that when views ui module is disabled, some features (with views) will not revert. enabling view ui will fix this.
Comment #64
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI had this issue with uc_product_power_tools in a feature.
Whenever I enabled my feature, the settings for uc product power tools would be overridden.
here is a screen shot: http://drupal.org/node/1034144#comment-5041552
I think that it might be related.
Comment #65
lsolesen CreditAttribution: lsolesen commentedSubscribe.
Comment #66
trrroy CreditAttribution: trrroy commentedsubscribe
Comment #67
tinefin CreditAttribution: tinefin commentedsubscribe
Comment #68
Dane Powell CreditAttribution: Dane Powell commented@tinefin- please don't post 'subscribe' comments any more. Instead use the 'follow' link at the top of the page.
Comment #69
anthonylindsay CreditAttribution: anthonylindsay commentedI had a feature that would not revert today. It was D7, rather than D6, but I think it's still relevant because of the cause/solution.
I merged two git branches containing different versions of the same Views based feature, each with different displays.
As far as git is concerned, it merged the exported Views code just fine, but it left me with conflicting Views display pages. It took a LOT of poking to find out what was wrong, but changing one of the displays from page_1 to page_2 (and obviously clearing every cache going) sorted it immediately.
So the moral of the story is that Features was not to blame at all. It was bad Views code caused by a normal git merge. So the next time a feature will not revert, I shall be quizzing git and looking at the exported code before blaming Features.
Comment #70
jenlamptonI'm also having this problem in latest D7 version - but its the page manager items that won't revert. According to page manager, the panels are running from code. Features can't tell that though, may be related to #1529026: Features is unable to determine the status of my existing features
Comment #71
Grayside CreditAttribution: Grayside commentedrc1 is broken with regard to some ctools stuff. rc2 with a fix should be out sooner than later.
Comment #72
gregglesCan folks try this with the latest 7.x-1.x-dev code to see if that fixes it?
Comment #73
iamEAP CreditAttribution: iamEAP commented@greggles,
I tried with the latest 7.x-1.x dev and the problem remains. My specific case is a context. It actually appears as though the entire context file is never firing, as the default in features for the context file is:
- FALSE
And the info file's default shows:
- features[context][] = learn_training
Reverting (including trying with a --force flag via drush) does nothing.
Going to flip this back to "needs work."
Comment #74
hefox CreditAttribution: hefox commentedNeeds work implies a patch; a quick scan shows no patch.
"feature not reverting" is a generalized problem that is caused by many, many different issues that should be their own issue queue post. Only reason to keep this one open is to refer to other ones.
aimEep: features-rc1 was bust and messed up hook_ctools_api, so that is likely related to your context problem.
Comment #75
shark CreditAttribution: shark commentedThis is so weird. Even after disabling and uninstalling the feature module, then reinstalling it, the in-code changes aren't being brought into the database.
In my case it is the page_manager_pages which isn't updating.
Comment #76
DamienMcKenna@shark: Are you sure you have the "include('myfeature.features.inc');" line in your myfeature.module file?
Comment #77
Ronino CreditAttribution: Ronino commented@DamienMcKenna: You saved my day, just been messing around with my feature module and couldn't find why my panel page and view aren't created, then found that missing line you mentioned, added it and now it works. Thanks! Somehow this line must have gotten lost when I recreated the feature module...
Comment #78
Danny Englander@DamienMcKenna - How does the code in #76 compare to this?
include_once 'webinars.features.inc';
(or is it the same?) That's what I am seeing generated when I generate my feature.I have been struggling with the issue described here for a long time on various sites so still trying to determine the cause and if I should open my own issue...
Comment #79
DamienMcKenna@highrockmedia: They're effectively the same thing, though the include_once() line adds additional internal logic to ensure the file isn't loaded multiple times (which shouldn't happen anyway.
Comment #80
mpotter CreditAttribution: mpotter commentedChanging the priority of this since the only reason this Issue is open is for people to read the information about the various reasons a Feature might be stuck on Overridden.
The include_once line mentioned above is automatically added by Features the first time is exports a Feature. However, it is only added if you export something that needs the featurename.features.inc file. If you later add a component that requires this file, Features is sometimes not able to add the include_once, especially if you have ever manually edited the featurename.module file. Perhaps the code that adds this line to the export needs to be improved, but if that is the case then we need to open a separate issue thread on it.
Comment #81
kenorb CreditAttribution: kenorb commentedI'm experiencing now the same problem as described in #73 (but in 6.x).
I've the latest 6.x-dev
Comment #82
kenorb CreditAttribution: kenorb commentedThe following description explaining the case when the default Feature returns FALSE. Which is caused by missing include in the .module file.
Not any other scenarios.
Function: features_detect_overrides
In above code features_get_normal() returns normal view, features_get_default returns FALSE.
Within features_get_default(), the following condition returns FALSE:
So it seems that hook module_views_default_views doesn't exists, so that means that somehow the required include file module.views_default.inc was not loaded.
But it's loaded correctly for the other features.
The reason for that is the file module.features.inc is loaded for one feature where it works (with hook_views_api hook), but not for the other.
So the main reason of the whole issues is that .module file didn't include .features.inc file.
Working feature (.module file):
Non-working feature (.module file):
So now the question is, why the following code failed during export (file: features.export.inc):
Workaround
You have to add include manually to .module file (see other features).
Example:
Problem
As I understand, the following logic is:
1. If .module file doesn't exist, then create a NEW file
1a. If generated code for .features.inc file is empty, then write '// Drupal needs this blank file.'
1b. If generated code for .features.inc file is not empty, then add the include 'include_once '{$module_name}.features.inc'.
2. If .module file does exist, then copy over (don't touch).
So I think there is the wrong logic here.
1. I'm creating a new feature including e.g. few variables.
2. I'm exporting it, and .features.inc file is empty, because I don't need any hooks, so the .module file is blank as well.
3. Now I've decided to add views dependency and export the feature again.
4. In this case, my feature was exported wrongly, because it copied the old .module which contains blank file, instead of proper include for .features.inc, where I've my required hooks for views.
So in this case my feature is broken, because .module file doesn't include .features.inc to load the views.
Comment #83
kenorb CreditAttribution: kenorb commentedComment #84
timfernihough CreditAttribution: timfernihough commentedI have improved the code that adds the featurename.features.inc file to the export and submitted a patch as per comment #80 above. Please see the new issue thread created here: http://drupal.org/node/1875888.
Comment #85
crutch CreditAttribution: crutch commentedSame experience as #55. Not using a view, simply content type updates. Fields are not consistent across sites and can't get out of overridden. 1 error is says that a filed already exists in database.
Comment #86
eugene.ilyin CreditAttribution: eugene.ilyin commentedHello
I had a problem with revert context when you use module metatag. This small patch solves the problem. More info about this bug you can get in this issue http://drupal.org/node/1921344
Comment #87
eugene.ilyin CreditAttribution: eugene.ilyin commentedComment #88
eugene.ilyin CreditAttribution: eugene.ilyin commentedComment #89
JayDarnellI'm using Features 7.x-1.0 and I'm having issues with features not reverting as well. With my views related features I was able to fix this by manually clearing all the caches but I'm still having issues with features that are being used to capture content types and their fields - specifically a fiend that uses the File Field Sources 7.x-1.7
I changed an image field to include IMCE as a valid file field source and features said it was overwritten. I regenerated the feature and tried to deploy it out to my other sites but it won't take. I try reverting it but it refuses to work. I had to manually make the file field sources changes on each deployment site.
Comment #90
matthewv789 CreditAttribution: matthewv789 commentedFor those with issues with blocks using Features Extra (FE Block), I notice that the setting it's not filling in on revert is the custom block machine name. When I manually pasted in the machine name, the feature became default.
I did have a separate problem with the block settings for a webform-generated block (which doesn't expose the machine name) not reverting, but I don't know whether it's related.
Comment #91
hefox CreditAttribution: hefox commentedPlease open up seperate issue (if haven't already) for any patches/specific instances to fix
Comment #92
likewhoa CreditAttribution: likewhoa commentedThis is an old issue and it's becoming really confusing to see many of my features stuck on 'Overriden' and not being able to revert to default state. Patch in #85 is unrelated to this issue since it assumes you're using metatag module.
Comment #93
kenorb CreditAttribution: kenorb commented@likewhoa: This is usually related to specific contrib module which exporting components in the wrong way. You can check that by enabling Diff module first, and check the differences on new tab which will appear on Feature page (eventually by comparing changes via: drush -y fu my_module; git diff). Otherwise without any provided details what is the cause, it's not possible to solve it, because it's not a bug of the module it-self, but other modules how they implement the API.
Comment #94
samwilson CreditAttribution: samwilson commentedGiven that there is a whole documentation page devoted to helping us figure out what's going on with a stuck-overridden feature, maybe this issue can be closed and future problems can be raised as new issues? Becuase it does seem that things are usually solved by the 'other' module fixing up its exportability; nothing for the Features module to do.
I'll have a more thorough read through and see if anything else from here needs to be copied to that doc page.
Comment #95
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedRevert dependent features first. Then revert your feature
I have a feature, event_feature, with an instance to a date field. The field_base date field is defined in the event_date_feature.
event_date_feature is a dependency of event_feature.
drush en -y event_feature
sometimes shows the date field is missing.drush fr event_feature -y
and it says that event_feature was reverted.So I thought that the field would appear. It did not.
drush fd event_feature
shows that nothing was reverted.What worked was seeing that event_date_feature also had to be reverted as
drush fd event_date_feature
shows that the field is not defined.After reverting the event_date_feature, the field is defined.
I reverted event_feature again and the field instance showed up.
Is there anyway to make a feature-revert command line option that reverts all dependent features first then the feature itself? I guess that would be analogous to how enabling a module works.
Comment #96
mpotter CreditAttribution: mpotter commentedClosing this because a) wasn't a bug report, b) it's documented, c) there have been other commits and fixes to decrease revert issues. As in #94, any specific issues need to go to their own issue topics, this is too generic to continue.
Comment #97
dfletcher CreditAttribution: dfletcher commentedI hit this one when renaming a content type (and changing the machine name). Seemed to capture the settings fine on my dev site but cannot apply them directly to live site. Just FYI in case anyone else runs into this, had to make the name / machine name change by hand on live site and then it all worked fine.
Comment #98
drupal.ninja03 CreditAttribution: drupal.ninja03 at Publicis Sapient for Publicis Sapient commentedThanks for the tip on https://www.drupal.org/node/744450#comment-3143080!! This really saved my day and all the trouble! Cheers!:)
Comment #99
MrPaulDriver CreditAttribution: MrPaulDriver commentedSometimes when moving or copying module folders, one may accidentally place a feature module folder inside the same or another folder. The result could result in a duplicated feature or the hidden existence of one thought to have been removed.
Comment #100
kscheirer+1 for https://www.drupal.org/node/744450#comment-3143080. Found this issue via search.
Comment #101
dfletcher CreditAttribution: dfletcher commentedCrazy. Four years later and I still constantly hit this issue. Some stuff just refuses to be applied without explanation. This was first reported in Drupal 6. I don't know if this module will ever work like I want it to, super frustrating.
Comment #102
donquixote CreditAttribution: donquixote commentedThe title of this issue is a bit ambiguous, which is part of the problem.
There are two kinds of "does not revert".
1. The intended changes are not applied. This would be a real bug.
2. Intended changes were applied, but the feature still shows as overridden after the revert.
The second case can happen if different modules are enabled on the environment where you revert the feature, which would cause some differences when exporting the feature.
Some ways to distinguish the two cases:
- Use features diff (in the UI or in drush) to check the changes. Be careful with this.
- Recreate the feature, or use drush features-update, and then compare the changes.
- Check if the desired functionality change is active.
Usually by looking at the diff you should see if this is just noise, or if these are the intended changes you were trying to apply.
I am adding these steps in the issue summary.