Metatags corrupted when saving translated entities programmatically

When was the last time you updated Metatag? Can you please provide the exact version number you're using?

Or, more to the point, the Feeds integration wasn't updated to handle recent API changes.

Could you please test this with the current -dev release? Thanks.

Need confirmation that the problem persists with the current -dev codebase. Thanks.

I also have this problem using version 7.x-1.0-rc2 of 2014-aug-05.

To test this i added the following code in a hook_init(). :

  $node = node_load(54);
  node_save($node);

I think it has something todo with the following code in the function metatag_metatags_load_multiple :

  $metatags[$record->entity_id][$record->revision_id][$record->language] = $data;

When you save the entity an array with e.g. nl as language will be serialized. The next time you load the metatags it will be the data will already contain nl and the language is added again.

Edit:

When you save a node using the node form the entity that will be saved is :

[metatags] => Array
        (
            [title] => Array
                (
                    [value] => test | test
                )

            [description] => Array
                (
                    [value] => test
                )

        )

The language is not added here.

I'll take a look at this today, thanks.

I'm going to hammer on this a little bit, I don't want 1.0 going out with a data-corruption bug like this.

Data corruption = critical.

Can you please install the Devel module and try this:

define('DRUPAL_ROOT', getcwd());
include_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

$nid = 1;

// Load the node the first time
$n = node_load($nid);
kpr($n->metatags);

// Save the node.
node_save($n);

// Reload the node again.
$x = node_load($nid, NULL, TRUE);
kpr($x);

Add that to a php file in your home directory. Create a node with multiple translations, and update the $nid in the code snippet to that node. Verify that you can go through the normal edit processes and everything works fine. Then run the new PHP script and confirm that the data structures are borked again.

Now try applying the enclosed patch and go through all of the steps again with a new node, it should all work correctly now.

Doh! The file!

PS this is the last remaining bug before we can release 1.0, any help testing it would be greatly appreciated!

@grahamC: Thanks for pointing that out. So instead of checking to see if the array keys have a length of 2 (e.g. "fr") it needs to specifically load the list of available languages and work from that.

@DamienMcKenna,

I think it should be something like this. Patch attached.

@JeroenT: Thanks, you beat me to it :)

@grahamC: Ugh. Yeah, that's a tricky one, because metatag_metatags_save() isn't going to know whether the $metatags array was empty because your code manually set $entity->metatags = array(), which should blank out values for all languages, or if there are no values passed from the entity edit form which would only delete the record for the requested language.

How about "solving" this problem with documentation?

• Delete meta tags for the current language:
  

  $node = node_load(123);
  $node->metatag = array();
  node_save($node);
  

• Delete meta tags for all of the entity's languages:
  

  $node = node_load(123);
  foreach ($node->metatag as $langcode => $values) {
    $node->metatag[$langcode] = array();
  }
  node_save($node);
  

I've updated the patch with a note in the developer section of the README.txt file to note the issue.

Anyone have any feedback on the latest patch? And would a disclaimer in the README.txt be sufficient guard against confusion for people directly manipulating the entity meta tags?

I tested the following situations as suggested in #11:

• Without patch: Using node edit form: Works
• Without patch: Using node edit form: Data structure is wrong
• With patch: Using node edit form: Works
• With patch: Using node edit form: Works

About directly manipulating the entity meta tags, I don't think if there is another solution to fix this.

Without reading any of the history here and considering that this workflow is contrary to how field values are saved, I find this incredibly confusing.

@Dave: Any recommendations would be greatly appreciated.

@Dave: So instead of re-saving all languages, I should maybe just use the same language-check but then only save the current language, matching the effect of submitting an entity through the normal entity edit form?

This version just saves the submitted language.

I just checked - when you do a node_load() on a node which has content in multiple languages (via Entity_Translation) it does indeed contain multiple language values for each field all contained within the one $node object, just like grahamC said. I need to test how the data submission works for fields and then see what it'd take to make Metatag work the same way. Argh.

Food for thought. This restructures the form fields to use a nested structure per language, similar to the Form API way of doing it. I've tested it with nodes, users and terms and it appeared to work correctly. When using node_save() it will update the values if they exist, e.g. $node->metatags['en'] will be updated, but just having $node->metatags equal to an empty array will not make any changes. Is this acceptable?

Lets see if this makes the tests compete.

Go testbot!

Closed a duplicate: #2332259: Conflict with Scheduler module

Argh, the submodules all need to be updated.

Some updates to the Metatag:Context module so a) it still works, b) is backwards compatible with previous configurations, c) THE TESTS PASS (at least locally)!!1!

Go testbot! :-p

Actually it needs further work to make integration with the Context UI work, right now just the By Path ui works.

This seems to resolve the context_ui problems too.

There isn't as much funny stuff going on in metatag_panels or metatag_views as metatag_context, so I think they'll be ok.

This version properly handles the scenario where $entity->metatags is an empty array, i.e. all meta tags for that id/revision combination are deleted.

Would one (or several) of you here please test out my latest patch to let me know if it works for you? This is the last blocker for 1.0 and I'd like someone else looking over my shoulder so I don't accidentally mess it up (again). Thanks!

This version resolves a problem when creating an entity that the metatag values were not set to the correct language. I also changed the tests to the "Metatag" group, to make it easier to run all tests (drush test-run Metatag).

I've tested the patch in #46 rather extensively and have committed it as-is. I'm going to test it tomorrow a little more with a few additional test sites, if there are no problems then I'll release 1.0. Thanks all for the help!

I spoke too soon. There were several scenarios which were incorrectly handled by the code committed previously:

• The logic in metatag_entity_update() for checking if an entity's language had changed was executed after the language value would have already changed; as a result it was necessary to directly check the $entity->original->language value.
• When a node had its language setting altered, the node's old language record was not removed.
• When a node had its language setting altered, the meta tag values were not changed over to using the new language.
• There was old code in metatag_metatags_save() that would re-load the previous revisions metatag data and save it with the new revision ID. This was the wrong way of handling this issue as it clashed with the need to be able to correctly handle entity_save / node_save.
• The workaround for the previous issue was to instead load all of the meta tag data for languages, other than the one being currently edited, in metatag_metatags_form_submit() and allow it to be saved via metatag_entity_update().
• There were complications with logic for the above between the scenario of editing an untranslated node, versus editing the translation of a translated node; in the first scenario the $new_language would equal $entity->language, but not so in the second scenario, which could lead to false positives and both corruption & loss of data.

This patch resolves these issues.

I've tested the latest patch a bunch more times on different entity types, and it all seemed to be working ok, so I'm committing it!

Still corrupted (description and abstract are the keywords I tested) using
Feeds -dev
Metatags -dev

I did a quick & dirty fix by updating like this on metatag.feeds.inc and it worked.

  // Assign the value.
  //$entity->metatags[$name]['value'] = $value; <- commented out and replaced by the following line
  $entity->metatags[$entity->language][$name]['value'] = (is_array($value) ? $value[0] : $value);

The node form generated metatags array has 'und' as first level element of the array and the value that comes from feeds is an array on my case

Lets handle the Feeds integration in a new issue: #2347193: Feeds integration borken in 1.0