WordPress consent
that blocks before the click.

Yes, and the blocking lives in the markup, not in a promise. In strict mode, on by default, the document is captured on its way out and five passes rewrite scripts, iframes, pixels, connection hints and third-party media. Two limits you should know about: actual blocking rests on the catalogue of 175 signatures and on the inline code signatures — an unknown third-party script is allowed by default, an unknown iframe is blocked — and if you switch strict mode off, only the scripts registered by WordPress are handled, not the ones hard-coded into the theme. Finally, a document larger than 8 MB, or a failure of the regular expression engine, is served intact rather than broken.

Yes, that was the constraint it started from. The HTML served is identical for every visitor, neutralised trackers included, and the consent state is rebuilt in the browser from the cookie, then applied before the first paint. No cache can therefore serve one visitor's choices to another. The trade-off is explicit: the visitor's regime is decided on the client side, so without JavaScript nothing is recorded. A visitor without JavaScript sees a noscript block, loads nothing non-essential, and is never locked behind a window they cannot close.

It decides the legal model: opt-in for GDPR, UK PECR, the Swiss nFADP, Law 25, LGPD, POPIA, PIPL and DPDP; granted until refusal for CCPA, the generic US profile and Australia. It also decides whether the “Do Not Sell or Share” link is shown (CCPA and generic US only), whether the GPC signal is binding (the same two profiles: elsewhere the signal is reflected on screen but nothing is recorded), and both the language and the supervisory authority of the generated documents. Country detection is optional and off by default; it fails closed, meaning towards the strictest regime. Two limits we own up to: no state-by-state granularity in the United States and none province by province in Canada, and the MaxMind file is neither downloaded nor uploadable by the plugin — you drop it into uploads/ow-geoip/ yourself.

It proves exactly as much as the key that signs it, and the plugin tells you so plainly. Every row is signed with HMAC together with the hash of the one before it, and the head anchor is kept outside the table, so an edit, a truncation or a wipe all show up at verification. But if AUTH_KEY and AUTH_SALT are not in your wp-config.php and you have not defined OWC_LEDGER_KEY, the key comes from the database: anyone with database access can re-sign the chain. In that case the plugin shows an admin warning and reports for itself that the chain is no longer tamper-evident, instead of carrying on claiming otherwise.

No, and that is better said before you commit than after. The module implements TCF v2.2 in the browser — the __tcfapi API, an encoded TC string, the euconsent-v2 cookie — but it does not supply a CMP ID: that is assigned by IAB Europe once you register, and without it the module emits strictly nothing. The scope is bounded too: Core segment only, no publisher restrictions emitted, two special features supported, no global scope. In plain terms it behaves as an unofficial CMP-compatible mode, which is enough for many integrations but does not replace an official registration — Google AdSense in particular refuses it in production in the EEA. The module is off by default.

Deactivating touches no data: it merely removes the scheduled tasks. On deletion, two things always go, whatever your setting: the scheduled tasks and the data subject request table, the only table holding directly identifying data about other people that nothing bounds once the plugin has gone. The rest — consent ledger, scanner findings, tracker catalogue — survives, unless you have explicitly ticked full erasure, which is unticked by default: your proof of consent under Article 7(1) should not disappear with an uninstall.