User tests: Successful: Unsuccessful:
Pull Request for Issue #45403.
Cache Control: allow caching for Content views: articles, categories etc
Check browser dev. console network tab for the response for the page HTML of any article.
Also check that Content views works as before.
There is cache-control with no-store, no-cache ...
There is no cache-control
Please select:
| Status | New | ⇒ | Pending |
| Category | ⇒ | Front End com_content |
| Labels |
Added:
Feature
PR-6.1-dev
|
||
I have tested this item ✅ successfully on 071936c
looks like the wrong approach for the linked issue. Also could lead to unexpected caching on frontend proxies for random content for example in random image module.
my suggestion would be to remove the no-store from the default caching policy and only add it if the user is logged in.
+1 about what @HLeithner said.
@alikon I am not saying that Caching article would be a bad thing, but in order to make Joomla pages BFCache elgible it would be sufficient to remove only no-store, leaving the rest unchanged as default.
Currently we have only On/Off option for caching and nothing in between.
When we remove no-store we will lose possibility to really prevent the caching. This is not an option without bigger changes in Application class.
What I suggest is to allow the cache for all "static views" (article listing, categories etc).
When any extension want to prevent it then they always can switch it Off with $app->allowCache(false).
Currently we have only On/Off option for caching and nothing in between.
When we remove
no-storewe will lose possibility to really prevent the caching. This is not an option without bigger changes in Application class.What I suggest is to allow the cache for all "static views" (article listing, categories etc). When any extension want to prevent it then they always can switch it Off with
$app->allowCache(false).
no-store is not needed for normal no-cache, no-store means 2 things (afaik). It doesn't allow to to store the content on disk, which actually means you need also no-cache in the cache-control header. We would not remove the no-cache part.
We remove the no-store directive if the logged in user is guest / not logged in. This means you need to revalidate but the backward / forward history cache could load the page from the internal cache.
Technically I should/could add a $app->cacheAllowStore(); and $app->cacheNoStore() method or similar... but would do this in the document and not in the application tbh.
before pr
with pr no cache-control
with firefox 145.0.1