Cache & Access

Cache Layers

Layer	Where	What It Caches	Invalidation
Browser	Visitor device	CSS, JS, images	Versioned asset URL, hard refresh
LiteSpeed Cache	GC-US-M10 (OpenLiteSpeed)	WordPress pages, GP Elements output	Targeted origin-direct PURGESINGLE per URL (default); purge_all for structural changes (see LiteSpeed Cache CLI)
PHP OPcache	GC-US-M10	PHP bytecode	wp flush-opcache flush
Cloudflare	Edge network	HTML pages, static assets	Targeted API URL purge (default); purge_everything for structural changes

Invalidation Strategy

Default = targeted. When content changes, only the affected pages are invalidated — the changed post URL(s), the homepage (which lists latest-reference cards), and their Cloudflare edge copies. Untouched pages keep warm caches, so returning viewers are unaffected.

Full purge (purge_all + Cloudflare purge_everything) is reserved for structural changes: theme, plugin, GP Elements, or configuration deploys.

The content-sync pipeline applies this automatically (see LiteSpeed Cache CLI). Manual examples:

# LiteSpeed targeted (per URL, origin-direct)
curl -ksS --resolve id86.net:443:127.0.0.1 -o /dev/null -w "%{http_code}\n" \
  "https://id86.net/<slug>/?LSCWP_CTRL=PURGESINGLE"   # expect 200

# Cloudflare targeted (per URL)
source ~/.ssh/cloudflare/.env
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_FULL_CONTROL_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://id86.net/<slug>/","https://id86.net/"]}'

Always clear all four layers in order when a change is not visible after a deploy.

Important: wp litespeed-purge all does not work on this site — the request routes through Cloudflare Access and never reaches the origin. Use the origin-direct purge documented in LiteSpeed Cache CLI. The LiteSpeed Cache plugin is also inactive by default; activate it during the sites' development phase (see LiteSpeed Cache CLI).

Cloudflare Configuration

• DNS: Proxied (orange cloud) for all id86.net subdomains.
• SSL: Full (strict), origin cert managed by OpenLiteSpeed.
• Cache: Standard browser cache TTL; purge via API after deploys.
• WAF: Cloudflare WAF active for threat protection.
• Access (Zero Trust): Protects the public site and subdomains with email OTP.

Cloudflare Access Applications

The id86.net zone has 60+ Access applications. Key ones:

App	Domain	Policy
Access - id86.net	id86.net	Email OTP, donnyaw@gmail.com
Access - sites.id86.net	sites.id86.net	Email OTP, donnyaw@gmail.com

Access verification returns a 302 redirect to rezriz.cloudflareaccess.com/cdn-cgi/access/login/... for unauthenticated requests.

Cloudflare Cache Purge

source /home/rezriz/.ssh/cloudflare/.env
zone_id=$(curl -sS -H "Authorization: Bearer $CF_FULL_CONTROL_TOKEN" \
  "https://api.cloudflare.com/client/v4/zones?name=id86.net" | jq -r '.result[0].id')
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$zone_id/purge_cache" \
  -H "Authorization: Bearer $CF_FULL_CONTROL_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

Operational Caution

• Do not disable Cloudflare Access to test visual changes. Use origin verification from the production host instead.
• Public browser automation (Playwright) is blocked by Cloudflare Access. Use authenticated sessions for visual review.