Caching and page speedPro
Find a stale page in Super Page Cache or Cloudflare
Super Page Cache runs two caches: HTML files on disk and, optionally, Cloudflare's edge in front of them. GoBuildWP fires the plugin's own swcfpc_purge_cache hook, reads and writes its swcfpc_ rows, and measures the cf-cache-status header, which shows whether Cloudflare served the HTML from its edge. That narrows down where a stale copy might be; it does not prove on its own whether the disk copy is stale. Cloudflare-side configuration stays in the plugin's screen and in Cloudflare.
cloudflare_page_cache- Layer
- edge
- Declared purge scopes
all- Shared keys
- None
- Detected by
- plugin folder wp-cloudflare-page-cache
Installed class, method or listener checks and per-layer results determine whether a purge ran. Neither a declaration nor a returned ran flag proves public freshness.
- Edition
- Pro
- Abilities
- 16
- Requires
- WordPress 6.9+, PHP 8.0+
Before changing cache settings, inspect captured drivers and not_captured. After reverting, inspect restored, deleted, not_restored, verified and purged_layers. Use a separate cache-purge result when you need details for each layer. Storage verification checks captured values; it does not establish functional recovery or public freshness. Revert may overwrite later settings, and vendor configuration regeneration or a re-save can still be required.
Check each measurement run’s fetched_via before treating it as public-path evidence. cache-verify-in-browser supplies checks and does not operate a browser. Automatic purge coalesces targets within the request and runs on shutdown; it is not necessarily one immediate flush per call. Verify generated files, object/page/edge caches and actual visitor behavior separately.
Data model
A disk fallback, a Cloudflare edge and swcfpc_ rows
On disk, cached pages live under wp-content/wp-cloudflare-super-page-cache/<domain>/cached_html_pages/, which the plugin calls its Cloudflare fallback cache. At the edge it can use Cloudflare's cache even on the free plan, connected with an API key or token, and it adds .htaccess browser-caching rules. By default a cached page has no lifespan: it stays until purged.
Local settings sit in rows prefixed swcfpc_, which GoBuildWP reads with include_native and writes by name. Credentials and the zone can instead be supplied as SWCFPC_CF_API_TOKEN (or SWCFPC_CF_API_KEY with SWCFPC_CF_API_EMAIL) and SWCFPC_CF_API_ZONE_ID constants, which are PHP definitions rather than rows. Current source redacts recognized credential keys and reports redacted_keys; review remaining values and minimize transmission to the client/provider.
GoBuildWP classifies this layer as kind edge. Separately, check-setup lists Cloudflare under edge_layers when Cloudflare answered the site's own request, which is how an agent learns there is a second cache in front of the disk one.
Option name prefixes
swcfpc_
An edge-cache front end: the settings that matter are Cloudflare-side. Its local option rows are readable and writable by name, and purge is supported.
Worked example
Is it Cloudflare or the disk cache serving an old homepage?
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
Compare the returned delivery path, cache headers and expected banner text. A Cloudflare HIT carrying the old banner can come from an unpurged edge, stale origin output that refilled it, or a different cache key. Check the plugin's Cloudflare connection and both origin and edge responses before selecting another purge.
The declared companion purge can reach Autoptimize; detected Perfmatters is skipped. Verify the expected banner on an anonymous request and keep session, cart and checkout bypass routes separate. Review sensitive native options before requesting disclosure.
The homepage still shows last week's banner. Is Cloudflare serving an old copy?
wppilot/cache-check-setupReadReturns cloudflare_page_cache and, if Cloudflare answered, Cloudflare in edge_layers.
wppilot/cache-measure-pageReadcf-cache-status HIT with a large age says the edge is serving a stored copy; DYNAMIC says HTML is not cached at the edge at all.
wppilot/cache-purgeWriteFires swcfpc_purge_cache with the GoBuildWP reason and reports the layer as purged, or as failed with the error it threw.
wppilot/cache-warmWriteRequests the homepage and reports whether the response is a hit again.
A suggested sequence from the ability reference, not a recorded run.
Limits
Limits at the edge
- The edge is purged only if the plugin's own hook does it; cache-purge never talks to Cloudflare directly.
- The default lifespan of zero means pages stay cached until purged, so if purge-after-write is turned off with the wppilot_cache_auto_purge option, GoBuildWP's edits wait for a manual purge.
- Treat the swcfpc_ dump as sensitive if Cloudflare credentials are stored as options rather than constants.
- Row writes are undoable with rollback-change; Cloudflare-side state and purges are not.
Abilities
What each cache ability touches in Super Page Cache
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-purge | Fires do_action('swcfpc_purge_cache') with GoBuildWP passed as the reason, because the hook fatals without an argument; every scope widens to this full purge. A layer that throws is reported as failed while the other layers still purge. | What gets cleared is the plugin's decision. Its docs separate a normal purge (HTML) from Force purge (static files too), and GoBuildWP calls no Cloudflare API itself. |
cache-check-setup | Lists cloudflare_page_cache with kind edge, and Cloudflare in edge_layers when it answered. | Detection does not prove the plugin is connected to a Cloudflare zone. |
cache-measure-pagecache-warm | measure-page reports cf-cache-status verbatim, so HIT, MISS, DYNAMIC or BYPASS on the HTML is visible along with age; warm refills after a purge and says whether each response came back as a hit. | Timings are the server requesting itself, not a visitor's network path. |
cache-verify-in-browser | Lists an edge answering DYNAMIC for HTML under blocked_by_environment, with steps for whoever owns the Cloudflare account. | It proposes checks and steps; it changes nothing at Cloudflare. |
cache-get-settingscache-set-native | Read and write swcfpc_ rows by exact name, confirm=true every time. | Settings the plugin has pushed to Cloudflare through its API are not rows and cannot be edited here. |
cache-set-settingscache-apply-presetcache-list-presetscache-list-actionscache-run-action | Offer nothing: no canonical map, no preset keys and no declared action. The plugin's diagnostics are its WP-CLI commands, such as wp cfcache doctor. | Run those from a shell. |
cache-begin-experimentcache-revert-experimentrollback-change | Capture and restore the swcfpc_ rows and purge. | Anything configured on Cloudflare's side is outside the snapshot. |
Reference: /docs/reference/cache
Shared cache module; do not add this count across drivers. Edition and effect labels describe the source catalogue. The installed schema, dependency versions, licence, WordPress capability, safety profile and per-ability policy determine availability; labels alone do not prove confirmation or recovery.
Other plugins
Plugins Super Page Cache names
- Its WordPress.org page asks you to disable WP Rocket, LiteSpeed Cache and W3 Total Cache, and says LiteSpeed Cache works alongside it only with LiteSpeed's page cache off.
- It lists Optimole, Autoptimize, Perfmatters and ShortPixel as safe companions; Autoptimize can be purged in the same fan-out; Perfmatters is detected but skipped.
swcfpc_config edits, edge evidence and shop exclusions
Changing one value in swcfpc_config without losing the Cloudflare token
Super Page Cache keeps its settings store in the swcfpc_config row, and that row also holds the Cloudflare API key, token and account email. GoBuildWP reaches it through its generic storage driver, where a native key is a whole option row. A cache-set-native call on swcfpc_config therefore replaces the entire array: the agent has to send back the complete structure it read with only the intended value changed.
The credentials survive that round trip because of redaction. cf_email, cf_apikey, cf_apitoken and the preloader and purge URL secret keys are returned as [redacted], and a [redacted] value sent back keeps the secret already stored. What does not run is the plugin's own save routine. GoBuildWP's write is a plain update_option, the write_note says so, and GoBuildWP's source records that Super Page Cache encrypts its Cloudflare credentials and rewrites advanced-cache.php only when its settings screen is saved. After a native write that touches caching behaviour, save once in the plugin's screen.
Did the server's own request cross Cloudflare at all?
Super Page Cache for Cloudflare MCP checks lean on cf-cache-status, and that header exists only on responses that passed through Cloudflare. cache-measure-page fetches the page from the server itself; if the server cannot reach its own public URL, it retries on the local interface with the site's Host header and records that in runs[].fetched_via. A run fetched locally never touched the edge, so a missing cf-cache-status there proves nothing either way.
When the run did go out through Cloudflare, read the two caches separately. cf-cache-status describes the edge copy, while the plugin's disk fallback cache shows only in timing. cache-warm reports cache_hit per URL after a purge, which tells you whether the edge took the page back in.
Caching HTML at Cloudflare on a WooCommerce store
When cf-cache-status reads DYNAMIC, BYPASS or MISS for page HTML and Cloudflare is listed under edge layers, cache-verify-in-browser's edge_not_caching_html entry gives the dashboard steps. On a shop the step that matters most is the exclusion list it puts first: cart, checkout, my-account, wp-admin, wp-login.php and any REST route that varies per user must stay out of a shared HTML cache, or one customer's session can be served to another.
None of that is done by the agent. Cache rules live in Cloudflare and in the plugin's settings, and GoBuildWP calls no Cloudflare API. The agent supplies the before-and-after evidence and fires swcfpc_purge_cache once the rules change. Under Read Only it can gather all of the evidence; the purge needs Production Safe. The cache module reference lists every field quoted here.
- "Measure the homepage and tell me whether the request went through Cloudflare and what cf-cache-status said."
- "Show me swcfpc_config with secrets redacted and point out anything that looks like a lifespan or bypass rule. Change nothing."
- "We changed the Cloudflare cache rule. Purge through Super Page Cache, warm the homepage and confirm it comes back as a hit."
Questions
Super Page Cache for Cloudflare questions
Does GoBuildWP purge Cloudflare directly?
No. It fires Super Page Cache's swcfpc_purge_cache hook, and the plugin decides what to clear, including anything at Cloudflare.
Why does GoBuildWP pass a reason string to the purge hook?
The hook requires an argument and threw without one, which once aborted purging on every layer. GoBuildWP now passes GoBuildWP as the reason and isolates each layer's purge.
What does cf-cache-status DYNAMIC mean with this plugin?
DYNAMIC means Cloudflare did not cache that tested response. Other visitors, routes and cache keys can differ. Check the request's cache rules, headers and any disk fallback; cache-verify-in-browser treats this response as an environment blocker.
Is there a WP-CLI equivalent of the agent's purge?
The plugin documents wp cfcache purge_cache, along with status, doctor and settings commands.
Where these facts come from
GoBuildWP behaviour is taken from the plugin source and the ability reference; third-party details from the vendor documentation below, checked by the GoBuildWP team.
- Super Page Cache on WordPress.org
- Super Page Cache FAQ
- Super Page Cache advanced questions
- Super Page Cache FAQ (SPC)
Super Page Cache for Cloudflare is a separate product; no partnership or endorsement is implied.