Preload files getting deleted

UPDATE:

We think the preloaded cached files were deleted at 00.00hrs last night.

This evening this has NOT happened so far ( 00.05hrs UTC )

The only thing we changed was “Refresh preloaded cache file every” from 30 mins to 480 mins.

Not sure if this expected behaviour on first install, we will monitor and report back

Thank you.

Ok files still not been deleted, so looks good after all.

We have noticed that the scheduled PRELOAD process did not run until we logged back into the sites today.

Am wondering if this is due to the sites being on development servers that are no accessible to the internet, so will not have had any page/post visits. So the scheduled preload process did not start until we visited the site(s) today, does that make sense ?

Otherwise, brilliant lightweight caching plugin, with CDN support and makes dramatic improvement to page load speed, thanks !

Hey there,

We have noticed that the scheduled PRELOAD process did not run until we logged back into the sites today.

Am wondering if this is due to the sites being on development servers that are no accessible to the internet, so will not have had any page/post visits. So the scheduled preload process did not start until we visited the site(s) today, does that make sense ?

WP Super Cache relies on WP-Cron that works by checking, on every page load, a list of scheduled tasks to see what needs to be run. Any tasks due to run will be called during that page load. In other words, WP-Cron does not run continuously, which can be an issue if there are critical tasks that must run on time and no trigger from traffic.?You can address this by setting:

define( 'DISABLE_WP_CRON', true );

and relying on your server’s system cron (you may want to check with your host if system cron is enabled).

Otherwise, brilliant lightweight caching plugin, with CDN support and makes dramatic improvement to page load speed, thanks !

Thank you for your feedback! It means a lot to us!

Hello

Thank you for your kind reply.

Following extensive testing, we can confirm that the cache is DELETED , and not refreshed.

This is undesirable and at odds with the stated / expected behaviour of the plugin.

It may be related to a bug with this setting on the PRELOAD page.

Refresh preloaded cache files every??XXX minutes. (0 to disable, minimum 30 minutes.)

No matter what setting is entered for ( minutes ) it will default back to 720. We could not locate ‘720’ anywhere in the SQL database. In pour case we needed a setting of 1440 which seems not possible.

In summary , the plugin DELETES the preloaded cached files, and does not preload/refresh them.

Unfortunately for us that renders the plugin useless, which is a great shame as we really wanted to use it.

@treecutter There is a check in the code that sets the limit if you have many posts on your site, but if you set it higher, it should let you without complaining. Do you have more than 1000 posts on your site?

Have you tried using the Cache tester on the Easy settings page? If it doesn’t work, it might be related to this, and that might mean your server can’t make requests to itself.

If preload doesn’t work at all, then you can ignore it. Disable garbage collection (advanced settings page) and your cache will be filled by visitors, both human and bots, hitting the site. If you ever edit a page, the cache for that page and related archives will be cleared but will be populated in time again.

Hello

There is only a very small number of posts, not more than 200.

The two main issues are the preload cache setting seems to be limited to 720. But no matter what figure is entered and saved, it reverts to 720. That really should be fixed.

The preload sets the cron job X minutes after the preload interval is set. At the designated time the cache is emptied, but then not re-populated.

We can see a lot of work has gone into building this plugin, and the performance is excellent. It would be an even better plugin if these inconsistencies could be addressed.

We will try your suggestions

Thank you again for the kind help and support.

• This reply was modified 6 months ago by treecutter.
• This reply was modified 6 months ago by treecutter.

Can you toggle the checkboxes on the preload settings page, and do they save?

I’m going to remove the code that forces a minimum of 720 minutes between preloads. I’m not sure how the plugin thinks your site has more than 1000 posts. The minimum interval will now be set to 10 minutes if this patch goes in.

The next preload is scheduled by the previous preload, so there’s no chance that multiple preloads can happen in parallel.

No the setting are not sticky.

Thanks for the update, we will await the PR release and test accordingly.

Appreciate the awesome support !

OK, if the settings don’t save, there’s a more fundamental problem.

If you enable preload mode, can you download your wp-content/wp-cache-config.php and look for the string “wp_cache_preload_on”. If preload mode is enabled then it will look like this:

$wp_cache_preload_on = 1;

If it’s set to 0 instead, it failed to save.

Next, please enable debugging in the plugin and load the debug log. You might need to limit it to your own IP if your site is busy. If the setting was updated you should see:

wp_cache_replace_line: changing line $wp_super_cache_debug = 0; to *$wp_super_cache_debug = 1;*
writing to ABSPATH/wp-content/cache/.....

If that appears normal, check your PHP error log. If it failed to write to the config file, there should be a warning there. May be “wp_cache_replace_line: Error – could not write to <filename>”, or may be a PHP warning related to a cache file.

The plugin does extensive checks on the permissions of wp-content and wp-cache-config.php but maybe your server is set up in a different way. However, if you were able to enable caching in the first place, then the config file must be writable. I’m not sure what else to suggest except to contact your host support and ask if wp-content/wp-cache-config.php can be updated by the web server.

Hello @treecutter,

Do you have updates about that? We usually close inactive threads after one week of no activity, but we want to make sure we’re all set before marking it as solved. Thanks!