Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
Hello,
I did not understand the logic of the image cache.
In the case of a high-traffic gallery, the image cache is used once for storage space and, in addition, server load is produced.
If I understood correctly, the resize images and thumbnails are also generated by the server (if not present) when search robots make a web page request (or somebody). So, on average, all resize and thumbs are in cache anyway. Deleting them after a certain time only increases the server load.
Honestly. How often does a user change the size of resize images and thumbnails? With me: only once.
In my gallery the original images (in / albums) and the resize images are to be protected from hotlinking and these image files are not indexed by searchrobots (the text of the image pages already). But, it should allow the thumbnails of searchrobots to be indexed. (only thumbs: bing and google image search indexing allowed. All images: hotlinking disallow). In the logic with the image chache this becomes very difficult.
It would at least be an advantage if the resizes and thumbs were stored in different folders. Even better would be if they were stored in the same folder structure (not in the same folder) as the original image files. Example resize max-width / max-height 800 = parent folder "/800" or "/resize". Thumbs size 150 = parent folder "/150" or "/thumbs". Saving in the same folder structure also saves the renaming of file names, what makes it even better. All resize and thumbs together in a single folder is unwieldy.
I do not understand the benefit of image cache.
Comments
Generating image sizes causes server load which is why Zenphoto stores these generated images in the cache.
You need to understand that the default sizes you can change via options are just the default ones. Themes and plugins can choose to request any extra image sizes directly without the backend "knowing" directly of these.
The original images generally are not touched so any new size requested from them is directly possible. Also you can embed images into articles and pages which also can be any size not know before actually created.
This core functionality will certainly not be changed as this is how Zenphoto works. It is different to lots of other galleries but it allows you to directly upload via ftp.
If you want to protect hotlinking for certain image types you need to do that via htaccess or similar. Look at the cache file names. Thumbs for example should generally have a "thumb" within their name.
You can further protect the original images by moving the albums folder above the webroot (setting via the config file only).
Please review this article: http://www.zenphoto.org/news/caching/
Sorry, I can not follow the reasoning. It should be more economical? But it saves neither disk space nor server load if the cache is emptied regularly. OK, it's a funny idea. Or did I get it wrong and the cache is never emptied? Thus, the "on the fly" feature is also weird, and saving all resize and thumbs into a single folder as well. I do not really understand it. Why should the resize images and thumbs be deleted regularly? OK, too little space. But that is not up to date today, is it?
An important question is also whether search engines can really index images (I mean not image pages) that are not in the cache? For sure?
Apart from this. Is it possible to generate a standard version via plugin, in which the resize images and thumbnails are saved as usual in their own folder structure, without renaming? I need that.
(I have no desire to switch to a gallery that will soon be abandoned, like Gallery3.)
The cache is not emptied unless you do it manually. It is generally persistent.
The "on the fly" feature is not weird, it is a base feature. Zenphoto does not require any pregenerated images sizes. They are generated when requested. It is possible to pre-cache but normally it is not needed.
Differently to other systems Zenphoto does not create any sizes on upload. It is the themes and plugins that request their sizes as they need them. They can use the default image functions which get their sizes set on the backend but they don't. See our site for example, it does not use any default image sizes at all.
Within the cache folder the album structure is replicated, so no "single folder".
No sure what you are asking. If you link your original full images on your site and don't prohibit this via e.g. robots.txt (so the search engines follows this) or htaccess they are of course indexed.
It is really not necessary (besides that it would bypass core functionality and may cause isssues of all sorts). Sorry if it doesn't fit your way but you have to take this as it is.
A bit weird question, Zenphoto will not.
OK, "Single Folder" was not right. But if the folder structure is already respected, why not create extra folders for resize, thumbs and backend images? OK, that's not really important, because then all, including the cache images are moved when moving. Is that so?
Then I did not understand something with the cache. It is not a cache as it is not automatically deleted. You can delete it if you want. But why should you?
At the moment I regulate the hotlinking forbidden with the htaccess and the indexing release for search engines with robots.txt and symlink folders.
With Zenphoto this may not work with the symlink folders, as all resize images (resize and thumbs) are in one folder. But maybe it works. Let's see.
The cache image will be invalidated whenever the original image has changed. This is typical caching behavior--an item is captured when first referenced then that cache is used thereafter. Zenphoto does not limit the cache size, so there is no garbage collection process. If you believe your cache should be "garbage collected" you would have to do so manually (presumably via FTP.)
While it would certainly work to create separate sub-folders for thumbs vs other resized images it really makes almost no sense. After all, a thumb is simply a resized (and cropped) image used for a specific purpose. Not really all that different operationally from any other sized image.
Zenphoto works very well with symlinked folders so long as your server supports symlinking. In general zenphoto does not care if a folder is actual or a symlink. (Which is true of most applications!)
No, actually if you move an album the cache versions are not moved (just tried). But it does not matter for the album as Zenphoto will just generate the sizes again. Something we probably could put on the list indeed.
Because you may have used a different theme or tried some plugins that create sizes you don't need anymore. Since the backend generally might not know of these sizes there is no other way to get rid of these. Or you replaced an original image with an update. It would still use the old cached version.
That means the cache is a garbage dump? not cool.
I'm not happy that extra thumbs are created for the backend. Would not there be a CSS width / height of the existing thumbs? Oh, that does not work, because the "on the fly" ... There is the error!
"on the fly" is a gimmick for me, nothing more. Sorry, but not really useful.
Thanks for the infos.
You will hopefully agree that serving fake resized images is not really the best way either. So the sizes are created as needed.
Not really you can clear the cache and again Zenphoto will different to other systems just recreate everything that is missing. You can even use the cacheManager (so the plugins and/or theme used registers its sizes properly) to pre-cache all required size again (= not on the fly).
Sorry if you don't like this but that's how it is