Metatag 1.7 adds a revision_id column and includes an update function to set the revision ID for all existing metatag rows. This update function is broken for multilingual sites using entity_translation. In the update function, for each row in the metatag table, the corresponding node is loaded with a condition on the language of the metatag row. However, for sites using entity_translation, there is only one row in the node table for each piece of content, not one for each language. Therefore, only metatags records in the default language are updated, rows corresponding to a translated version are skipped.

Attached patch fixes the update function. The patch is against version 1.7 and does NOT include a new update function. On the site where I had this problem, I didn't want to update to the dev version of metatag, therefore I added the following to a custom module to re-run the (now fixed) update. Re-running the update function is not a problem, it checks if there is anything to do before trying to do the work.

function my_custom_module_update_7001(&$sandbox) {
  metatag_update_7018($sandbox);
}

This could easily be adapted to metatag.install in metatag-7.x-1.x, all that has to be changed is the function name.

Comments

Frando created an issue. See original summary.

Frando’s picture

StatusFileSize
new943 bytes

Here's a proper patch to metatag-7.x-1.x.

Status: Needs review » Needs work

The last submitted patch, 2: metatag-fix-revision_id-update.patch, failed testing.

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 2: metatag-fix-revision_id-update.patch, failed testing.

Frando’s picture

Version: 7.x-1.7 » 7.x-1.x-dev
Status: Needs work » Needs review

damienmckenna’s picture

Ugh, sorry about that :(

damienmckenna’s picture

Should the new update script only run if entity_translation is enabled?

Frando’s picture

Not sure if there are other situations where this might happen (e.g. custom translation modules or an entity_translation successor or dunno). For sites where the update has already run successfully, it is basically a no-op, so I think there's no harm in just running it for everyone.

damienmckenna’s picture

I was able to confirm the problem with entity_load() using the following code:

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

// This assumes an English node with nid 2 that was translated into French.
$entity_type = 'node';
$entity_id = 2;
$conditions = array(
  'language' => 'en',
);
$records = entity_load($entity_type, array($entity_id), $conditions);
kpr($records);

$conditions = array(
  'language' => 'fr',
);
$records = entity_load($entity_type, array($entity_id), $conditions);
kpr($records);

$records = entity_load($entity_type, array($entity_id));
kpr($records);
damienmckenna’s picture

StatusFileSize
new1.03 KB

Rerolled, and improved the comment.

  • DamienMcKenna committed aea6a7a on 7.x-1.x
    Issue #2603458 by Frando: Fixed update 7018 for sites using Entity...

  • DamienMcKenna committed 35b66f7 on 7.x-1.x authored by Frando
    Issue #2603458 by Frando: Fixed update 7018 for sites using Entity...
  • DamienMcKenna committed fb5bf20 on 7.x-1.x
    Revert "Issue #2603458 by Frando: Fixed update 7018 for sites using...
damienmckenna’s picture

Status: Needs review » Fixed

Committed. Thanks!

Status: Fixed » Closed (fixed)

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