Incorrect path alias and "token" parameter in links

Yogesh Pawar → made their first commit to this issue’s fork.

Hi All,

I have created a patch for this issue which now will not append the token to languages when we flush cache manually from backend.

I have used the same code tweak mentioned by @bigboy with one additional condition which checks if the token is coming when we really flush the cache.

Thanks for filing the issue and for the patch. I finally had time to look into this, thanks for your patience.

The patch will most likely work to remove the token, but it will only fix one symptom of the problem instead of addressing the root of the problem itself. So unfortunately, we need to dig deeper.

The root cause of the issue is that the menu link derivatives are cached when they shouldn't, so our menu link derivatives aren't regenerated as needed. Currently, core doesn't allow to set correct cache metadata for derivative plugins without patches, so we need to use an entirely different approach. I've attached a patch that always adds one menu link plugin per language in the derivative plugin and then moves the actual link generation to the menu link plugin, where we can actually set correct cache metadata so that the language switch links are actually regenerated when they should be. When we check for access we now also check, if the menu link plugin actually has link information from the language switcher for the language code, so that we only display links that are actually generated by the language switcher service.

All of this combined should resolve the problems 1) and 2) from the issue summary. It would be great, if you could test the patch and report back whether it works for you.

The last submitted patch, 9: 3250223-09.patch, failed testing. View results →

@feyp,

Thanks for the new patch. I have checked the new patch and it does work and solves all the issues.

Thanks for the new patch. I have checked the new patch and it does work and solves all the issues.

@Yogesh Pawar Thanks for testing and reviewing the patch and confirming that it works for you. That's really helpful.

Unfortunately, there was still an unexpected test failure when running tests on Drupal CI, so we can't commit the patch like this.

I hard a hard time to reproduce this locally. Turns out this happens, because Drupal CI installs Drupal in a subdirectory. Attached is a new patch, which should hopefully fix the test failures.

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