Feature-packages appear overridden when they are not

subscribing

subscribbles

Quick update on this specific symptom. It seems reproducible using current -dev of features, views and ctools. Simply create any view, add it to a feature, enable the feature and voila views are overriden regardless. Installing current .git of diff and trying to view, I see that the the "default" shows only "Line 1 - FALSE" while "current" shows the complete view. Screenshow attached

There were some missing pieces to Views/Features integration with respect to overridden and reverting. I committed some changes that I think should fix this and #1134202: Display_options 'overridden' problems

http://drupalcode.org/project/features.git/commit/b9d8002

I still see some weird behaviour, after downloading the latest -dev (May 21st).

If I clear all caches, drush fl and drush fd will give the correct answer the first time. However, any subsequent calls to either of the two functions will result in the views being listed as overridden, and the diff shows that the entire view is considered missing..

-Morten

Are these for views created before the views/ctools/features upgrade? if so i would recommend that you recreate your Features since the views/ctools integrate has had some changes on the views that may cause this.

I tried doing a drush fu NN, which resulted in no changed code, and a overridden state (except for the first check after each cache-clearing as described).

I confirm the behaviour in #5! I did recreate all my features...

At least, drush cc all; drush fl; gives me the right answers now!

Hi,

Still having the same problem with today dev branches of views, ctools and features.

I deleted a simple feature, recreated it and its shows as overridden in the views component.
The diff shows FALSE in the left part, It seems that my view is not really linked with the feature.

So I tried to disable that feature, deleted the according view, enabled the feature. The view was recreated but still displayed as overridden. Now reverting and recreating or updating with Drush works.

Disabling/Re-enabling the feature now deletes/re-creates the view but it still shows as overriden.

Willing to help, please let me know if you need more info.

Changing the status as we are at least 2 having this issue.

subscribing

subscribing

I can confirm the behavior in #5 with the latest dev versions of Features, Views and CTools.

drush cc all followed by drush fl shows a none-overidden status, while calling drush fl again is showing it as overridden.

To me it sounds like we are having some kind of cache problem. I will look into this.

//dixon_, NodeOne

I have one feature that always shows up as overridden in drush-fl but as "default" in admin/structure/features.

Subscribing, having the same bug: some of my features are displayed as "Overridden" while they are not.

Ok, I've done some debugging on this one. It all seems to go wrong when Features tries to get the signature for the default state in features_get_signature(). Instead of returning a "default" signature that should match the "normal" signature it returns a boolean FALSE. And the underlying reason to that is around line 623 in features.export.inc. It looks like this:

if ($default_hook && module_hook($m, $default_hook)) { //<-- We have $default_hook, but module_hook() returns FALSE
  $cache[$component][$m] = call_user_func("{$m}_{$default_hook}");
  if ($alter) {
    drupal_alter($default_hook, $cache[$component][$m]);
  }
}
else {
  $cache[$component][$m] = FALSE; //<-- This is returned instead, which is also what you see in the diff UI
}

The reason for module_hook() returning FALSE, is simply because the implementation of hook_views_default_views() isn't included.

I haven't had time to look much deeper into it, but after a quick look it seems that the declaration of the API versions differ, thus causing something to be recognized as not compatible.

Side note: there seems to be some stale legacy Views code in features_include_defaults().

I will come back looking at this again soon.

I couldn't let this one go, so I took another look at it before leaving the office, and found the problem :)

It all fails when features are generating the api declaration for all CTools components. More precisely it's the generation of the version string that fails. Features are generating it as an integer, but it needs to be a string for the version comparison to work. This causes CTools to recognize the implementation as not compatible, thus not including the default hooks under certain circumstances.

For a half day of debugging the fix is redicoulously simple. Ooooh I love dynamic code generation!! ;)

wow, thanks a lot _dixon!

the patch fixes the problem for me. note, that you have to re-export the feature once in order to apply the the version integer/string fix. afterwards, the feature will remain in default state as expected.

I too can confirm that this (#16) patch worked for me.

Confirming that the patch works for me too, a thousand thanks dixon_ !!

I can comfirm as well that the pach from #16 works. Thanks dixon!

+1 @ confirm: #16 works fine here, too. Hope this gets committed soon. :)

good catch @dixon_

Patch looks good + works great.

The patch works here as well.

The patch is everything I ever dreamt of ...

Great work @dixon_, thanks a lot!

Thanks @dixon_!
For those using drush make, here is a version of dixon_'s #16 patch without prefixes.

+1 for #16

#25 fixes my issue with features (latest dev) staying overridden with Views 7.x-3.0-rc1.

Ditto #27. Thanks @dixon_!

Thanks for the legwork on this one dixon_

http://drupalcode.org/project/features.git/commit/aa90585

Sorry for rattling up this old issue, but I ran into the same issue on Provide way to Import views/true exportables back to the database. As you can read there, I'm unable to pinpoint where the bug is introduced again. Is there somebody out there that can help with this one?