Rule examples: WordPress
This page documents the exact WordPress ruleset that Paradarum ships as a one-click preset: which paths get cached, for how long, which cookies bypass the cache, and the recommended general settings. You can build it by hand from the tables below, or apply the whole bundle in a single click from the CMS Presets Quick Setup card.
Instead of creating these rules manually, open the Quick Setup card on the property's General settings page, choose WordPress, and click Apply Preset. Paradarum creates each rule below as an individual, editable cache rule and then applies the recommended general settings. See CMS Presets for the full flow.
These rules control what is cached. To automatically purge the cache when you publish or edit content, install the Paradarum CDN Purge plugin for WordPress.
Cache rules
WordPress mixes static assets (safe to cache for a long time) with dynamic, per-user pages (the admin area, login, and authenticated sessions). The preset caches assets aggressively, bypasses the admin and login surfaces entirely, gives the REST API a tiny TTL, and falls back to a short page cache for everything else.
The patterns use nginx-style location matching: ~* is a case-insensitive regex (matched against the request URI), ^~ is a prefix match, and the bare / is the catch-all fallback that runs last.
| Order | Path / pattern | Match | TTL (seconds) | Meaning |
|---|---|---|---|---|
| 1 | ~* \.(jpg|jpeg|png|gif|ico|svg|css|js|woff|woff2|ttf|eot)$ | Regex | 2592000 | Static assets cached 30 days |
| 2 | ^~ /wp-admin/ | Starts with | 0 | Admin area — never cached |
| 3 | ^~ /wp-login.php | Starts with | 0 | Login — never cached |
| 4 | ^~ /wp-json/ | Starts with | 10 | REST API — 10s micro-cache |
| 10 | / | Catch-all | 1800 | Pages cached 30 minutes |
A TTL of 0 seconds tells the edge never to cache that location. That is why /wp-admin/ and /wp-login.php are set to 0 — those responses are always served fresh. The catch-all / rule is given order 10 so it always runs last, after the more specific rules.
Create these rules in the panel
Open the property's Rules tab, click Add cache rule, and create each row from the table above — set the Path / pattern, the Match type and the TTL. Give the catch-all / rule the highest order so it runs last. See match operators for the match types.
Creating or editing a rule does not push to the OpenResty edge synchronously — the edge polls configuration, so changes go live within a short interval rather than instantly.
Bypass cookies
A page cache is only safe if logged-in users are never served another visitor's cached page. The WordPress preset bypasses the cache whenever any of these cookie name prefixes is present on the request:
| Cookie prefix | Set when |
|---|---|
wordpress_logged_in_ | A user is authenticated to the dashboard |
wp-settings- | A logged-in user has saved admin UI preferences |
comment_author_ | A visitor has left a comment (their details are remembered) |
wp-postpass_ | A visitor has entered a password-protected post password |
Add these cookie prefixes to the catch-all page rule under Location Features → Cache Bypass Cookies, so any logged-in or commenting visitor always gets a fresh response.
The Quick Setup apply action creates the cache rules and applies the general settings, but it does not automatically attach the preset's bypass-cookie list. After applying the WordPress preset, open the catch-all page rule (and any other page-serving rule) and add the four cookie prefixes above under Location Features → Cache Bypass Cookies. Without this, logged-in users risk being served cached pages.
Recommended general settings
The WordPress preset also applies a set of property-wide general settings covering security headers, tracking-parameter stripping, browser caching, and always-online behavior:
| Setting | Value | What it does |
|---|---|---|
| HSTS | Enabled, max_age 31536000 (1 year), include_subdomains, preload | Forces HTTPS for a year, including subdomains; opts into the preload list |
| Clickjacking protection | true | Sends a frame-protection security header |
| MIME-sniffing protection | true | Sends an X-Content-Type-Options: nosniff style header |
| Query string | mode: only with a values list | Strips tracking params from the cache key (see below) |
| Always Online | Enabled for error, 500, 502, 503, 504 | Serves a cached copy when the origin returns those errors |
| Browser caching | mode: override, ttl 3600 | Overrides downstream browser cache lifetime to 1 hour |
Query-string handling: strip tracking parameters
The query_string values list (with mode: only) removes common marketing and analytics parameters (utm_source, utm_medium, utm_campaign, fbclid, gclid, _ga, _gid) from the cache key. Without this, ?utm_source=newsletter and ?utm_source=twitter would be cached as two separate copies of the same page, fragmenting your hit rate. Stripping them means one cached page serves every campaign variant.
Add your own tracking or session parameters to the values list if your campaigns use them — anything that does not change the rendered HTML but does change the URL is a good candidate.
Where to go next
- CMS Presets (Quick Setup) — apply this entire bundle in one click.
- Cache rules — TTLs and Location Features (bypass cookies, cache key, minification, WebP) in depth.
- Header rules — add, set, or delete request and response headers.
- Match operators — the five URL match types.
- Security headers — HSTS, clickjacking, and MIME-sniffing protection.
- Caching and query strings — query-string cache-key behavior at the property level.