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?

Files: 

Comments

Yes, I have the exact same problem. Output from drush fd:

        'type' => 'metatags_quick',
        'module' => 'metatags_quick',
        'settings' => array(
>         'field_permissions' => array(),
          'meta_name' => 'description',
          0 => 'meta_name',
<         'field_permissions' => array(),
        ),
        'type' => 'metatags_quick',
        'module' => 'metatags_quick',
        'settings' => array(
<         'meta_name' => 'keywords',
<         0 => 'meta_name',
          'field_permissions' => array(
            'edit own' => 'edit own',
          ),
>         'meta_name' => 'keywords',
>         0 => 'meta_name',
        ),
        'type' => 'metatags_quick',
        'module' => 'metatags_quick',
        'settings' => array(
>         'field_permissions' => array(),
          'meta_name' => 'description',
          0 => 'meta_name',
<         'field_permissions' => array(),
        ),
        'type' => 'metatags_quick',
        'module' => 'metatags_quick',
        'settings' => array(
<         'meta_name' => 'keywords',
<         0 => 'meta_name',
          'field_permissions' => array(
            'edit own' => 'edit own',
          ),
>         'meta_name' => 'keywords',
>         0 => 'meta_name',
        ),
        'type' => 'metatags_quick',

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.

Can this be related to #1263260: Wrong defaults in metatags_quick_field_info()? If so, then problem is gone in 7.x-2.1

Version:7.x-2.0» 7.x-2.2
Status:Active» Fixed

I 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?

StatusFileSize
new67.86 KB

Here is a screenshot using the diff module.

Status:Fixed» Active

That release definitely didn't fix it, we're still having the problem :-\

I'm still seeing it too.

I also experience this often.

need some hint to catch this, since I don't experience that :(

Its 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.

We 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.

Version:7.x-2.2» 7.x-2.x-dev
Priority:Normal» Major

Priority:Major» Normal

Any reason to mark this as major? Bumping back to normal

Version:7.x-2.x-dev» 7.x-2.5
Priority:Normal» Major

We 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.

Version:7.x-2.5» 7.x-2.x-dev
Priority:Major» Normal
Status:Active» Needs review

Please try attached patch. Does it help?

StatusFileSize
new674 bytes

...and here's the patch

Thanks for the quick response! Will try the patch asap.

Patch committed to 7.x-2.x, please confirm does this solve the problem

Status:Needs review» Fixed

Since no report, I'm marking this as fixed

Sorry 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.

That makes sense - patch was already committed to git

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.