I am running into a new bug that has appeared over the past week since I have upgraded from 8.1.10 to 8.2.1. I have a multilingual site and have created translations for most of my nodes. Prior to this bug, I was able to create menu items and add the link as either a node # (/node/1874) or by using the autocomplete to reference the node title. So long as the menu language is set correctly for each menu, the link will automatically include the path prefix and link to the node translation correctly with the appropriate path alias.

Since I have upgraded to 8.2.1, this behavior has changed. If my menu link is entered as a node #, the menu link will appear as node/id instead of the path alias. I have to enter the title name and use the autocomplete to reference the node in order for the menu link to include the path alias when rendered.

CommentFileSizeAuthor
#10 drupal-menu-links-lose-prefix-after-cache-clear-11812915-10-D8.patch512 bytescorneboele
#8 drupal-menu-links-lose-prefix-after-cache-clear-11812915-8-D8.patch595 bytescorneboele
#6 drupal-menu-links-lose-prefix-after-cache-clear-11812915-6-D8.patch621 bytescorneboele
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

goodwillhinton created an issue. See original summary.

cilefen’s picture

cilefen CreditAttribution: cilefen as a volunteer commented
Title: Menu link bug - Multilingual » [regression] Menu links are no longer replaced by the path alias and translation prefix
goodwillhinton’s picture

goodwillhinton CreditAttribution: goodwillhinton commented

I am seeing a similar bug that I believe may be connected. I am adding relative links to translated content (ie /en-gb/contact-us) yet after a cache clear the link is rendered as node/id. I have discovered that if I enter the link as an absolute link (ie www.domain.com/en-gb/contact-us) that the path alias remains without an error.

corneboele’s picture

corneboele CreditAttribution: corneboele commented

I can confirm that after a cache rebuild the links display as untranslated. After saving the menu link (without changing anything), the translated path is displayed again. Seems that cache rebuild is missing a step compared to menu item save?

corneboele’s picture

corneboele CreditAttribution: corneboele at Aubergine IT commented

Could track it down to the file vendor/symfony-cmf/routing/ChainRouter.php. If I replace this file with the one from 8.1 the problem doesn't occur anymore.

  • Occurs when clearing cache via drush cr or rebuild.php
  • Routes are being rebuilt when caches are flushed (common.inc:1141)
  • In ChainRouter on line 183, Request::create was replaced by $this->rebuildRequest
  • Inside $this-rebuildRequest, $this->context->getMethod() returns '', where it should return 'GET' (which was default in Request::create) to match
corneboele’s picture

corneboele CreditAttribution: corneboele at Aubergine IT commented
FileSize
drupal-menu-links-lose-prefix-after-cache-clear-11812915-6-D8.patch621 bytes
cilefen’s picture

cilefen CreditAttribution: cilefen as a volunteer commented
Status: Active » Needs review
corneboele’s picture

corneboele CreditAttribution: corneboele at Aubergine IT commented
FileSize
drupal-menu-links-lose-prefix-after-cache-clear-11812915-8-D8.patch595 bytes

Status: Needs review » Needs work

The last submitted patch, 8: drupal-menu-links-lose-prefix-after-cache-clear-11812915-8-D8.patch, failed testing.

corneboele’s picture

corneboele CreditAttribution: corneboele at Aubergine IT commented
FileSize
drupal-menu-links-lose-prefix-after-cache-clear-11812915-10-D8.patch512 bytes
corneboele’s picture

corneboele CreditAttribution: corneboele at Aubergine IT commented
Status: Needs work » Needs review
stella’s picture

stella CreditAttribution: stella at Annertech for Glanbia commented

I was having a similar problem since upgrading to 8.2.1 and this patch has fixed it for me. Thanks!

smaz’s picture

smaz
Primary language English
Location England, UK
CreditAttribution: smaz at Five Mile Media commented

I've just run into a similar issue, and can confirm the patch fixes the problem.

We are using Drupal 8.2, using drush to clear the caches. The issue does not occur when you clear the caches whilst logged in, or using /core/rebuild.php.

Our site does not have any translations or related modules enabled, but was migrated from Drupal 6 - so possibly not just translated content is affected.

The issue is, as pointed out above, there is no method for the requests that are generated when trying to match paths to routes during a menu rebuild. Rolling back to an earlier version of /vendor/symfony-cmf/routing/ChainRouter.php also fixes the issue, again as pointed out above.

So the issue lies with one of three places:

1) Symfony, has an issue where method could be blank.
2) Drupal, where there should be a default method set if none present (as per the patch, though is that in the best place? I don't know)
3) Drush, should be causing there to be a method

I'm guessing though that if the issue is by interacting with Drupal from the command line, that other tools (i.e. Drupal Console) could have the same issue & therefore it not be up to drush to fix?

badrange’s picture

badrange CreditAttribution: badrange commented

I wonder if this problem is also valid for 8.2.6 and/or 8.3 rc1?

corneboele’s picture

corneboele CreditAttribution: corneboele at Aubergine IT commented

Yes, the problem is still valid for 8.2.7. I don't know about 8.3.

jzavrl’s picture

jzavrl CreditAttribution: jzavrl at NDP commented
Status: Needs review » Closed (outdated)

I can confirm this is not the case anymore with 8.3.0.

cilefen’s picture

cilefen CreditAttribution: cilefen as a volunteer commented

It would be good to find the issue that fixed it.

corneboele’s picture

corneboele CreditAttribution: corneboele at Aubergine IT commented

Drupal 8.3 introduced a new Router, which might do things different than the Symfony one.

For example I see the following code:

// HEAD and GET are equivalent as per RFC.
if ('HEAD' === $method = $this->context->getMethod()) {
    $method = 'GET';
}

IF the requests Drush made were HEAD requests, then this would resolve the issue.

But this is a wild guess.