I just saw that if a gallery is protected by a password, static HTML cache won't work.

Just a silly question : why is it like that ? Isn't possible to check if the user is identified before checking if there is a cached version of the page ?

For logged in users the cache is disabled by default as otherwise protected pages would be cached in their unprotected state. Also the cache otherwise needs to be cleared manually whenever a user changes something, otherwise he would not see his own changes.

Sounds like you should post a ticket about this. Then we take a look if that would make sense (technically).

Thanks for your quick reply.

Let me just make sure I get this right before posting a ticket. No need to post one if what I'm asking is stupid.

"protected pages would be cached in their unprotected state" :
but if the cache is used AFTER checking the rights, it should not be a problem, right ?

" Also the cache otherwise needs to be cleared manually whenever a user changes something, otherwise he would not see his own changes."

But this does not sound related to the fact that the image is password protected, am I right ?

Or maybe I don't have the right meaning for "protected" ?

My problem is the following : to make a password protected gallery fast. It's protected just with a password. So in my mind, it should be possible to make sure the cache is used ONLY after checking the access rights. I made a small change in the static cache PHP file to do that on my gallery, and it seems to work. I say "seems" because I'm only considering my own case (simple password protection) and it's surely more complicated (I think it's possible to have identified accounts accessing a gallery maybe). I can document myself a bit more and propose a modification of the cache library if you want. I'm not a top notch PHP developper, but if I can help, I will try.

Then about the problem with modification, usually I clear the cache when I modify something in a gallery. The best solution could be to automatically clear it after a modification is made (on a per photo basis ideally, or on the full sub gallery otherwise). But I think it's another topic not related to my current problem.

[i]but if the cache is used AFTER checking the rights, it should not be a problem, right ?[/i]
Probably, it is not built in I think, not sure why, but probably because 1. the plugin is older and from a time when the multiuser usage was not that refined. Also, most people seem to use the site with one single admin user so they never would need this.

[i]But this does not sound related to the fact that the image is password protected, am I right ?[/i]
Password protected items are also not cached for this reason. Problem in general is that if they are anyone knowing the Zenphoto structure (we are open sourec) would be able to access protected items by guessing the cache_html file name (unless you do some htaccess protection work).

[i] Then about the problem with modification, usually I clear the cache when I modify something in a gallery. The best solution could be to automatically clear it after a modification is made (on a per photo basis ideally, or on the full sub gallery otherwise). [/i]
Well, that is quite complicated because of inheritance and that an item might be used elsewhere. Only clearing the image/album/page/article html cached page will not be enough. The title of an item might be used in the navigation or an image within some latest images displays. Also archive counts may need to be update etc. Those all are reasons why the cache does not update automatically (it is time managed generally).

I would say open a ticket to the cache vs protection and we (my collegue will surely have to say somethign to that as well) discuss it further there.

Ok clear, I agree with everything you said. I will go for the ticket.

Of course the true issue is that the permutations of "protected cached pages" is not even knowable. There would need to be a cache for eache user or guest with a password. Right now we do not think that this is worth the effort. Unless you have a large number of users, there should not be so much overhead on your site from generating the pages.