COOKR – Cookie Consent & Script Blocking

GDPR cookie consent with real script blocking.

Block Google Analytics, Google Tag Manager, Meta Pixel, Hotjar, YouTube embeds, and other third-party services before they reach the browser.

Unlike JavaScript-based consent tools, blocked scripts never reach the browser at all.

Most cookie consent plugins display a banner and rely on JavaScript to stop tracking scripts. In many cases, those scripts can begin loading before the visitor has made a choice.

COOKR takes a different approach.

Scripts are blocked server-side before page delivery. Third-party services cannot execute until consent is explicitly granted. This helps website owners meet GDPR and TTDSG requirements more reliably.

Avoids the client-side race conditions common to JavaScript-only consent tools. No script guessing. No “hope it loads in time.”

Consent enforcement instead of consent theatre.

✓ Server-side script blocking — blocked before the browser receives them
✓ Google Consent Mode v2 support
✓ No external consent cloud
✓ No proxy infrastructure
✓ No visitor data sent to third parties
✓ Works entirely on your WordPress installation

Built for site owners, agencies, and developers who want real GDPR cookie consent enforcement.

COOKR CORE includes:

• Consent banner & preferences UI
• Server-side script interception via PHP output buffer
• Auto-Blocker for third-party scripts and iframes
• Runtime Inspector
• CSP-aware restoration with nonce propagation
• Google Consent Mode v2 support
• Full JavaScript API (window.cookrConsent)
• Compatibility Center — live enforcement status plus a tested-stack matrix with honest VERIFIED/PARTIAL/UNKNOWN/FAILED states
• Automatic optimizer exclusions — LiteSpeed, WP Rocket, Autoptimize, FlyingPress
• Self-hosted operation — no external services required

COOKR RADR additionally includes:

• Privacy Radar — runtime detection and classification of third-party services
• Enforcement Verification Framework — structured protocol for proving enforcement claims
• Curated signature database with automatic weekly updates

How It Works

COOKR intercepts scripts in the PHP output buffer using WP_HTML_Tag_Processor before delivery to the browser. Matching script and iframe tags are neutralised server-side and restored only after the visitor grants consent.

There is no client-side race condition because blocking happens before the browser receives the page.

Reliability

Your consent choices are applied precisely — analytics, marketing, and external media are gated independently, with no mixups between categories. You can withdraw consent at any time; it takes effect starting with your next page load.

COOKR is safe to use with page caching. The server-rendered HTML is always consent-neutral — a cached page never carries one visitor’s consent-based content into another visitor’s response.

If COOKR encounters an internal enforcement failure, it fails closed rather than silently serving unblocked trackers.

Scope of Enforcement

COOKR blocks known trackers that are present in the server-rendered HTML as standard external <script src> or <iframe> elements, before the visitor’s browser ever receives them.

It does not intercept arbitrary JavaScript behaviour at runtime. This includes: scripts and iframes created dynamically after page load, document.write()-based script injection, and tracker requests proxied through a first-party URL — COOKR matches known third-party hostnames, so a same-origin proxy path is invisible to that classification regardless of what it forwards to server-side.

One consequence worth knowing specifically: once a tag manager such as Google Tag Manager is itself permitted to run (its own <script src> was consented to and restored), whatever tags that container subsequently injects at runtime are outside COOKR’s enforcement scope. Configuring consent-aware tag firing inside the tag manager itself remains the site owner’s responsibility.

These are architectural limits of a server-side, markup-level blocker, not partial results. If your site loads trackers through any of the paths above, COOKR will not enforce consent on them — migrate them to standard external <script src>/<iframe> markup to bring them into scope.

Auto-Blocker

Enable in Settings. Off by default.

When enabled, COOKR rewrites matching script tags and iframe tags server-side — setting type="text/plain" and preserving original attributes in data-cookr-* attributes for restoration after consent.

Test after enabling when using WP Rocket, LiteSpeed Cache, NitroPack, or Cloudflare Rocket Loader.

Runtime Inspector

The Runtime Inspector exposes third-party runtime activity directly in the browser — blocked scripts, restored services, iframe activity, detected domains.

Enable in Settings. Append ?cookr_debug=1 to any frontend URL while logged in as administrator.

Compatibility

COOKR is verified compatible with WP Rocket and Autoptimize. It is partially verified with LiteSpeed Cache — see the Compatibility Center for exactly which parts are confirmed. For other caching and optimization plugins, check your own site’s Compatibility Center before assuming full compatibility.

CSP-aware

COOKR never sends its own Content-Security-Policy header. It supports strict Content-Security-Policy setups without requiring unsafe-inline, provided your CSP layer supplies a nonce through the cookr_csp_nonce filter.

