Andrei Baicus

Hey @bobsled,

Thank you for the kind words!

When I check a page with Dev Tools it shows cf-cache-status HIT and x-wp-spc-disk-cache HIT. So both the Cloudflare cache and the disk cache are working just fine.

The x-wp-spc-disk-cache header was probably cached on the first HIT from Cloudflare. We also don’t record each hit (the default sampling rate is 10% of all the requests), so that is why you might have a 0% hit rate – the miss was recorded, but no hits after that.

But showing a zero hit rate is misleading. As you said, it should be for the disk cache, but this gets overridden if using the Cloudflare cache. Surely it should show one or the other?

I agree, and we just released an update that should handle this more gracefully. Instead of showing the disk cache hit rate in the metric box, if you have Cloudflare connected, and the token has Analytics read permissions, the box will now show the Cloudflare Percent Cached, which is the same metric shown in the Cloudflare dashboard.

I hope this makes things less frustrating!

Have a great day!

@well666 Thank you for letting us know and sorry for the inconvenience.

We’re looking into it and will release a fix soon.

No worries! I’m sorry if this was confusing.

The cache hit rate represents the disk cache hit rate, which is internal to the plugin representing the HTML statically cached on the server itself, not correspondent to the Cloudflare hit rate.

If the pages were already cached by Cloudflare, or only the initial request was recorded for the metrics (which was then cached by Cloudflare), it would show a 0% / n/a hit rate.

So things are probably working just fine.

Let me know if there’s anything else I can help with!

Those are all great points. Thank you for letting me know. We will update the readme in the next few days.

On the “Cloudflare” plugin section, the “Cloudflare Setup Guide” is a dead link.

The documentation link should work fine now.

We will have the other suggestions in mind for the next release.

Have a great day!

Hello @masvil,

Thank you for reaching out and sorry for the confusion.

If you are coming from an older version of the plugin, a few versions ago (v4.7.11 – released in July 2024) we moved away from the old caching mechanism which was using Page Rules. In the previous versions we accounted for the old rule when rendering the switch, so it was showing as enabled. We also deprecated the Cloudflare Workers integration the plugin previously supported.

The setup you had should still work fine in both cases, but we removed both functionalities in favor of Cache Rules which are more robust and give better control overall. We also don’t account for them in the UI anymore.

If you are not sure which one you were previously using, you can check on the Cloudflare Dashboard, under Rules > Page Rules or Worker Routes.

That being said, if you were previously using a Page Rules, when you enable the toggle and update the settings, the site should migrate to the Cache Rules automatically. If you were previously using Cloudflare Workers, things will continue working fine, but we don’t migrate that setup.

I hope this helps!

Hello @dccorp,

I’m sorry you’re experiencing issues with the new version. To help troubleshoot this cache clearing error, could you please provide a few more details:

Does this error show up on the frontend, the dashboard, or both? Could you share which script throws this error?

If this is coming from backend.min.js from Super Page Cache when logged in and purging cache from the admin toolbar, it might be because a cached version of the script might be loaded when logged in.

If you have multiple caching plugins, can you please make sure that you purge the cache for all of them, and also ensure that you clear the browser cache (or try purging cache in an incognito window)? This should help determine if it’s a cache conflict issue.

Let me know if any of the above helps. Thank you!

Hello @ezral54,

I’m sorry you have experienced issues with the latest version. Would you be so kind to share more details about the error? If you’re using the Pro version, you can contact us directly.

I’ll need some additional technical details about the error you’re experiencing. Could you please follow these steps to gather more information:

• Enable WordPress Debug Mode Add these lines to your wp-config.php file (before the “That’s all, stop editing!” comment):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

• Go to your WordPress admin area & click on Super Page Cache in the menu to trigger the error again.
• The complete error message and call stack from /wp-content/debug.log. If no debug.log file exists, check your hosting provider’s error logs. You can also share with us a screenshot of any error message shown on screen if any.

The most important part is the complete error trace showing file paths and line numbers – this will help me pinpoint exactly what’s causing the issue.

Once we have these details, we can quickly identify the issue and provide a proper fix.

Thanks for your patience, and sorry again for the issue!

• This reply was modified 10 months, 1 week ago by Andrei Baicus.