Darrel2013

Seems like the custom post thing was a red herring.

I couldnt see anything obvious in the debug logs so I tried setting the cache timeout to zero and the scheduler to various very long times. I found that no matter what settings I chose for these, the cache-related cron job “watcher” and the wp_cache_gc job were still being created for much shorter periods than I had selected, and this seemed to correspond with my cache being emptied.

So I deleted the watcher cron job altogether (what does it do anyway?) and manually altered the cache_gc job to 3 years. So far my cache has stayed full and it is being rebuilt according to the preload setting (24 hours) that I selected. Fingers crossed.

One other thing I dont understand: why do I need legacy caching and these checks for emptying it? Cant it just be completely turned off if I’m using Supercache?
It seems to me that a couple of tick-boxes in the advanced settings page to deactivate both unwanted services would be easier to understand than the “cache timeout set to zero”, and the timer and schedule boxes that currently cant be turned off.

I think my problem has something to do with custom post types as these seem to be the only ones that arent working properly. This site is almost entirely made up of these custom types, with just a few regular pages.

Thanks for the response. No, I havent tried that but I will now. Will report back.

Cached emptied itself for no obvious reason shortly after the most recent preload. I’d love to work out what’s going on here.

One day on with the changes I mentioned above and my cache is still full. It has regenerated 3 times, and nearly all the folders and files in the cache directory have date stamps within an hour of each other. Just a few files and folders had an earlier date stamp when I checked just now. I have deleted these folders manually, to see what happens.

I suspect you are correct about most people not noticing if the preload doesnt work.

As far as I know the preload is just an automated procedure for visiting each page and thus filling the cache, instead of just waiting for a real visitor to visit the page and fill it.

Looking at the cache folder via FTP I can see that the “delete cache” button does indeed delete all the cache files and folders and then once “preload now” is clicked the folders rebuild themselves, at a rate of about 1 page every few seconds.

Presumably if it was just timing out then there would be no difference between a manual preload and an automatic one.

Our site is just on a run-of-the-mill shared host but it works fine and for the limited number of pages (600) and hits (under 1000/day) we have I see no reason to change anything. All I’m interested in is that these static pages get delivered as fast as possible, and that the cache gets rebuilt or verified once every 24 hours. I’ve spent quite a lot of time optimising the scripts and css, optimising the images etc, and generally minimising everything as much as possible. All it needs now is for the cache to be full all the time.

I’m having a very similar problem.

My cache was set to preload all pages once per day (static real estate site with about 600 pages), with garbage collection off, but on occasions the cache would just be empty for no obvious reason, or would just have a few very old cached files in it.

Manual preload always works fine and I cant see anything wrong with the cron tasks. It’s just the automatic preload that sometimes fails, or maybe it succeeds and then gets deleted.

I have now set it to preload every 6 hours and have turned garbage collection on, set to once per day. We’ll see what difference that makes, if any.

If it came to the worst I could just turn off the automatic preload and run it manually once a day, but it should work on its own.

Apart from that this plugin seems to be excellent. I tried W3TotalCache but that was an endless source of problems and errors.