[#48459] - [6.2] [AI] Fix tag filter ignored on cached category pages (#47797)
- Pending
- Medium
- Build: 5.4-dev
- # 48459
- Diff
- wakqasahmed:fix/47797-category-cache-filter-tag-v2
User tests: Successful: Unsuccessful:
Pull Request resolves #47797.
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
With System Cache set to Conservative or Progressive, com_content's category view caches its output keyed only by a whitelist of "safe" URL parameters (Cache::makeId() in libraries/src/Cache/Cache.php, fed by $app->registeredurlparams). com_content's DisplayController registers catid, filter, filter_order, etc. as safe params, but never filter_tag — so a request for ?filter_tag=2 gets served whatever was cached for that category first, tag filter or not, since the cache ID doesn't change when the tag changes.
Added filter_tag (as INT, matching how both CategoryModel and ArticlesModel already read it) to the $safeurlparams array in components/com_content/src/Controller/DisplayController.php, so the tag filter is now part of the cache key.
Testing Instructions
I traced this by reading the actual cache-key code (ViewController::_makeId() → Cache::makeId()) rather than assuming from the issue description, and confirmed the whitelist is the only thing that determines what varies the cache ID. I didn't add an automated test — this is a single-entry addition to a static safe-URL-parameter list, and exercising it end-to-end would need a full running Joomla install with page/view caching enabled (this repo's existing coverage for that is Cypress system tests against a live instance, not something a unit test can reach). Manual verification matches the reporter's own repro:
- Global Configuration > System > Cache: set to Conservative Caching.
- Open a category blog page whose articles use tags.
- Visit it once with
?filter_tag=1, then again with?filter_tag=2(or vice versa) — before this fix, the second request returns the same cached HTML as the first; after the fix, each tag value gets its own cache entry and the filter is respected.
Actual result BEFORE applying this Pull Request
Tag filter is ignored on cached category pages — whichever tag was requested first gets served for all subsequent tag values until the cache expires.
Expected result AFTER applying this Pull Request
Each filter_tag value gets its own cache entry, so the category page correctly reflects the requested tag filter even with caching enabled.
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
(Rebased onto current 5.4-dev from #48445, which had fallen behind; same commit content.)
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End com_content |
| Title |
|
||||||
You're right, and I should have traced this further before opening the PR. The tag-filter select on the Category List view (tmpl/category/default_articles.php) lives inside a real <form method="post">, submitted via a button, not auto-submitted or GET. That POST request has vName='category' with layout='default' (not blog), which hits the existing cache-disable condition at DisplayController.php:81-87 before $safeurlparams/filter_tag is ever consulted. So the fix here has no effect on the real, reachable path — the collision I reported only reproduces by editing the URL directly as a GET request, which isn't how this control is actually used. Closing this out.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-09-19 04:06:05 |
| Closed_By | ⇒ | wakqasahmed | |
| Labels |
Added:
bug
PR-5.4-dev
|
||
@joomdonation Should the corresponding issue be closed, too?
what about extensions - surely they can have this problem
| Status | Closed | ⇒ | New |
| Closed_Date | 2026-09-19 04:06:05 | ⇒ | |
| Closed_By | wakqasahmed | ⇒ | |
| Labels |
Removed:
bug
|
||
| Status | New | ⇒ | Pending |
Sorry my bad. Check it more carefully, I see that tags can be selected at Category Blog layout, so this PR appears to be valid
Thanks for taking a second look — glad it's not actually dead code. To close the loop on my last comment: I was wrong to retract, I'd only traced the Category List / Filter Field=Tags path and missed that Category Blog also exposes the tag filter and hits the same cache key. Leaving this open, no changes needed to the diff itself.
@brianteeman on extensions — this PR only touches core's com_content cache-key whitelist, so it can't fix a third-party extension's own caching logic, but any extension that reuses com_content's category view (rather than rolling its own controller) would pick up the same fix for free once this lands.
My comment was more to @joomdonation as there are extensions that add filtering etc
I have tested this item 🔴 unsuccessfully on 3cc89fc
Tested with JBT
- Using
scripts/memcached 54 onand installed Blog sample data - Created two Blog category articles, one with Millions (2) tag and one with Love/Joomla (5) tag
- Before PR seen
index.php/blog?filter_tag=2andindex.php/blog?filter_tag=5get the same result,
depending on first call and until cache is cleared - Applied PR with Patch Tester
- ✅ All tagged articles are shown with
filter_tagparameter w/o the need to clean cache - ✅
filter_tag=42shows correct 'There are no articles in this category. ...' - ❌
index.php/blogw/ofilter_tagstill depends on cache,
iffilter_tag=2was used first the article tagged Millions is used and
iffilter_tag=5was used first the article tagged with Love/Joomla is used w/ofilter_tagparameter
(this is the same behaviour as before PR)
- ✅ All tagged articles are shown with
- With 'OFF - Caching disabled' and w/ or w/o PR
⚠️ index.php/blogdepends on previous usedfilter_tagparameter, even w/ full page reload⚠️ index.php/blognever shows me all Category Blog articles
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48459.
I have tested this item 🔴 unsuccessfully on 3cc89fc
Tested with JBT
- Using
scripts/memcached 54 onand installed Blog sample data - Created two Blog category articles, one with Millions (2) tag and one with Love/Joomla (5) tag
- Before PR seen
index.php/blog?filter_tag=2andindex.php/blog?filter_tag=5get the same result,
depending on first call and until cache is cleared - Applied PR with Patch Tester
- ✅ All tagged articles are shown with
filter_tagparameter w/o the need to clean cache - ✅
filter_tag=42shows correct 'There are no articles in this category. ...' - ❌
index.php/blogw/ofilter_tagstill depends on cache,
iffilter_tag=2was used first the article tagged Millions is used and
iffilter_tag=5was used first the article tagged with Love/Joomla is used w/ofilter_tagparameter
(this is the same behaviour as before PR)
- ✅ All tagged articles are shown with
- With 'OFF - Caching disabled' and w/ or w/o PR
⚠️ index.php/blogdepends on previous usedfilter_tagparameter, even w/ full page reload⚠️ index.php/blognever shows me all Category Blog articles
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48459.
This pull request has been automatically rebased to 6.2-dev. Joomla! 5.4 is now in security only mode.
| Title |
|
||||||
Users should test it by doing something on the page (for example, select a tag), not by change variable directly on URL as you describe.
From what I see, the filter_tag input is only used on Category List menu item type when Filter Field parameter in the menu item set to Tags. And for that operation, we do not allow caching view output, see the code https://github.com/joomla/joomla-cms/blob/5.4-dev/components/com_content/src/Controller/DisplayController.php#L81-L87 , so the change you made here is useless.