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.
Multilingual nodes with translated fields don't always output correct language metatags due to caching.
If I view the node in english, the metatags are correct. Then, switching to another language (e.g. French), viewing the same node outputs the english metatags on an otherwise translated page. Only after clearing caches do the correct language metatags appear.
Comment | File | Size | Author |
---|---|---|---|
#16 | metatag-n2025425-16.patch | 1.08 KB | DamienMcKenna |
Comments
Comment #1
DamienMcKennaWhat display mechanism are you using for the nodes - Panels, normal page templates, Display Suite, etc?
Comment #2
moonray CreditAttribution: moonray commentedThe attached patch provides the global langcode by default if none is provided. This way the caching cid is correct.
Comment #4
moonray CreditAttribution: moonray commentedSame patch with fixed paths.
Comment #5
moonray CreditAttribution: moonray commentedTrying again.
Comment #6
DamienMcKennaIf the current entity doesn't support language assignment, or it's disabled, Metatag uses LANGUAGE_NONE instead of $GLOBALS['language_content']->language, so I don't think this is the best direction.
Also, please clarify what system is being used to display the entity as the $langcode value shouldn't be empty.
Comment #7
moonray CreditAttribution: moonray commentedmetatag itself calls the metatag_entity_view() function with the langcode being NULL in 3 instances. These are the cause of the problem.
In my particular case the call from metatag_ctools_render_alter() was the cause of the issue.
The reason I decided to use $GLOBALS['language_content']->language is https://api.drupal.org/api/drupal/modules%21node%21node.module/function/...
EDIT: Also see https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drup... (which ensures $GLOBALS['language_content'] is always set)
Comment #8
DamienMcKennaYes, I'm aware of the different reasons to use $GLOBALS['language_content'], however the $langcode value is different in hook_entity_view depending on different scenarios. The reason you're seeing an empty $langcode is because you're displaying the page with Panels, which doesn't work correctly with multiple languages as opposed to normal page displays, so any changes should go into metatag_ctools_render_alter().
Comment #9
moonray CreditAttribution: moonray commentedWhat about metatag_views_post_render() and metatag_taxonomy_term_view_alter()?
I'm not running through either of those function in my use case. Should those also include the settings of default value for $langcode? (I'd like to provide a full patch).
Comment #10
David_Rothstein CreditAttribution: David_Rothstein commentedI ran into this but honestly couldn't figure out how to determine the correct language to pass in for all cases.
I needed something that worked, and if the goal is just to bust the cache when necessary without affecting how the rest of the function uses the $langcode variable, here is one kind-of-hacky way to do it.
Patch applies against the beta7 release, but not against the latest dev code.
Comment #11
David_Rothstein CreditAttribution: David_Rothstein commentedSame patch, better filename.
Comment #12
DamienMcKennaCould someone please test the latest dev version?
Comment #13
DamienMcKennaComment #14
hefox CreditAttribution: hefox commentedPatch is being used on a project with multiple testers/developers and has not presented any problems yet and has fixed the issue.
Only tested with beta :/
Comment #15
hefox CreditAttribution: hefox commentedbeta9 version of beta7
Comment #16
DamienMcKennaThis adds an update script to clear the caches.
Comment #17
DamienMcKennaComment #18
DamienMcKennaCommitted. Thanks everyone!