Unwanted interactions between "Category Blog" and "Category List" menu items

[smz]

Steps to reproduce the issue

• have a com_content category named "Category"
• have a sub-category of "Category" named "Sub-category"
• First create a menu item of type "Category Blog" for "Category", call it "Blog"
• Then create a "Category Blog" sub-menu of "Blog" for "Sub-category"
• Then create a menu item of type "Category List" for "Category", call it "List"
• Then create a "Category List" sub-menu of "List" for "Sub-category"
• In all of the above have the "Subcategory Levels" options set to "All" (so that subcategories are listed at the bottom of the page)

Now:

• Vist "List"
• Click on "Sub-category" (at the bottom of the page)

Expected result

Sub-category should be displayed in a "Category List" layout

Actual result

Sub-category is displayed in a "Category Blog" layout

System information (as much as possible)

Joomal 3.5.0 (but I think this is an "old" issue)

Additional comments

• Delete and remove from trash all the above created menu items
• Repeat the steps above but this time create first the "Category List" menu items and then the "Category Blog" menu Items
• Results are reversed

"Category Blog" and "Category List" are two layouts of the same view: apparently this is the cause of this unwanted interaction. "Ordering" of the menu items does not play a role in the behavior. Rank of their menu ID does.

[infograf768]

Joomal 3.5.0 (but I think this is an "old" issue)

Indeed, it is old ( and odd 😃 )

[smz]

@infograf768 ... but was it already known and considered "acceptable behaviour" or is it something that should be fixed?

Am I wrong, or this is the only case where we have two layouts of a view associated to two different menu items (at least in core...)?

[infograf768]

It should be fixed imho.

[smz]

It should be fixed imho.

Thanks, @infograf768. Any Idea how? Split into two views? Act at the router level?

[infograf768]

Honestly no idea. ;)

[smz]

Just noticed #9808 and I'm smelling a similarity between the twos...
maybe @Hackwar could drop in and have a look if he thinks those two issue might be router related...

[Bakual]

You would probably have to improve the routehelper file where it tries to assign a proper itemid. In your usecase it has two valid itemids and it takes the first one found (the one with the lower ID). You could maybe change it so it checks if the current itemid matches the found ones and then use the current, or add an additional check for the layout in use.

Certainly don't split the views into two. That would be a horrible idea.

[smz]

@Bakual

Certainly don't split the views into two. That would be a horrible idea.

Agreed.

Unhappily I don't think I have the competence to touch the routerhelper, but I'll try to put my nose into that...

As a general consideration, I don't think that the "pick the first match" logic, there, is a sound choice. I think that a "pick the best match" approach would had been preferable. The problem, of course, is defining "best".

A "perfect match" (current ID match) is of course at the top of the preferences, but then I can imagine other factors, like:

• ordering of the menu items (vs. database order)
• a "weight" based on the menu type, like, eg., "Featured items" wins over "Category Blog" which in turn wins over "Category List". Menu items types weights should probably be configurable for maximum flexibility.

[mbabker]

It is a "pick the best match" selection IIRC, but when multiple menu items get returned based on the best match query, it then uses the first item out of that result set. As for weighting, unless you're going to make that user definable, that's just opening a can of worms.

[smz]

@mbabker

It is a "pick the best match" selection IIRC...

I wouldn't call it a "pick the best match" if id doesn't pick the current item...

As for weighting, unless you're going to make that user definable, that's just opening a can of worms.

Agreed!! 😜

[mbabker]

I wouldn't call it a "pick the best match" if id doesn't pick the current item...

It's the "best" match given what the code supports, which may or may not align with your perception of what it should do.

https://github.com/joomla/joomla-cms/blob/3.5.1/components/com_content/helpers/route.php#L78

There are only a few of the possible query options used as "needles" for the lookup. From the looks of it layout isn't one of those. That can be problematic when you have one view supporting two layouts like the case here. In general the route helper for com_content is somewhat limited (as it's hardcoded to only use a few possible options like the view, id, and language), so making it smarter to deal with more combinations of options would help find routes more accurately.

[brianteeman]

i am closing this at this time as there has been no activity for a very long time and as of 3.7 the router code has completely changed. If you still have an issue with 3.7 then please open a new issue

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/9717.}