I have a context in a feature which, when updated and deployed to a staging site, is automatically reverted on that site (i.e. it does not show as the expected "overridden"). Here's my workflow:
1. Edit a context (which already exists in my feature), add a block to a region, and save. Context correctly shows "overridden" at /admin/structure/context
2. Do a "drush fd my_feature" and see the new block show up in the now overridden feature.
3. Update the feature, commit to git and push.
4. Ssh into my staging site, and check the state of all Features. All are in the default state.
5. Git pull, and verify that the updated feature has been pulled.
6. drush fl and note that my_feature is *still* in default state (this is incorrect: it should show "overridden").
7. Visit the page (on staging) which the context is active on and note that the added block is not present.
8. Visit /admin/structure/context on staging and note that the context is in the "normal" state.
9. Edit the context and save it, and suddenly not only does the new block (correctly) show in the region, but it now also shows up on the page the context is active on. This is bizarre!
I've worked with Features enough to know that something is wrong. I'm using version 7.x-1.2 of ctools and context 7.x-3.0-beta6. As far as I can tell, the new block is correctly added to the context by Features. I don't know why the staging site doesn't show the updated features as "overridden" instead of magically automatically reverting the feature.
Marking as "major" as this is pretty concerning.
Comments
Comment #0.0
burningdog commentedRealized I had to save the context, not just view it, for the new block to show up
Comment #1
hefox commentedContextes are true explortables so if they are "in database" only they will always be in default state. Sounds like on staging that was the case, but needed a cc all to refresh the caches and make it appear (which was what saving also did).