as I understand it, the generated images are stored in an optional folder. Is it possible to automatically sort them into subfolders so that there are not tens of thousands of files in this folder over time?
That is something I had initially considered myself when I started with this plugin.
There was a (at that time) valid reason why not to do that, it had something to do with a specific use case for a customer. Not sure any more what the reason was.
I need to think this through again
There is no downside to one directory with a lot of images for performance reasons (the amount of images stay the same and the server OS is equiped to do just that: serve files). I am following also best practise as it is implemented by e.g. Joomla caching here. i have a customer with 80K articles, these are 80k cache files in one directory.
For maintenance it could be easier when you want to clear out specific cache files (because the original cached images are not used anymore: change in image filename). For changing images that changed but kept the same filename you can use the force cache advanced setting: that will then recreated the cache files for the new images > overwriting the cached files)
My experience in running multiple blog sites, is that images are mainly static and the cache files created are set and forget.
The 'overhead' of cache files that are never used (because image filename changed) is neglectable, and you can always remove all the cached files and all the new cached files will be created automatically
But then again: maybe I am missing something as my use cases are possibly limited to how you are going to use it.
So can you tell me what, other then structure and organization, are advantages to have this with subdirectories?
it was meant in case I wanted to work with files manually for some reason - individual deletion, backup, synchronization, etc.
I have experienced that some programs are significantly slower when they have to load and list folders with a really large number of files, even though the file system supports it. For example, loading via the webftp interface. Subjectively, it also seems clearer to me.
If the organization option was (optional) eg "/cache/yyyy/mm/dd/", depending on the date the images were created, it would be easy to delete a specific year or month manually without having to list all the files.
But maybe I approach it wrong and it's just a bad habit from historical restrictions
In any case, I'm very happy to have found your extension. So far I have used XT Adaptive Images, but thanks to Joomla 4 I was forced to try something else. And so I have a new favorite
it has to do with the way the cached images are linked to the images in the content.
this is done on the full name of the image (so with path). that name is converted to a hash. the hash is used as the name of the cached image.
This guarantees that when you use an image e.g. 10 times in different locations on your site, there will only be one set of cached images for that image.
Making data like date or article id or category etc. part of the cached image location will break in multiple ways:
1. not all views have this information and ochResponsiveImages works regardless of component / view / id / category / menu item / etc.)
2. when you use an image on multiple pages, multiple sets are created
the directory structure should add value, so imo it should be meaningful. reading the image modify / create date and use that as a directory structure would not add value (for me) because when you want to pinpoint that image, you first need to lookup the create / modify date for that image your self before you can find the image.
And then there is also the possibility for supporting remote images to be cached: as these images are not saved on your local disk but reside remote (on another webserver) , there is no date / information available. Also every page view needs to read the date information from the images before being able to locate the cached versions. This is putting additional load on your server which will result in slower pages.
How I do it now is just render the page, take the filename of the image from the page source and search for that image in the directory. I can then locate that image based on the filename.
As said, images are mainly static so there is almost never a change. When developing a site (so when the images might change more frequently), I always force cache (re)creation and when going live I remove all images. The new cached images are then created automatically.
thanks for the explanation, now i understand why this is so. It's a simple and elegant solution and makes sense Most of the time, you probably won't need frequent manual manipulations. So I note that this is better