== Problem ==

Status of components in a feature after drush features-update does not align with the status shown by the component pages.

== Test Setup ==

  • Create a View
  • Create a Context
  • Export the view and the context into a feature
  • Change something in a view and in a context
  • Feature will show overridden state. Views and Context status pages will show overridden states for the corresponding view and feature, as well.
  • Run "drush features-update " bringing changes back into the feature code.
  • Feature will show "default" state.
  • Views and Context pages will still show the view and the context managed by the feature as overriden!

It does not make any sense to have Feature show all its components as "default" when in fact they are served from the database and the status pages for these components show them as overridden.

== Why Does This Happen? ==

The way Features determines if something is default or overriden is: it asks exportable component (e.g. Views) to create code that is equivalent to the configuration in the database, compares it with the code from the corresponding feature module (last I checked - compares the two with hashes, which has its own set of problems: e.g. element ordering sometimes causes wrongful "overriden" statuses). If the two are deemed equivalent Features shows the feature under question as "Default".

However, CTools and modules like Context and Views who seem to build their status pages using CTools-based status, actually check if settings are used from the database or from code. That's where the mismatch seems to be coming from.

== Solution ==

It's very important that Feautres, CTools and component status pages (e.g. listing page of all views and listing page of all contexts) show the same status (default or overridden). Looks like in one way or another drush features-update needs to invoke "revert" on the components.

Comments

cedarm’s picture

cedarm commented

Not sure about features-update invoking revert. I would expect to have to do features-update, followed by features-revert.

irakli’s picture

irakli commented

Maybe but, alas, features-revert does not do a thing in the scenario described above. In the use-case, after update Features thinks the feature is already in its "Default" state so trying to force features-revert just results in a response like: "Current state already matches defaults, aborting". Problem still persists.

cedarm’s picture

cedarm commented

But once this status bug is fixed, features-revert would do the correct thing, right?

I agree that statuses are shown incorrectly and need to be fixed. I'm only questioning the "auto-revert" bit.

irakli’s picture

irakli commented

Before it got broken, "features update" was doing revert as well. I am not saying it should, but if Features Update won't do revert - that would be a behavior change compared to what it used to be.

I think if the behavior is changed, Features will need a new status, e.g. "Equivalent" as in: code and DB are equivalent to each other, but it is not "Default" since Drupal serves configuration from the DB not code. Without new status, changed behavior will be very confusing because until feature is reverted it is not really "Default" and at the same time it is not quite "overridden" either because code and DB are producing the same configuration.

cedarm’s picture

cedarm commented

Thanks for the clarification. I am in agreement with you now.

robbiethegeek’s picture

robbiethegeek commented

We have seen that if there is a features update to a feature and the change is to an existing context that it will appear overridden in the context interface until a drush fr --force is done or a revert through the ui even if they are in the default state because we just updated the feature with what was in the database. I believe this issue is still happening.

hefox’s picture

hefox commented
Version: 6.x-1.0-beta8 » 7.x-1.x-dev
Assigned: Unassigned » hefox
Category: bug » feature
Priority: Critical » Major

I don't see this as a bug, but as an import (but not critical as it's not really breaking thing, just confusing) change.

I'm think it's fine for features to say overridden even if an item is the same in code and database -- all exportable outside of features follow this pattern TMK (show overridden even if code matches database, as the OP mentions).

One of my major objectives for this is to improve performance though; the current implementation involves a lot of painful rendering of what the code version versus the database version to see if it's overridden -- ouch!

My proposal is for an optional features hook that will take over deciding whether something is overridden.

mattyohe’s picture

mattyohe commented

Thanks to #836538-6: Misleading Behavior of Drush Features Update - Wrong Statuses for the heads up on --force, but this seemed to add even another layer of UX confusion. It appears that when running the force revert, it reverts Image, which is fine, but if you have a image style set in manage displays on a particular node, you are left with an overridden feature, and have to apply a normal revert as well. The reason for this it seems is that the force Image revert will blank out $fields['node-node_type-field_name']['field_instance']['display']['settings'] array, and thus you have an overridden feature until you perform a normal revert after the forced.

I guess I do see why this occurs, but from a user perspective, it seems that performing a command (features-revert) should have the "Same" outcome when --force is applied to it, in that my feature is reset to a state that has reverted (albeit forcibly), but then also reset to the state in code. If --force was not intended to do that, it definitely is unexpected to leave a feature in an overridden state when performing a command that normally would do this, yet when done with force does not.

mpotter’s picture

mpotter commented
Status: Active » Closed (won't fix)

Closing this for lack of activity. Please re-open this issue if you can reproduce it in the latest version.