[6.1] Cache Control: allow caching for Content views

[Fedik]

Pull Request for Issue #45403.

Summary of Changes

Cache Control: allow caching for Content views: articles, categories etc

Testing Instructions

Check browser dev. console network tab for the response for the page HTML of any article.
Also check that Content views works as before.

Actual result BEFORE applying this Pull Request

There is cache-control with no-store, no-cache ...

Expected result AFTER applying this Pull Request

There is no cache-control

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: TBD
• No documentation changes for manual.joomla.org needed

[alikon]

before pr

with pr no cache-control

with firefox 145.0.1

[alikon]

I have tested this item ✅ successfully on 071936c

---

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

[HLeithner]

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.

[gilbertococchi]

+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.

[Fedik]

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).

[HLeithner]

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).

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.

[dgrammatiko]

@Fedik @HLeithner I don't think that this can be done anywhere else but the template. The reason: a page could have a component without a form but the footer, or any other template position, might have a contact us form or something similar. My point is that only after laying out the page a decision on the caching could be done safely

[HLeithner]

@Fedik @HLeithner I don't think that this can be done anywhere else but the template. The reason: a page could have a component without a form but the footer, or any other template position, might have a contact us form or something similar. My point is that only after laying out the page a decision on the caching could be done safely

Technically I would set the "no-store" to false and allow the view, or what ever doesn't want it disabled to set it, the cache control in the application is wrong anyway, it would be in the document that at least knows more about what happens to the output then the application.

[Fedik]

I do not agree.
The Document IS the template and it just a wrapper around the content. All it know is the format: html, json, xml etc.

To cache or not to cache is decisions for content providers. In our case it is a Component and then Modules.
It should stay on Application level.

[HLeithner]

then you need a way to tell the application layer from the view or model if caching and what kind of caching.
If that's not needed then in the M or C the controller is in charge and has application access so just do it there.