Great to have one cache folder finally.
But what happens on J! update with the /cache folder, will it stay but just won't be used?

We'll probably delete it. Nothing's been done with the install script for 3.x to 4.0 yet (so the filesystem updates/deletions), so nothing's included here or ultimately decided on it.

Actually removal of this folder shouldn't have negative effects as it the same situation using system > clear cache in admin panel.

Plus its contents are cleared on an update if using the file system cache and data placed there through Joomla's caching API.

The only possibility of breakage is extensions writing front end code expecting const JPATH_CACHE = JPATH_SITE . '/cache' will have to be aware that is no longer the case. Not to say they can't hardcode that path and keep using a cache directory there, but Joomla core and its caching API won't use or support it by default.

In one of my extensions I decided to use one cache folder for both front and back end to store response from 3p service. So I've decided to hardcode cachebase to JPATH_ADMINISTRATOR . '/cache'.

While this change won't affect this specific extension, some developers may have decided to use JPATH_SITE . '/cache' instead or expect /cache folder just to be there (like JoomlaWorks SIG extension that have been quite popular in the past).

I suggest that even that this is not a BC, it should be mentioned in J! update notes

By the way, what are the reasons for keeping Administrator cache and not Site cache folder?

I've prepared a plugin that is optimizing article images on the fly and I'd prefer having URIs to images as site.tld/cache/md5.jpg than site.tld/administrator/cache/md5.jpg.

One less "exposed" top level directory. Doesn't really matter either way if it's site or admin, I just threw it there.

So thinking about this a little bit, I think it's actually good to have JPATH_CACHE be in the administrator directory.

This cache path should relate directly to the system's caching API (operations completed through JCache), which generally should be protected/inaccessible files (with 3.7 exposing the cache path configuration, it should be encouraged to set this path outside your web space).

Knowing full well there are a lot of extensions creating cache resources (image galleries, media assets, etc.), they should be encouraged to continue using JPATH_ROOT . '/cache' to store those files without being aware of the cache filepath configuration or the JPATH_CACHE path constant.

So this is actually a good step forward. It creates separation of concern (splitting cacheable web assets and cached data storage that shouldn't be web accessible) and less potential for conflict in running operations on the two (i.e. clearing the cache right now I believe nukes all directories in your cache directory, regardless of whether they were created by JCache or another extension manually writing there).

Can you resolve the conflicts please so it can be tested - thanks

OK, rethinking this a little bit, I think we might need to revisit our organization of filesystem caching logic in general. For Joomla though, it starts with two high level definitions:

• (Semi-)Persistent Cache - this is the stuff that you'd cache through our caching API and is things like saved data queries, third party system lookups, etc. If you're familiar with Symfony this is what you'd use var/cache for, in our case this is what JPATH_CACHE should cover by default and this is the part that is fine to live in administrator/cache by default (this should be stuff that you aren't direct serving HTTP requests for and if you configure a custom cache path outside the web root shouldn't break anything).
• Media cache - for extensions which create images of different resolutions/formats, compress media, etc. This is really best served in media/cache IMO, but failing that, just the root cache directory is fine. Arguably, extensions doing this type of cache shouldn't be relying on the JCache API or the filesystem cache path configuration and this be the one convention that is globally hardcoded as `JPATH_SITE . '/cache'.

So I think we need to come up with the convention to use for 4.0 and nudge developers in that direction, and also break the convention that the two different cache purposes can be sanely served from one directory. Rebasing shouldn't be hard, but IMO there is a philosophical decision to make.

Would be a nice move to have media/cache as official cache folder for extensions to put their modified assets in.

Added the documentation required label. If you can add a /media/cache folder to the pr, then we are good to go here. The cache folders will then have the following purposes:

• /administrator/cache
  Is for cached stuff like queries, etc., created through the API.
• /cache
  Should not be used anymore, but we need to leave it for legacy.
• /media/cache
  For cached assets like thumbnail images.

If you can fix the conflicts, then I'm happy to merge.

OK, rebased to current, added media/cache directory, and a permissions check for it in com_admin.

I have tested this item ✅ successfully on 47f0a54

a little bit confused by (admin)

and by (site)

a little bit confused by (admin)

Confusion removed ?

nice now ?

I have tested this item ✅ successfully on 35ac5c6

I have tested this item ✅ successfully on 35ac5c6

RTC

RTC

Waiting for appveyor and then we get it in.

Thanks!