[#43379] - [5.2] Fix tagged items URLs for items with the same view
- Pending
- Medium
- Build: 5.1-dev
- # 43379
- Diff
- AlterBrains:patch-4
User tests: Successful: Unsuccessful:
Summary of Changes
"Tags > List of tagged items" view uses Joomla\Component\Tags\Site\Helper\RouteHelper::getItemRoute() to get a URL of individual item.
It uses Joomla\CMS\Helper\RouteHelper::getRoute(), if no JPATH_BASE . '/components/' . $explodedAlias[0] . '/helpers/route.php' is found.
Assuming that we have modern components with Router service, the tagged item URL is generated via Joomla\CMS\Helper\RouteHelper::getRoute().
This method adds the Itemid via this code:
if ($item = $this->findItem($needles)) {
$link .= '&Itemid=' . $item;
}
The problem is that the new routers are using the NoMenuRule and can auto-find the correct Itemid themselves.
Hence, there is no need to auto-find the Itemid here.
Another problem is that Joomla\CMS\Helper\RouteHelper::findItem() uses internal static cache of needles per view name.
Hence, if we have multiple components with the same view name, the second component will receive invalid Itemid because its URL generation will use the needles cache of the first component with the same view name.
Testing Instructions
Create multiple tagged items from different component but with the same view name.
Actual result BEFORE applying this Pull Request
See broken URLs if you browser the list of tagged items where we have the items from different components but the same view.
Expected result AFTER applying this Pull Request
Correct URLs respecting the components' specific Itemids.
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
| Labels |
Added:
PR-5.1-dev
|
||
What if someone extends from this class? Since $lookup is not private, they could access this and this change could break that.
Lots of Joomla classes can be extended and break smth. It's not a problem. We have an open source "easily extendable" project, I am sure that is should not contain the words "private" or "final" at all. Otherwise, it looks like commercial code. And making $lookup private will break extensions which can potentially inherit from class.
Coincidentally, the class is inherited by a RouteHelper class in com_tags, but that class overwrites the original lookup and it is also dead code at this point.
I don't see any overrides in TagsHelperRoute.
I would consider the risk for this to break anything minimal, but if we want to be nitpicking here, this would be a b/c break. For me, it is a weighing between fixing the bug and introducing a minor b/c break.
To be honest, I don't see any b/c breaks, it's just a bug fix. The people are waiting for this bug to be fixed since Apr.
Create multiple tagged items from different component but with the same view name.
@AlterBrains can you give an example what exactly to test?
You need two components, each with items which can be tagged using native Joomla tags, and items should have the same "view" name in request.
A test requires custom component with article view. Unfortunately, we don't have such extension.
@AlterBrains thanks for the answer. I don't understand it, no test.
This pull request has been automatically rebased to 5.2-dev.
| Title |
|
||||||
I reviewed your change and it indeed fixes the issue. A good catch. However, I see 2 theoretical issues:
$lookupis not private, they could access this and this change could break that.I would consider the risk for this to break anything minimal, but if we want to be nitpicking here, this would be a b/c break. For me, it is a weighing between fixing the bug and introducing a minor b/c break.