Environment
- WordPress Multisite (Bricks used to gate an entire subsite via Password Protection)
- Hosting: Rocket.net staging environment, Cloudflare Enterprise at the edge + server-level page cache
- No caching plugins installed — caching is entirely host edge + server page cache
- Bricks Builder v2.3.11 with Bricks Child theme installed
Password Protection config
- Password source = “Template & post password”
- Conditions = “Entire website”
- Disable for logged-in users = on
- Unlock via a form with the “Unlock password protection” action, success message shown on submit
- Note: this password-protection template is the oldest template on the site by creation date — flagging this in case template age/order affects how/when Bricks resolves which password template applies (e.g. priority among multiple templates, or caching of template selection itself)
Issue
After a successful unlock (form submits, success message shown, brx_pp_ + COOKIEHASH cookie set via setcookie() as HttpOnly), reloading the page intermittently shows the password form again instead of site content — even though the browser is sending a valid brx_pp_* cookie on the request.
We traced this to full-page caching at the edge: the locked password-gate HTML gets cached (with a long TTL) the first time a page is requested (before any cookie exists), and subsequent requests — including ones from browsers with a valid unlock cookie — are served that cached locked page straight from the edge, never reaching PHP to check the cookie.
Steps to reproduce
- On a Bricks Multisite install with Password Protection set to “Entire website”, ensure the host/CDN in front of it does full-page/edge caching (no caching plugin — host-level).
- Visit any page on the protected site in a clean/incognito session → password form renders.
- Enter the correct password → Bricks confirms success and sets the brx_pp_* cookie.
- Reload the same URL → password form reappears, as if the cookie were never set.
- Behavior is intermittent and tracks with cache MISS/HIT: works right after a cache purge, breaks again once the locked page gets cached.
Troubleshooting steps taken
- Cleared browser cache and cookies, retested in a fresh/incognito session
- Tested across multiple browsers to rule out local/browser-side caching: Chrome, Firefox, and Opera all reproduce the same behavior
- Tested from a different network/device to rule out local DNS or ISP-level caching
- Confirmed with our host that the brx_pp_* cookie is explicitly whitelisted as a cache-bypass rule at both their server layer and at Cloudflare
- Host confirmed the underlying cause on their side: the page is cached before the cookie is ever set (i.e. the first, unauthenticated request populates the cache), so once cached, the cookie-based bypass rule has nothing left to trigger on for subsequent requests to that same cached URL
- Purged cache and repeated the unlock flow — issue reproduces again once the page is re-cached
Questions for the Bricks team
- Does Password Protection send any cache-control headers (e.g. Cache-Control: private, no-store) on gated pages, or is exclusion from caching expected to be handled entirely by the host/CDN via the cookie?
- Is the unlock check purely cookie-based at PHP render time — meaning if the locked HTML response itself gets cached and served by an edge/CDN without hitting PHP, there’s no way for Bricks to intervene regardless of host configuration?
- Is there documented guidance for using Password Protection behind a full-page/edge caching CDN (Cloudflare, Fastly, host-level page cache, etc.)? If not, is this a known limitation?
- Is there a way to have Bricks emit a distinguishing response header or vary directive on protected templates that a host could use to build a more reliable cache-bypass rule than cookie-presence alone (which only works once the page has already been requested uncached at least once per cache key)?
- On Multisite, COOKIEHASH (and therefore the brx_pp_* cookie name) is derived from the network’s siteurl and is identical across all subsites. Is that intentional, and does it have any implications for using Password Protection independently on multiple subsites of the same network?
- Does template creation date/order play any role in how the applicable password template is resolved for a given request? Asking since the password template involved here happens to be the oldest template on the site.
Happy to provide reproduction steps, HAR files, or response header dumps if useful — this reproduces consistently across Chrome, Firefox, and Opera in clean sessions, and again after any cache purge. Also happy to provide staging environment URL and authentication privately.