Canonical metatag on Views pages no longer refers to current, language page

Created on 8 August 2022, over 2 years ago
Updated 29 September 2023, about 1 year ago

Problem/Motivation

Since upgrading from Metatag 1.19 to 1.21, the metatag for the canonical link in Views pages no longer refers to the current language page (Italian) and instead it refers to the original language page (English).

For example, on the page example.com/it/articoli, this is the HTML diff since upgrading to Metatags 1.21

-<link rel="canonical" href="https://example.com/it/articoli" />
+<link rel="canonical" href="https://example.com/articles" />
-<meta property="og:url" content="https://example.com/it/articoli" />
+<meta property="og:url" content="https://example.com/articles" />
-<meta name="twitter:url" content="https://example.com/it/articoli" />
+<meta name="twitter:url" content="https://example.com/articles" />

This issue only affect Views pages which are in different languages from the default language of the website.

🐛 Bug report
Status

Needs work

Version

2.0

Component

Views integration

Created by

🇮🇹Italy andrewsuth

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • @bbu23 opened merge request.
  • 🇷🇴Romania bbu23

    I've just encountered this issue on some views pages on a multilingual site. I arrived at line 591 in web/modules/contrib/metatag/src/MetatagManager.php file:

        // Use the entity's language code, if one is defined.
        $langcode = NULL;
        if ($entity) {
          $langcode = $entity->language()->getId();
        }
    

    The language code that is later used in all token replacement calls seems to be declared here, and the $entity variable contains the Views configuration object. This object always returns the default language, at least for my case.

    I added a patch that might not be the best fix/approach, but I think it's good to start somewhere. I'm omitting to set the current language if the $entity is a view (probably it applies to all config entities, but idk about that) so that later on in the execution the language is set with the current detected language. We don't want to have the language of the config object, but the interface language (especially for views pages).

    I tried the option from comment #10, but that didn't work for me.

  • 🇵🇹Portugal introfini

    I had the same issue and the current patch fixed it. Thanks.

  • Status changed to Needs review over 1 year ago
  • 🇺🇸United States DamienMcKenna NH, USA

    Setting the status to "needs review" now that there's a merge request to review.

  • The issue is relevant to webform pages as well. I think it make sense to not extract language from any config entity, not only Views.

  • Status changed to Needs work about 1 year ago
  • 🇺🇸United States DamienMcKenna NH, USA

    I think it'd be worth improving the test coverage to catch this problem.

Production build 0.71.5 2024