If your site runs a nonce-based script-src policy, hook the cookr_csp_nonce filter once with the nonce your CSP layer already generates for the response:

add_filter( 'cookr_csp_nonce', function () { return my_csp_plugin_get_nonce(); } );

COOKR then applies that single nonce consistently to its own scripts and to every dynamically-restored, consented tracker script. Without a hooked cookr_csp_nonce provider, COOKR’s own scripts and any restored tracker scripts will be blocked by a strict script-src policy with no 'unsafe-inline' — the Diagnostics self-test reports this explicitly (CSP nonce: pass/warn) rather than silently assuming it works.

Developer JS API

cookrConsent.has('analytics')
cookrConsent.require('marketing', callback)
cookrConsent.whenConsented('analytics').then(fn)
cookrConsent.on('consent' | 'change' | 'decline' | 'reset', handler)
cookrConsent.off(event, handler)
cookrConsent.getConsent()
cookrConsent.getExpiry()
cookrConsent.categories()
cookrConsent.reset()

Consent Categories

• Necessary — Always active.
• Analytics — GA, GTM, Matomo, Hotjar, Clarity, etc.
• Marketing — Meta Pixel, Google Ads, TikTok, LinkedIn, etc.
• External Media — YouTube, Vimeo, Google Maps, etc.

Does COOKR require an external cloud service?

No. COOKR runs entirely on your WordPress installation.

Does visitor consent data leave the server?

No. Consent data is stored locally on your site.

Is the Auto-Blocker enabled by default?

No. Enable and test it after installation, particularly when using caching or JavaScript optimization plugins.

Which services can be blocked?

Any third-party script or iframe matching configured domains, when present in the server-rendered page as a standard external <script src> or <iframe> element. Examples: Google Tag Manager, Meta Pixel, YouTube embeds, TikTok Analytics.

What about tags Google Tag Manager loads on its own?

COOKR gates GTM’s own <script src> load — GTM itself will not run before consent. Once a visitor consents and GTM is restored, tags that GTM subsequently injects at runtime are outside COOKR’s enforcement scope; that’s a tag manager configuration question, not something a markup-level blocker can see. See “Scope of Enforcement” above for the full picture.

Does COOKR support Google Consent Mode v2?

Yes. Enable in settings when using GTM or GA4.

How do I inspect runtime activity?

Enable the Runtime Inspector in settings and append ?cookr_debug=1 to any frontend URL while logged in as administrator.

Does COOKR store personal data?

The consent log stores a hashed IP (not the raw IP address), consent choices, and a timestamp. The raw IP address is never stored.

Is COOKR compatible with strict CSP?

Yes, if your site’s CSP layer supplies a nonce. COOKR does not generate or send its own CSP, and it cannot see a nonce your CSP-generating plugin creates unless you connect the two: hook the cookr_csp_nonce filter once to return that nonce. COOKR then applies it consistently to its own scripts and to every dynamically-restored, consented tracker script. Without that filter hooked, a strict script-src policy with no 'unsafe-inline' will block COOKR’s own scripts as well as any restored trackers — check Settings → Diagnostics, which reports the CSP nonce check explicitly rather than assuming success.

Will COOKR work with caching plugins such as LiteSpeed Cache, WP Rocket, or Cloudflare?

Yes, but always test after enabling script optimization features such as JavaScript combine, defer, delay, or Rocket Loader. COOKR performs script blocking server-side, but aggressive optimization plugins may alter script delivery and should be verified on your site.

COOKR automatically excludes itself and the tracker scripts it blocks from LiteSpeed Cache, WP Rocket, Autoptimize, and FlyingPress’s JavaScript optimization pipelines — no configuration required. Check the Compatibility Center (COOKR → Compatibility) for the current tested/verified status of your specific stack.

Does COOKR require HTTPS?

Yes. COOKR requires HTTPS for consent state to persist correctly across page loads. Modern browsers restrict cookie behaviour on HTTP origins — on HTTP, the consent cookie may not persist, causing the banner to reappear on every page load. HTTPS is also a legal recommendation under GDPR for any site collecting consent.

What WordPress version is required?

WordPress 6.2 or higher. COOKR uses WP_HTML_Tag_Processor for safe, attribute-aware script rewriting, introduced in WP 6.2.

External Services

This plugin does not connect to any external service by default.

The auto-blocker contains a built-in list of known third-party domains (such as googletagmanager.com, connect.facebook.net, maps.googleapis.com, etc.) that is used purely as a local reference to identify and block scripts before consent. No data is sent to these domains by this plugin — the list is pattern-matching data stored locally in the plugin code.