Problem/Motivation

We have a multi-language menu with an item pointing to a node. When accessing a specific language where the node is not translated, the link does not appear because the menu_multilingual module filters it out. This is the expected behavior. However, with the translatable_menu_link_uri module, we are overwriting the link in the language where it does not appear with an external URL, so it should not consider the unpublished node condition.

Steps to reproduce

  1. Create a multi-language menu in Drupal.
  2. Add a menu item pointing to a node.
  3. Ensure the node is not translated into a specific target language.
  4. Enable the menu_multilingual module and the translatable_menu_link_uri module.
  5. Configure the menu item so the link points to an external URL in the targeted language.
  6. Try to access the menu in the language where the node is not translated.

Proposed resolution

The menu_multilingual module hooks into the pre-render phase, whereas translatable_menu_link_uri hooks into the preprocess phase. To resolve this issue, it is suggested that the menu link be altered in the pre-render phase.

Issue fork translatable_menu_link_uri-3472291

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

eduardo morales alberti created an issue. See original summary.

eduardo morales alberti opened merge request !10

eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented
Status: Active » Needs review
eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented
Parent issue: » #3252404: Avoid extra DB query per menu item

Previously applied the issue #3252404: Avoid extra DB query per menu item

eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented
Status: Needs review » Needs work

Also fails because \Drupal\Core\Menu\DefaultMenuLinkTreeManipulators::checkAccess, if the menu link is not updated before BlockViewBuilder::preRender.

eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented
Parent issue: #3252404: Avoid extra DB query per menu item »
Related issues: +#2595839: Menu link URL should be translatable, +#3252404: Avoid extra DB query per menu item
eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented
Related issues: +#3091246: Allow MenuLinkTree manipulators to be altered

After reviewing the Drupal Issue Queue the best short-term solution is to use the patch from #3091246: Allow MenuLinkTree manipulators to be altered to alter the menu link tree.

eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented

We will create a new branch and MR with the manipulators approximation if the issue #3091246: Allow MenuLinkTree manipulators to be altered is fixed.

eduardo morales alberti opened merge request !11

eduardo morales alberti changed the visibility of the branch 3472291-override-the-menu to hidden.

eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented

Created MR https://git.drupalcode.org/project/translatable_menu_link_uri/-/merge_re... using menu tree manipulators strategy.

eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented
Status: Needs work » Needs review
eduardo morales alberti’s picture

eduardo morales alberti
Primary language Spanish
Location Spain, 🇪🇺
commented
Title: Override the menu links on the pre render instead the preprocess » Override the menu links before BlockViewBuilder::preRender alters them
jsobiecki’s picture

jsobiecki commented
Status: Needs review » Postponed

Hello Eduardo,

Thank you for your patch. Unfortunately, I need to put it on pause. The reason behind this is that you are using code that is not part of Drupal core. The fragments you are using are still in development at the moment (https://www.drupal.org/i/3091246 ) and needs work.

Generally, I like the approach as it axe's some old hooks, but since it's not yet part of core, I'd rather wait.
Maybe good idea would be to start release 3.x after the dependent change will be part of both 10.x and 11.x branches of Drupal. I think axing 9.x and 8.x is not a bad thing at this moment.