Skip to content

v3.8.0 — Production cache policy and scoped maintenance

Choose a tag to compare

@djknucklehead djknucklehead released this 21 Sep 16:38

The Install cache buttons on network site rows and subsite settings now install the production-proven September 19 cache policy. Anonymous public HTML shares its cache key across unknown/tracking query values, while functional/private requests and submissions bypass. Supported static assets cache across the domain and keep their full versioned query strings. Gravity Forms front-end HTML and private-response safeguards are retained.

Existing verified plugin-owned policies are backed up and upgraded. Already-current policies are left unchanged. Safe custom exceptions are preserved; conflicting or unrecognized overlapping rules stop installation for review. Cache installation does not change security rules or request a broad purge.

Paced maintenance now invalidates known WordPress object-cache keys for the selected site before its WP Engine page-cache dispatch, followed by its hostname-scoped Cloudflare purge. Sibling-site/global caches remain intact. Invalidation failures block page/CDN dispatch and use bounded retries. The running plugin version now appears beside network, subsite and standalone settings-page titles.

Validation: PHP syntax, purge/object-cache/queue/security regressions, canonical production snapshots, cache/defense expressions, HTTP runtime-guard tests, deterministic package validation, and real standalone/multisite WordPress integration tests passed. External providers were simulated; this release was not deployed to WordPress and live Cloudflare zones were not changed.

Limits: known-key object invalidation does not enumerate opaque third-party keys or individually cached deleted records. Reserved query markers conservatively bypass even when present in query values. WP Engine dispatch remains asynchronous. Persistent-cache isolation is covered by scoped test doubles; the local WordPress integration fixtures used the built-in object cache.