PO never purges automatically — WordPress plugin does not call the API

Benard David Corroy
(@malibard)

3 weeks ago
Hi,

Thanks for the reply. I can’t run that test any more: I have disabled APO on
the zone and removed the Cloudflare WordPress plugin. Here is everything I
measured while it was still in place, so you have the full picture.

TIMELINE — 8 September 2026, all times UTC, measured from an external client
12:09 APO enabled on buzzarena.com (zone 50be6de476b26998d44cc7ec18a24253).
Every page cached at this moment.
12:00, 12:05, 13:00, 14:06 Four articles published.
14:21 Every navigation page still serving the copy stored at activation:
```
     /                HIT  age 7555s  copy of 12:09  latest article: NO
     /geek            HIT  age 7384s  copy of 12:10  latest article: NO
     /bons-plans      HIT  age 7488s  copy of 12:10  latest article: NO
     /guides-dachat   HIT  age 6094s  copy of 12:10  latest article: NO
     /high-tech       HIT  age 7384s  copy of 12:10  latest article: NO

   All responses carried cf-apo-via: tcache.
```
14:47 After clicking Purge Cache inside WordPress, and with the plugin
reporting itself as connected and Automatic Cache Management ON, the
API token still showed “Last used: May 27, 2026” — unchanged through
all four publications of the day.

14:57 I called the purge endpoint by hand with the same credentials:
```
     POST /client/v4/zones/50be6de.../purge_cache
     {"files":["https://www.buzzarena.com/"]}
     -> {"success":true}

   The homepage updated within seconds (age 0, correct content).
```
15:25 APO disabled. Site back to cf-cache-status: DYNAMIC, TTFB 89-344 ms.
15:43 Cloudflare WordPress plugin removed.

So the token, its permissions and the zone were never the problem. Whatever the
plugin was doing during those two hours, it was not purging — and a front page
frozen on a two-hour-old copy is not viable for a site that publishes several
times a day.

A SECOND, SEPARATE ISSUE
Throughout, the plugin displayed “cf-edge-cache response header is missing!
Please clear any server cache used via other plugins.” Clearing every cache
layer did not change it. The header was in fact present on every response type
I could produce:

Cloudflare cache HIT cf-edge-cache: cache,platform=wordpress
PHP-generated (unknown query) cf-edge-cache: cache,platform=wordpress
HEAD request cf-edge-cache: cache,platform=wordpress

The plugin’s own verification was therefore wrong about my origin. Your
community forum and the WordPress.org support forum both have long-running
threads on this exact warning, several of them pointing at a conflict with
another page-cache plugin.

QUESTIONS
1. Is there a way to inspect the purge requests the plugin believes it is
  sending, so a user can tell “connected” from “actually calling the API”?
2. GitHub issues #404, #456 and #484 on cloudflare/Cloudflare-WordPress describe
  the same failure to purge across several plugin versions, and your community
  forum has threads titled “APO does not clear the homepage after publishing a
  post” going back to 2021. Is this the same defect, and is a fix planned?
3. If the plugin cannot be relied upon for invalidation, is calling the purge
  API directly from the site a supported way to run APO?
I am happy to re-enable APO on a staging basis if that would help you reproduce.

Best regards,
Bernard David Corroy — buzzarena.com
- This topic was modified 3 weeks ago by Benard David Corroy.
- This topic was modified 3 weeks ago by Benard David Corroy.

Viewing 7 replies - 1 through 7 (of 7 total)

Plugin Contributor Remkus de Vries
(@defries)

3 weeks ago

Hi @malibard,
To confirm, a separate Cloudflare connection in WP Rocket isn’t required.

Could you share your Cloudflare plugin and WP Rocket versions, and test “Purge Everything” from Settings → Cloudflare inside WordPress? Your dashboard/API tests confirm purging works, but this will help establish whether requests from the plugin itself succeed before we investigate the automatic triggers.

Thread Starter Benard David Corroy
(@malibard)

