menken

It was set to clear post, page, categories — not the whole cache. But now it’s set to not clear at all, “Clear cache files when a post or page” is not checked, not for new and not for update…

And… it still happened. I activated the “Sassy Social Share” plugin, and it immediately moved cache/all to tmpWpfc and started over. Even activating or deactivating the “Mammoth docx converter,” which doesn’t impact the front end, it just converts docx files to HTML in the wp-admin section, caused the whole cache to clear.

I also noticed that it wasn’t updating even though “Restart after Completed” was checked, so something seems funny here.

• This reply was modified 3 years, 9 months ago by menken.

I think we have to try update post — because maybe it thinks the post is updated.

We have changed Divi theme parameters, removed a social media plugin, and other things — and in all cases the full cache has been purged. The sassy-social-share plugin makes no mention of wpfc (nor does any of the themes in our themes directory), but when it was deactivated, the entire site cache was cleared.

Is there any other process that might cause the wpfc cache to be purged, besides your delete feature?

• This reply was modified 3 years, 9 months ago by menken.

Yes, I agree – I’m saying if we disable wp-cron and only run it hourly, we have to run your cronjob in the tutorial, or it will only run hourly.

Feature request: Could you add an option to not purge cache when there is a design change? Every time we activate or deactivate a plugin, change the CSS of all pages, or similar changes, it purges the cache. Sometimes we are happy to show the cached version until the next reload, or purge manually.

You could create an option, checked by default

Purge on Change [X] Purge all cache when site design changes

We’d love that option.

OK. I have put a wrapper around your preload call to only run if the load average is low.

I also realized — we don’t use wp-cron. we have set define(‘DISABLE_WP_CRON’, ‘true’);

That means preload would only run as often as we execute wp-cron (hourly) — without your preload cron: https://www.wpfastestcache.com/features/manually-preload-with-cron-jobs/

Thanks!

• This reply was modified 3 years, 9 months ago by menken.

Does the ‘preload’ monitor how many pages have been loaded by visitors? I would like to keep preload on all the time, but I’m worried it will overload if everyone is hitting the site after clearing the cache.

It would be best if every visitor caching a page counts against the “pages per minute.”

/feed/ of particular parts of the site. I think that’s sitemap, but now we made a change that cleared the cache, something else I am learning!

Thank you! Preload also seems to be skipping xml files — everything has been revised, but some of the XML files are untouched since Jan 21. Does that make sense?

Thank you that is very helpful. I am monitoring, and in any case it is moving more quickly than I thought originally.

A few of our URLs have commas in them, and those don’t seem to get preloaded. I know it’s not great to have commas in the URL but I didn’t create them, I’m just working on the cache. ??

How does “Restart after Completed?” decide which pages to reload, in what order? Does it skip pages where the main content is the same, even if the sidebar changes, or does it force a reload in any case?

I am getting the same error with cURL and the preload, meaning if I load https://[SITE]/?action=wpfastestcache&type=preload in a web browser, more than half the results come back with a green OK, but 40% or so return a red ERROR.

It doesn’t really take 10 seconds to load uncached pages. Is it preloading these sequentially rather than hitting the server with all the requests at once?

I did reduce preload to 2 and still have the problem.

Thanks!

It’s a problem with a particular plugin, which we have deactivated and will replace.

Would anyone be able to suggest the “simple change” that @pronl mentioned? It’s certainly a lot simpler if you know which line number to look for and what to change.

@pronl, could you please specify the simple change required?

Note, of course, that we’re running Apache rather than nginx, but both running php5-fpm / fastcgi.