w3tc outdated cache files not updated

Hello @rrivv

Thank you for reaching out and I am happy to assist you with this.
_old files are created when the cache is purged.
it’s fine to have _old files. If the page is marked as _old immediately after visiting the page, that means there’s probably a WordPress cron schedule invalidating the cache.
When a page is cached, the file is saved without _old. The _old is added when you update the page or click flush cache. This is actually done to prevent loading the cached page, and force updating the page cache. Garbage collection is used to remove all the _old files from the cache directory (wp_cron default is 3600s). If that doesn’t work, there’s some server restriction preventing the plugin from doing that, which is why it is better to use a memory-based cache method in that case.
When you say “Cache update interval: 900 seconds” can you please confirm that you are using Cache Preload?

Thanks!

Hi @marco

When you say “Cache update interval: 900 seconds” can you please confirm that you are using Cache Preload?
oops, cache preload not enabled on this site so please disregard this ??
***
Yup, I understand why xxx_old files created. And by a “w3_pgcache_cleanup” cron process, right?

But the problem is that on some sites at some time xxx_old versions stop creating, so usual files, like “_index_ssl.html” stay in cache folder forever – till I purge cache manually (and never renamed to xxx_old).

So I need a direction, where to dig, cron issues or something else?

Hello @rrivv

Thank you for the information.
The _old files are handled and deleted by the w3_pgcache_cleanup cron process, and the default is 3600s. If the _old file is not deleted after an hour, this means that wp_cron is not triggering w3_pgcache_cleanup for some reason.
Once the page is cached, the _index_ssl.html will stay in the cache folder until the entire page or that specific page is purged. When the Page cache is purged the _old file is created as mentioned before, and the page will only be cached again once visited.
I hope this helps!

Thanks!

Hello Marko

It seems I got it where the problem is.

When w3tc Page cache is enabled and nobody have been loged-in to the site for a while, cron is not working (no cron run by WP admin-ajax).
So, since cron is not working, cached pages not flushed/updated.
Since anonymous users “see” only cached versions of a page, wp-cron, based on anonymous users visits also not running.

So we just need create a dedicated cron call for every site…
Does it make sense? ??

thank you

Hello @rrivv

Thank you for your feedback.
You should make sure that the line define('DISABLE_WP_CRON', 'true'); is not added to wp-config.php
WP-Cron only runs on a schedule when some ‘thing’ visits your site, either to the front-end or the WordPress admin. I say some ‘thing’ because to WordPress, it doesn’t matter if it’s a user, a visitor, or a bot – it just has to visit your site in a way that will keep the WP-Cron running on time.

This is fine for high-traffic websites (in fact it can also be a problem) but for sites that don’t get visited that often, or sites that are behind a login or used on an internal network, it can mean that the WP-Cron doesn’t run correctly.

I hope this helps!

Thanks!