Indeed, if first you add to lookup entry for menu item A
index.php?option=com_content&view=categories&id=9

And then for menu item B
index.php?option=com_content&view=categories&layout=print&id=9

• then the lookup entry for menu item A is wrongly overwritten by entry for menu item B

But i guess the reason that that line was added there is for

• the case that menu item A does not exist

if we want menu item B to be selected when menu item A does not exist then the correct fix is to keep that code but check if menu item A exists (aka it has an entry in the lookup structure)

so the question is do we want the a menu item that has a -specific- layout to
be selected by links that do not set a layout ?
probably not, so your fix seems good

When this will be merged? Today 3.8.5 was released!
To be honest I am not familiar with the workflow!
But it's a serious issue if the router ignores the layout of the menu entry.

1. All pull requests require at least two successful tests from individuals other than the person who submitted it to validate the behavior works as intended without introducing new bugs.

2. 3.8.5 only addressed regressions from 3.8.4 (the only reason #19488 went in, even though it's not a regression, is because it's a low risk change and I merged it before knowing we'd need a quick release and wasn't going to go through the extra effort to exclude it).

@RubbelDeCatc every Pull Request needs 2 successfully Test before Release Lead decide to merge or not.

I have tested this item ✅ successfully on a8e7596

To hopefully help this patch getting one more test, I give my testing instructions here...
I made two category list menu items, one with blog layout, one without (=default), but both took the same category.
Somewhere in the code (like a tmpl file, but not from category, more specifically the menu items target) I did
echo JRoute::_('index.php?option=com_content&view=category&id=19'); die;
where the string is the url from the menu item with default layout.
Before the patch the route became the one with blog layout.
After the patch the route had the (wanted) item alias with default layout.

I have tested this item ✅ successfully on a8e7596

To hopefully help this patch getting one more test, I give my testing instructions here...
I made two category list menu items, one with blog layout, one without (=default), but both took the same category.
Somewhere in the code (like a tmpl file, but not from category, more specifically the menu items target) I did
echo JRoute::_('index.php?option=com_content&view=category&id=19'); die;
where the string is the url from the menu item with default layout.
Before the patch the route became the one with blog layout.
After the patch the route had the (wanted) item alias with default layout.

As now this PR will break B/C:

• featured/article/category views create a link to category by JRoute::_(ContentHelperRoute::getCategoryRoute($displayData['item']->catslug)), which does not contains any layout information.
• if we are only have blogs (menu items) on website then that items won't be used in links.

As @ggppdk mentioned, instead of removing lines wrap them in conditions if (!isset(.....))

@csthomas

ok so the usage of layout-having menu items is desirable as a fallback choice of links that do not specify a layout

but after we add an entry in the lookup for the menu item B that has a layout

• (we add for both with and without layout cases)

then at later time while adding an entry for a menu item A that does not have layout,
how do we know that the currently set lookup entry without layout should be overwritten because it was added as a 'fallback' ?

i mean i think that my original suggestion with isset will fix this issue mentioned in this PR, but it will not handle the case i described above

For a single language website there is no problem because if the layout is empty then it overrides the default, before the if condition.

$this->lookup[$language][$view . $layout] = $item->id;

if (!isset($this->lookup[$language][$view])) {
	$this->lookup[$language][$view] = $item->id;
}

The problem is for multi language website when specified language (!=='*') overrides everything else. I have not found a solution for that.

@ggppdk I have found what you mean. Yes, it is very complicated, I wrote some code and I'm stuck on it.

@csthomas, @FPerisa, @RubbelDeCatc

i have made a PR, (i have not tested it yet, just checked logic of it)

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/19516

Closing in favor for #19945