3 weeks ago

Hi Remkus,

Thanks. I can’t run that test any more: I disabled APO and removed the plugin
before your reply.

Versions at the time: Cloudflare plugin 4.14.4 (latest), WP Rocket and
WordPress both on their latest releases, PHP 8.x.

To answer the question behind the test: I did click Purge Cache inside
WordPress, at around 14:40 UTC. Fifteen minutes later, after four articles had
been published that day and with the plugin showing connected and Automatic
Cache Management ON, the API token still read “Last used: May 27, 2026”, and
every navigation page was still serving a copy frozen at 12:09. A manual call
to the purge endpoint with the same credentials returned {“success”:true} and
updated the homepage within seconds.

So requests from the dashboard and the API succeed; requests from the plugin
left no trace at all.

Happy to re-enable APO for a controlled test if that helps you reproduce.

Bernard

Plugin Contributor Remkus de Vries
(@defries)

3 weeks ago

I want to be sure it’s not due to something obvious, because out of the box, turning on APO in Cloudflare’s dashboard, activating the plugin and connecting it produces a very straightfoward result.

Before you do a controlled retest, could you reconnect the Cloudflare plugin using the exact same API token that worked in your direct API test, then try “Purge Everything” inside the plugin? And after that, use a different connection via the Global API Key, please.

This would help rule out an outdated or incorrectly saved credential. Please don’t share the token here 🙂

Thread Starter Benard David Corroy
(@malibard)

3 weeks ago

Hi Remkus,

Done. I reinstalled the plugin, connected it with the exact token that
succeeded in the direct API test, and clicked Purge Everything inside
WordPress. It works: five static assets that had been cached at the edge for
1,792 seconds all returned MISS with age 0 immediately afterwards, measured
from an external client. The token’s “Last used” date updated as well.

So the credential was never the issue, and the plugin is perfectly capable of
reaching your API when asked manually. That narrows this down to the automatic
triggers: during the two hours APO was on, four articles were published, the
plugin was connected with Automatic Cache Management ON, and not one of those
publications produced a purge — every navigation page stayed frozen on its
12:09 copy.

I didn’t need to test the Global API Key for this, since the scoped token
demonstrably works inside the plugin.

Happy to re-enable APO for a controlled test of the publish trigger if you want
to observe it live.

Plugin Contributor Remkus de Vries
(@defries)

3 weeks ago

Thanks, that confirms the plugin can now purge successfully. From your reply, I assume you haven’t yet re-enabled APO inside the plugin. Is that correct?

Please re-enable it and publish a test post with WP Rocket temporarily deactivated, then check whether the homepage updates. If it works, repeat with WP Rocket active. That will help isolate whether the failure involves the automatic publish trigger or the WP Rocket integration.

Thread Starter Benard David Corroy
(@malibard)

3 weeks ago

Hi Remkus,

Done, and the result is clear.

Setup: APO enabled, Cloudflare plugin connected, WP Rocket deactivated,
Cloudflare cache fully purged first so nothing predated the test.

At 10:12:27 UTC I updated a published post. Measured 48 seconds later from an
external client:

/ HIT age 125s (copy from 10:11:07, before the update)
/geek HIT age 89s
/guides-dachat HIT age 88s
/bons-plans HIT age 88s

No page was purged. Every age kept climbing from copies created before the
update, and the edge kept serving the pre-update homepage.

So the failure occurs with WP Rocket deactivated. The WP Rocket integration is
not involved — the automatic publish trigger itself does not fire a purge.

I’ve reactivated WP Rocket since the site was serving uncached renders at
~500 ms instead of ~100 ms. I didn’t run the second half of the test, as the
failure is already reproduced in the more favourable configuration.

Bernard

Thread Starter Benard David Corroy
(@malibard)

3 weeks ago

I’ve since disabled APO again. With it off, publishing updates the site
immediately, as expected.

Viewing 7 replies - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.