p15h

That helps! After spending more time with the log, I’ve tracked down the root cause: auto purge relies on wp cron, whilst manual purge executes immediately. The result is the OPcache/object cache entries show up at once for the latter, but appear in the case of auto purge according to the cron cycle (5min in our case). Still, they get run eventually.

Thanks very much for getting me through this.

Yes, both are indeed enabled – which is why the third and fourth log lines were there when a manual purge was triggered.

It’s only the auto purge that doesn’t seem to be controlled by these settings.

Before you go MySQLi, it doesn’t hurt to check if you’re on a RHEL9-like system, and if so, refer to https://www.ads-software.com/support/topic/rules-not-updating-done-a-lot-to-fix-this-but-no-vail/#post-16875273, although that’s not the case for the OP.

Dear Peter

It’s good to know WF actually believed that Extended Protection would speed up a site, and that the slowdown a lot of users have experienced with EP is news to the WF team. I would like to keep this topic open to keep track of the discrepancy, and see if further empirical research by WF would result in a different recommendation regarding EP.

Dear Peter

The present topic isn’t related to the answer you provided in that topic. My link points to the following questions that that user asked there:

thanks for reply in detail. I have done some digging and found that the issue arises when we enable Extended Protection in wordfence. Can you please elaborate on this? Why extended protection may cause speed issues ?

I cited him simply to show that many people have experienced a performance hit when they turn on extended protection.

I was requesting that you document this performance trade-off on your website.

Thanks for fixing this so quickly @haseeb0001. And thanks to @lkraav for the input.

Dear Majumder

Many thanks for this!

I’m afraid I utterly failed to get my point across. Let me try again if you’ll bear with me:

The trouble with ‘?fbclid=‘ isn’t that it can’t bypass CF cache, it’s that it still bypasses CF cache even after Rule 4 gets implemented. That is, it always bypasses cache whatever we do in the CF zone dashboard.

The APO doc I linked to has this to say:

APO serves cached content as long as the query parameters in the URL are one of the following

This seems to indicate that their allowlist isn’t intended to let these query parameters (including fbclid) bypass CF cache. On the contrary, the allowlist stops them from bypassing cache precisely because Rule 4 alone is unable to achieve this.

This would explain why we repeatedly observed queries with parameters like ‘?fbclid=‘ in our access log even though we’d already implemented Rule 4. (FYI, we don’t have CF’s default plugin installed on our site.)

I hope I’ve made it a bit clearer?

Yes, I was alluding to this earlier recipe from you! But Facebook’s fbclid query string keeps bypassing the cache even after toggling on ‘Ignore query string’ both in that cache rule and under Caching —> Configuration panel.

I suppose that’s why APO has to maintain an allowlist (above) in order to serve cache for these strings, which bypass cache by default even when choosing ‘Ignore query string’.

We may have to do a bit of extra work to replicate the functionality of that allowlist?

Yes, I can confirm the sitemap is excluded from caching! Trying to think of other potential causes…

Hmm… Looks like it’s more endemic to our particular environment than I realised. And we’re on good old httpd.

The only thing I know at the moment is this routinely happens after a purge action. Let me take some time to think things through.

Thanks for confirming this, Peter. I suggest adjusting the wording next to the box to make it absolutely unambiguous!

I’m glad you pointed this out @isaumya. My guess is it has to do with the old problem with third-party page builders (Elementor in our own case) documented previously here and here.

So what happened is we took the HTML text from Elementor at one point to do some search-and-replace, and that HTML did come with a cache buster on the link to each image. We should have manually removed the cache busters before pasting the HTML back into Elementor. That’s because when we pasted in the links with cache busters appended, Elementor apparently thought the query string was part of the links and showed it on the webpage!

This is all a bit convoluted, but I hope I’ve managed to explain how the cache buster winded up on our static assets. So once some of the crawlers caught sight of these query strings, they started to send requests for assets with the cache buster appended – which naturally bypassed CF cache.

After redirecting legitimate traffic using the page rule for a while, we now simply block any further requests with the swcfpc query string appended.

Got it! So in this case it seems best to just ignore the php warnings.

Turns out this was caused by bots scanning the site by directly visiting our ip address, which would naturally circumvent CF’s hostname-based WAF. Such traffic can be blocked at server level like this:

SetEnvIfNoCase Host "^\d|^$" bot


# Controls who can get stuff from this server.

    	<RequireAll>
            Require all granted
            Require not env bot
    	</RequireAll>

Dear @isaumya

Many thanks for this. I can confirm both patches work as intended. I’m glad we’ve managed to get localised time at least into the log, while still preserving backward compatibility.