Cloudflare admin page

The Cache tab groups the integration's cache controls.

Enlarge screenshot

A real Payload global (slug cloudflare, label "Cloudflare") — it shows up natively in the admin Globals nav rather than as a bespoke custom view. Every control on the page, including the persisted autoPurge field, autosaves the instant it changes and gives contextual toast feedback — nothing here needs the document Save button, which is hidden entirely. Every boolean zone setting below (Development mode, "I'm under attack", Automatic HTTPS Rewrites, WAF, Always Online, Image optimization, Auto-purge on publish) renders as a native-feeling switch (role="switch", keyboard-operable), not a checkbox: clicking it flips immediately (optimistic), a brief pending state covers the — often slow — Cloudflare round trip (or, for auto-purge, the Payload global save), and a failed request reverts the switch and shows an error toast rather than ever leaving it in a stuck or bouncing state; success also toasts (e.g. "Development mode enabled."). On a site publishing through more than one Cloudflare zone the page also gains a domain selector, cross-domain "differs" badges and an apply-to-all action — see Managing every domain from the admin page. Sections:

• Connection status — read-only panel: a Cloudflare-mark logo, a brand-orange undertone, and either the connected zone's name or "Not connected". Plan and auth mode aren't shown on this card (they're available from the settings endpoint, not rendered here).
• Auto-purge on publish — the one field actually stored in the global's document; every other control on the page is a live zone control that talks directly to the Cloudflare API and stores nothing in Payload. It still autosaves like every other switch, via a direct POST to this global's own update endpoint.
• Optimize for Systhema — a one-click button applying the recommended bundle below, listing per-setting results (applied / skipped by plan / failed) rather than a single pass/fail, since some settings can fail independently of the others (token scope, plan), plus a summary success or error toast.
• Cache tab:
  • Development mode switch — bypasses the cache for the whole zone; Cloudflare automatically reverts it after 3 hours.
  • Purge everything — behind a confirmation modal; the outcome (purged / Cloudflare unreachable, revalidated only / error) surfaces as a success or error toast, not inline text.
  • Purge by URL — a textarea (one URL per line), batched into groups of 30 automatically; the outcome surfaces as a success or error toast the same way.
• Security tab:
  • "I'm under attack" — flips security_level to under_attack and remembers the level active before it, restoring that level when turned back off.
  • Security level select (disabled while "I'm under attack" is on) — offers Off/Essentially off/Low/Medium/High, except Off is only offered on Enterprise-plan zones (Cloudflare rejects it elsewhere); every other level is available on every plan. A successful change toasts the new level.
  • Automatic HTTPS Rewrites switch.
  • Web Application Firewall (WAF) switch — plan-gated (Pro+); shows an upgrade hint rather than hiding when unavailable.
• Speed tab:
  • Always Online switch.
  • Image optimization — a single combined switch driving Cloudflare's mirage + polish settings together; plan-gated (Business+).

The "Optimize for Systhema" bundleLink to this section

Setting	Value	Plan gate
security_level	medium	—
cache_level	aggressive	—
browser_cache_ttl	14400	—
always_online	on	—
development_mode	off	—
ipv6	on	—
websockets	on	—
ip_geolocation	on	—
email_obfuscation	off	—
server_side_exclude	on	—
hotlink_protection	off	—
rocket_loader	off	—
automatic_https_rewrites	on	—
mirage	on	Business+
polish	lossless	Business+

The two Business+ settings are skipped (not counted as failures) on lower plans. Any other setting that fails — some token types reject specific settings endpoints even with the right scope — is reported as failed while the rest of the bundle keeps applying.

email_obfuscation and rocket_loader are deliberately off even though Cloudflare's WordPress plugin turns them on: both rewrite the HTML after React rendered it. Email obfuscation in particular replaces every email address in the page with __cf_email__ placeholder elements while the RSC payload keeps the originals, so React throws a recoverable hydration mismatch (minified error #418) whenever hydration runs before Cloudflare's decode script — most visibly inside the admin's live-preview iframe. Cloudflare enables email obfuscation by default on new zones, so running the Optimize bundle also cleans that default up.

AccessLink to this section

Reading the page (to see connection status) needs cloudflare.read or global.cloudflare.update. Mutations split by capability, matching the endpoints' own gates: Purge everything and Purge by URL need cloudflare.purge; every zone-setting toggle/select, the Optimize button, and the autoPurge switch itself strictly need global.cloudflare.update.

Admin-bar cache clearingLink to this section

When Cloudflare is enabled and the signed-in user holds cloudflare.purge, two buttons appear on the front-end Systhema admin bar, next to the existing preview/logout controls:

• Clear cache — purges the Cloudflare edge cache for the current page's path and triggers a Next.js revalidation for it, then refreshes the page.
• Clear all caches — behind a confirm dialog, then purge_everything plus a revalidation of every published page.

Both post to /sys/cloudflare-purge, a Next.js route protected by capability-checked cookie auth and a same-origin (CSRF) guard rejecting cross-site requests. The buttons appear as soon as Cloudflare is enabled — even if the zone hasn't resolved yet ("not connected") — because the purge leg silently no-ops and only the Next.js revalidation runs in that case. They stay hidden while Cloudflare itself is disabled.