That will mess things up unfortunately. I’ll have to force the cache tester to use a http:// link.
Donncha,
Thanks for your reply. My main concern, though, is the cache building process itself. If the tester alone is going to work over https, no biggie.
However, my concern is that if the actual cache is building over https and http (and I think it is because you can see a different cache by requesting the frontend over https), it’s working way harder than I want it to.
I think this is also the reason why visitors on the insecure host are getting way outdated files when newer ones are available: because the newer files will only display to https requests.
Am I correct here?
Unfortunately supercache files don’t differentiate between ssl and non ssl urls. The protocol isn’t saved so the files are shown to every user.
If your site is available in both ssl and non ssl modes you should probably use the plugin in half-on PHP mode. You won’t be able to preload then however.
Sorry, I should have mentioned it is in half-on mode. I suffered from 500 errors in full on mode.
Unfortunately supercache files don’t differentiate between ssl and non ssl urls. The protocol isn’t saved so the files are shown to every user.
Well, actually… that’s good isn’t it? I was trying to figure out if SSL was the reason why users would be fed an outdated cache file when a newer one was available.
I’ve just looked through the code and it searches either for the post_id of the post changed, or of files without a post_id so when you change a post it should delete all those files, regardless of ssl or not.
You might have to debug the wp_cache_post_change() function to figure out why it’s not working on your server.
Donncha,
Thanks very much for your replies. I have just a few simple questions that I want to wrap up right here so I can stop bugging you. I’m a self-service sort of guy, but I haven’t been able to find the answers out there.
- Does WPSC go through my site procedurally when creating cache files, starting with the “first” blog and going through to the last one, every [expiry time] seconds?
- Does the number of requests for a particular page affect how frequently it’s cached?
- Is there any other sort of prioritizing of some types of content (like home pages) over others?
I’m still confused as to why a request for the same content over https pulls a different cached file than when it’s viewed over http, but my main goal is just to be able to tell my users: “hey, stop refreshing the page! These are the factors the cache considers, and your updates will appear no later than X (hours? minutes? days?) depending on X.”
Some have reported content more than 24 hours out of date, and I just want to understand a little better what could be at play there.
Again, thank you.
