Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
In a current project, features with metatags_quick fields as components almost always stay overridden because of cosmetic changes in the order of exported php-arrays – so we never know the true state of our features without deep inspecting them everytime. Nasty and irritating.
A "drush fd" would always result in something like:
Component: field 'module' => 'metatags_quick', 'settings' => array( < 0 => 'meta_name', 'meta_name' => 'description', > 0 => 'meta_name', ), 'type' => 'metatags_quick', 'module' => 'metatags_quick', 'settings' => array( < 0 => 'meta_name', 'meta_name' => 'keywords', > 0 => 'meta_name', ), 'type' => 'metatags_quick',
Thi behaviour has no practical impact on functionality whatsoever, and only happens with features that contain metatags_quick fields and only exactly these fields.
Did anyone experience this before?
Does anyone know where the problem could originate?
Comment | File | Size | Author |
---|---|---|---|
#16 | 1301552.patch | 674 bytes | valthebald |
#5 | Screen shot 2011-10-31 at 8.28.43 PM.png | 67.86 KB | bentekwork |
Comments
Comment #1
trrroy CreditAttribution: trrroy commentedYes, I have the exact same problem. Output from drush fd:
I thought at first that it might be related to making a change to a Field that existed in multiple Features so I consolidated all of my Fields into one Feature but the problem continues. When I send the Feature to another server I am unable to revert the Fields portion of that Feature. Drush fr will not work, I guess, because it tries to revert everything? The only way I could revert the other parts of the Feature was through the Features UI. The Fields portion remains overridden with the diff from 'drush fd' above. It seems to shuffle the position of the meta_name and permissions in the Features Fields array on every Feature update.
Comment #2
valthebaldCan this be related to #1263260: Wrong defaults in metatags_quick_field_info()? If so, then problem is gone in 7.x-2.1
Comment #3
valthebaldComment #4
bentekwork CreditAttribution: bentekwork commentedI am still experiencing this issue in 7.x-2.2 and 7.x-2x-dev. I created a feature from an existing content type that has metatag_quick fields. When I create the feature and revert the feature is overridden in the diff it is the order of the 0 => 'meta_name'.
Any suggestions on a fix?
Comment #5
bentekwork CreditAttribution: bentekwork commentedHere is a screenshot using the diff module.
Comment #6
tizzo CreditAttribution: tizzo commentedThat release definitely didn't fix it, we're still having the problem :-\
Comment #7
trrroy CreditAttribution: trrroy commentedI'm still seeing it too.
Comment #8
Maciej Lukianski CreditAttribution: Maciej Lukianski commentedI also experience this often.
Comment #9
valthebaldneed some hint to catch this, since I don't experience that :(
Comment #10
Maciej Lukianski CreditAttribution: Maciej Lukianski commentedIts fairly easy to reproduce.
Create one site with metatags and export content type to features.
Import this onto another site. Tweak something there (eg add a field, change comment settings etc) and re-export this feature so that it includes the field and new settings.
Now move the feature to back to the original site so that the content type there receives a new filed and new settings from the feature. Try to revert. Quite often feature stays as overidden, because of the above issue.
Comment #11
billstennett CreditAttribution: billstennett commentedWe get this all the time as well.
We use features to move from development / staging environments to production. Using "drush fr" to revert the feature appears to work correctly but the feature still appears overridden and it is related to the meta tags quick module I think.
See below - the output from a "drush fd" on a newly reverted feature:
==================================
Component: field
'module' => 'metatags_quick',
'settings' => array(
< 0 => 'meta_name',
'meta_name' => 'description',
> 0 => 'meta_name',
),
'type' => 'metatags_quick',
==================================
We are running CORE 7.12
and Metatags quick 7.x-2.4
Any suggestions much appreciated.
Comment #12
Taxoman CreditAttribution: Taxoman commentedComment #13
valthebaldAny reason to mark this as major? Bumping back to normal
Comment #14
Frank Ralf CreditAttribution: Frank Ralf commentedWe have been experiencing the same behavior with 7.x-2.5 and after spending a half day cleaning up our features we decided to abandon Meta tags (quick) from the current project. IMHO this is definitely a "major" bug as it makes Meta tags (quick) unusable for any site using Features.
The issue seems especially to happen when using Meta tags field within field groups.
Comment #15
valthebaldPlease try attached patch. Does it help?
Comment #16
valthebald...and here's the patch
Comment #17
Frank Ralf CreditAttribution: Frank Ralf commentedThanks for the quick response! Will try the patch asap.
Comment #18
valthebaldPatch committed to 7.x-2.x, please confirm does this solve the problem
Comment #19
valthebaldSince no report, I'm marking this as fixed
Comment #20
Frank Ralf CreditAttribution: Frank Ralf commentedSorry for not reporting back but we had abandoned Meta tags (quick) for the current project.
Just used the new Simpletest.me feature of Dreditor to test the above patch but it throws an error:
An error occurred while patching the project.
Comment #21
valthebaldThat makes sense - patch was already committed to git