[#9717] - Unwanted interactions between "Category Blog" and "Category List" menu items
- Closed
- 9 Dec 2016
- Medium
- Build: master
- # 9717
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.
| Labels |
Added:
?
|
||
| Category | ⇒ | Components |
@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...)?
It should be fixed imho.
It should be fixed imho.
Thanks, @infograf768. Any Idea how? Split into two views? Act at the router level?
Honestly no idea. ;)
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.
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.
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.
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.
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.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-12-09 13:04:09 |
| Closed_By | ⇒ | brianteeman |
Indeed, it is old ( and odd
)