Feature stuck in overridden state due to buggy hook detection

Just curious, but does your module implement its own hook_node_info()?

I am having a similar problem with features when the base module implements this hook and the responsible module for that content type is mine (so features does not implement its own hook_node_info() in hook.features.inc ). Features keeps the node component as FALSE in its
"normal" settings, then compares that to the output of hook_node_info() "default", which are not the same.

These feature modules (there are three like this) always show overriden.

The problem seems to be in features.export.inc, in the function features_detect_overrides(). In my copy this appears to be happening at line 288:

        $compare = array('normal' => features_var_export($normal), 'default' => features_var_export($default));
        if (_features_linetrim($compare['normal']) !== _features_linetrim($compare['default'])) {
          $overridden[$component] = $compare;
        }

In the case of the node component, there should probably be an exception here.

Steve

Bumping this to bug report on component code

Attaching a suggested solution (as a patch against ver 6.x-1.0) as a patch file. It seems to be working for me as it should now.

Sorry, left some testing code in the last patch, adding another one without the testing code.

Changing status to get this patch reviewed

following

me too

Trying to clarify the title; there's a few similar issues.

From a brief look, this is not specific to node (on a seperate note, node specific stuff should not be in features.export [please patch against -dev if can].); the issue is that if you remove an item from an export, then add it back in via a non-features controlled hook and change it, features does not realize that that item is not part of the current feature, correct? If so, Ttat should be fixed generally.

Please try and avoid code style fixes (the spacing fixes) as they're a separate issue altogether.

The problem doesn't have anything to do with the cache, but rather in how features_get_default detects wether a hook has been implemented.

features_get_default blindly checks to see if a hook has been implemented (such as hook_node_info) by checking to see if the function exists, without actually checking where the hook was defined. It assumes that if the hook has been defined, then features is responsible for it! This means that features will mark as overriden any module that implements a hook that a component also implements, even if said component is not part of the feature.

I think we should be able to fix this by checking the file in which the function was defined and see if it matches the file where features expects to find it.

Also updating to the latest dev since this should be fixed here first then backported.

So I've dug into this a bit more and dealing with this at the level of features_get_default won't be possible. PHP provides no easy way to determine *where* a given function is defined. The only way to to this is to file_get_contents and grep the file for the function definition. Yuk. I tried this anyways and doing this resulted in timeouts. :-(

So there is no way to fix this bug at it's root until PHP provides a way to determine where a function has been defined. We need to fix it one level up in features_get_component_states.

Will post more details shortly.

So I've given up. This needs the attention of someone who knows how features works at a more intimate level. For those who just want this problem to go away, here's some code you can drop in at the beginnings of your hooks that features is erroneously detecting.

function hook_node_info() {
  // Terrible hack to get features to ignore this hook
  // @@TODO: Can be removed when this issue is fixed: #1042088: Feature stuck in overridden state due to buggy hook detection
  // @@TODO: When we upgrade to PHP 5.4 we can make debug_backtrace faster by specifying a limit
  $backtrace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS);
  if ($backtrace[2]['function'] == 'features_get_default') return FALSE;
  
  ...rest of the hook as normal...

feautures knows what component it currently handles for a module based on the .info features array, so it should be checking if it actually handles that component before calling information on it, at least as far as override detection goes.

Hi @hefox,

That's what I thought would happen, but does not appear to actually be the case. If you would like I can create a simple feature the demonstrates this problem and paste it here.

Attached is an example of a bad module that has this bug.

The module part defines the content-type using hook_node_info, and the feature defines a field. The feature is overridden and cannot be reverted.

This patch was done against 6.x, so not updating to needs review. It should be easily adapted to d7 as the code isn't that much different.

Here is a version rolled on the latest 7.x-dev. The first time I cleared cache after installing it I got errors around the foreach in features.export.inc complaining that the $all_features[$feature]->components was not an array for array_intersect. But after that initial error, subsequent cache clears were ok and I didn't encounter any problems. So might just need another isset() or is_array(). Marking this for review.

Hi mpotter,

your last patch #18 seems also fix #1721926: Field Instance Export "weight" - brings me in a Override ping/pong - quotes and no quotes

Here is a slight variation of the patch from #18 that also fixed the error when clearing cache the first time.

Really need to get some eyes on this to see if it has any other side effects.

(note this probably doesn't really "fix" anything in 1721926, it just potentially removes an overridden difference in a feature that might make it look that way)

Hmm, is this still an issue? Let's run the automated tester.

reroll

This is quite lovely. Thanks for the work here!

Committed to f87d486.