You need to be very careful with this. If logged in users are sharing the same cache, then it is possible that the cache be generated with data a non-logged in user sees and this creates a minor security issue (information leak).

In general I think there’s a reason Joomla arbitrarily doesn’t cache for authenticated users and that it’s probably a good idea to not try to monkey patch partial cache support into the system. Instead, it would honestly be better if modules were migrated to a OOP code structure and caching decisions could be made inside the module itself instead of a generalized decision forced by the helper class in front of them (as then the module would be able to decide if cache can be shared between authenticated and not authenticated, or if different caches need to be made for different groups, or if the module just should not be cached at all (here’s looking at you, mod_breadcrumbs)).

@mbabker thanks for thinking along (appriciate it as always :)), agree that this introduces a risk of 'information leak', so care should be taken (as with all cache settings), it is an advanced setting that defaults to off: because of b/c but also because of 'caution' so the user makes an informed decision. Maybe the language desc should include more info?

With the availability of this setting it is the module itself that can decide if cache should be created and served for logged in uses as well, via the cache_loggedin parameter. same mechanism as use global or not and cache lifetime can be set per module.

I have changed the mod_articles to hold the setting because i find myself redoing (and maintaining) these modules (and custom ModuleHelper) on large content sites where once people start to log in the load 'criples' the experience (multiple mod-article modules on a page with 80K+ articles to sift though).

Beside the above, new features have to go into Joomla 4, as far as I know. So this PR against the staging branch is definitely not the right thing if I'm right with this. But may the release lead decide ... ping @HLeithner .

@richard67 thanks, not keeping up with all this :) lets see what 'happens'
been using this PR for some time no on my own and customer sites and thought it was time to also let others benefit :)

richard is right this have to be done for j4. The other thing is that as michael already said caching could be problematic. A better (but maybe less useful approach) is to cache per user.

@HLeithner just out of curiosity: what makes it for J4: the mod_articles xml changes or the ModuleHelper change (or both). It would already help a lot when the ModuleHelper has the option so that there is no need for 'cloning' and maintaining that customized helper file.
When your site grows (far beyond the static brochure site), these are the 'issues' you run into, throwing money at the hardware can be simply avoided with these kind of 'tweaks': a + for Joomla! :)

Not sure if caching per user is going to solve it, as that can lead to thousands of cache files (with all the same content) that still need to be created. Advantage is that you avoid the potential 'information leak' and improve performance for subsequent page visits.

With the availability of this setting it is the module itself that can decide if cache should be created and served for logged in uses as well, via the cache_loggedin parameter. same mechanism as use global or not and cache lifetime can be set per module.

Modules can't make any kind of advanced cache decisions. It's all reliant on a combination of these parameters. That's a huge problem.

I do a lot of caching in some of the applications I work on, some of those cached datasets include data that is only exposed when you have the right ACL privileges. So having this level of granular control is a real life requirement. The current Joomla architecture does not expose a mechanism to provide developers this level of granular control, and because of that it is too high risk to accept this feature proposal. If the Joomla architecture is fixed to provide more granular control over caching, then this parameter is completely unnecessary as the newly created architecture would let someone programmatically decide if cache can be shared 100% between guests and authenticated users or if there needs to be a separate cache for guests and different user groups (and there actually are some cache keys in Joomla that factor in the user's current groups, so this is not unprecedented).

Not sure if caching per user is going to solve it

It won't. You're better off disabling caching in full at that point, not because of the "thousands of files" problem (and no, it really isn't an issue if your cache store grows to be 1.5GB in size if you're handling cache logic appropriately); it's just unnecessary overhead in general.

"if" this was to be accepted surely it ould need to be applied to all modules not just a small arbitrary subset

Closing for stated reasons. Also no new features for J3.