Is this a crazy idea? I thought of it when I had to delete the cached files for one album but these were in the same folder with theme.txt and all other cached files. I could have selected individual files but if all cached files pertaining to one album (subalbum) had their own folder (subfolder), then cache clearing would be much easier. This does not seem like a big problem until your cache folder has literally thousands of files.

Way ahead of ya ;-) 1.0.5 is already structured this way (have you upgraded?)

Actually, it's causing problems with those in php_safe_mode, which can't create script-writable directories. For that I might fall back on the one-directory strategy later, but everyone else will have /cache/album/subalbum/file.jpg structured cache.

If you have upgraded and are seeing jpg files in the root /cache directory, they're probably from a previous installation... you can (and should) delete them.

No, I haven't upgraded. Screwing up the courage still...but based on your excellent code in the past, I know I have nothing to fear.

Ok, have you implemented this one: When I load an album page for the first time the image compressor creates the cached thumbnails but only when an individual image is viewed for the first time, is its resized image file generated for display. Now, for personal albums this is no problem but the delay is large enough for public galleries that I actually browse through my gallery before e-mailing the link to others. That way they do not have to wait.

So what I am asking is this:

Trigger the compressor to generate ALL cache files (thumbnails and image files) for an album once it (the album page) is loaded.

Well, what you want is for them to be preloaded... how about a pre-load album link? It could display a status bar and everything...

One of the problems with that is the custom image sizes possible with each theme, so it'd have to take that into account, or produce some javascript which loads a preloader in the background.

The challenge is loading them in the background without making the user wait... I think that's possible.... we'd need a switch for i.php which returns nothing instead of an image, when asked to 'pre-load'. Should be possible.

Exactly, preloaded! Amazing how the right word can substitute for a paragraph. Going forward, if all themes were obliged to report certain parameters in set positions, even a separate standard 'parameters.txt' file, you could simply read those values.

There already is a theme.txt, but that shouldn't be required. Themes can have free reign with the image sizes they request, so I think the best way is to give them a preloader function and let them give it their parameters for what needs to be preloaded.

We need better documentation for theme creators... man I can't wait to get the Wiki back up...

Trisweb, a question or feature request: I am one of those "in php_safe_mode, which can't create script-writable directories". It's bad in that the default ZP installation doesn't expect safe_mode to be on and the whole cache business breaks down, resulting in no thumbs whatsoever.

I've therefore tried a small patch on the i.php, as follows, to detect safe_mode automatically and adapt cache generation accordingly. It just simply switches off subdir generation and changes the "/" separator of the cached file to "___" (a random choice). Maybe more could be done with safe_mode_gid detection, which I didn't have time to try.

Could this patch make it into the standard distro?

The link to the patch: http://premek.abilo.net/index.php?s=txp&t=zenphoto-in-safe_mode

Premek

PS: My first post here, so I'd also like to give due credits to all Zenphoto developers for this piece of work :-)

That is the general idea, thanks premek! I'll go a bit further and use the conditional to stop the creation of those directories, and test if safe_mode_gid works or not. Also I think the separator could be slightly more unique than three underscores; maybe I'll use some other character combination.

Thanks for the patch.

OK, thanks for positive response Maybe the separator could go to the config file, but that decision I'll leave to you since you have the overall picture.

Has anyone resolved this issue?

Currently the code in SVN has the safe_mode compatibility fix in it. It needs a bit more testing before a release as 1.0.8, as there are significant changes and bugfixes, but you're welcome to pull it from SVN to test.

@premek-b, btw, the separator does not matter I just realized, since the filename is being combined and saved, never separated out into parts, so there will never be a conflict. I've used two underscores for easy readability.

Just FYI, if you tested this before revision 352 it may not have worked. Latest SVN code should work fully with safe_mode on.