Moving the consent gate into the browser does not move the test
6 July 2026 · 5 min read
We moved the analytics gate out of PHP so the HTML would stop varying by cookie. For a while the entire gate could have been deleted with every server-side test still green.
Serving different HTML depending on a consent cookie means the page cannot be cached, or has to be cached per cookie value, which is nearly the same as not caching it. The usual fix is to send the same HTML to everybody and let a script in the browser decide whether the analytics tag is ever loaded.
That is the right call. It also quietly moves the most compliance-sensitive decision in the application out of the language your test suite covers.
What the gap looks like
Before the move, a server-side test asserted that the tag was absent without consent. After it, the same test asserts something that is now true of every response, consented or not, so it passes forever and proves nothing. The logic that actually decides whether a third party is contacted is in a JavaScript file with no test at all.
Delete the gate entirely and the suite stays green.
Logic does not stop needing a test when it changes language
If a decision moves from PHP to the browser, the test moves with it - to a JavaScript test runner, asserting on the same behaviour: no consent, no network call; consent withdrawn, no further calls; a stored record from an older version of the banner, interpreted the way the current code claims to interpret it.
Two smaller things that bite
A cookie written by JavaScript cannot be read by a framework that encrypts cookies, unless you exclude it. Get that wrong and the banner reappears on every page load forever.
And withdrawal has to be as easy as consent. That means the banner must be reachable again after the first choice - a link in the footer, not a one-time decision the visitor can never revisit.
