Title: COOKR – Cookie Consent & Script Blocking
Author: danjed
Published: <strong>مئی 29, 2026</strong>
Last modified: ستمبر 18, 2026

---

Search plugins

![](https://ps.w.org/cookr-cookie-consent-script-blocking/assets/banner-772x250.
png?rev=3554078)

![](https://ps.w.org/cookr-cookie-consent-script-blocking/assets/icon-256x256.png?
rev=3554198)

# COOKR – Cookie Consent & Script Blocking

 By [danjed](https://profiles.wordpress.org/danjed/)

[Download](https://downloads.wordpress.org/plugin/cookr-cookie-consent-script-blocking.1.9.33.zip)

 * [Details](https://bcc.wordpress.org/plugins/cookr-cookie-consent-script-blocking/#description)
 * [Reviews](https://bcc.wordpress.org/plugins/cookr-cookie-consent-script-blocking/#reviews)
 * [Development](https://bcc.wordpress.org/plugins/cookr-cookie-consent-script-blocking/#developers)

 [Support](https://wordpress.org/support/plugin/cookr-cookie-consent-script-blocking/)

## Description

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.

## Screenshots

[[

[[

[[

[[

[[

[[

[[

## Reviews

There are no reviews for this plugin.

## Contributors & Developers

“COOKR – Cookie Consent & Script Blocking” is open source software. The following
people have contributed to this plugin.

Contributors

 *   [ danjed ](https://profiles.wordpress.org/danjed/)

[Translate “COOKR – Cookie Consent & Script Blocking” into your language.](https://translate.wordpress.org/projects/wp-plugins/cookr-cookie-consent-script-blocking)

### Interested in development?

[Browse the code](https://plugins.trac.wordpress.org/browser/cookr-cookie-consent-script-blocking/),
check out the [SVN repository](https://plugins.svn.wordpress.org/cookr-cookie-consent-script-blocking/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/cookr-cookie-consent-script-blocking/)
by [RSS](https://plugins.trac.wordpress.org/log/cookr-cookie-consent-script-blocking/?limit=100&mode=stop_on_copy&format=rss).

## Changelog

#### 1.9.33

 * Docs: added a “Reliability” section (consent accuracy, cache safety, fail-safe
   enforcement) and a “Compatibility” section (named only where the Compatibility
   Center currently supports the claim — WP Rocket and Autoptimize verified, LiteSpeed
   Cache explicitly partial). Tightened the CSP-aware section’s opening sentence
   to put the `cookr_csp_nonce` requirement up front rather than reading as automatic.
   No functional changes — every claim added here already has a corresponding live
   Compatibility Center status, per this week’s trust-testing program.

#### 1.9.32

 * Added: Compatibility Center now includes an “Enforcement Fail-Safe” check — verifies
   the fail-closed fallback mechanism (added in the enforcement rearchitecture) 
   is present and correctly wired on this installation, and reports any recorded
   fallback events. This is the check that licenses the product claim that COOKR
   never silently serves unblocked trackers on an internal failure. Also adds an
   informational “Update channel” row (CORE: confirms updates flow through WP.org
   as usual; RADR: reports the update-service’s reachability — this never affects
   the main enforcement status, by design).

#### 1.9.31

 * Fixed: `cookr_fallback_events` (enforcement fail-closed fallback history, introduced
   in 1.9.30) was missing from the uninstall cleanup list — an orphaned option left
   behind on a full uninstall with “preserve data” off. Found during upgrade-safety
   testing.

#### 1.9.30

 * Security/privacy fix: COOKR’s enforcement now fails closed instead of open. Previously,
   if the script/iframe rewrite pass threw for any reason (a plugin conflict, an
   edge case in the HTML parser, a future bug), COOKR served the original, completely
   unblocked page to every visitor — including ones with zero consent — with no 
   visible signal beyond a debug-log line gated behind `WP_DEBUG_LOG` (off by default
   in production). Found via a controlled failure test, confirmed live. Replaced
   with a three-stage chain: the normal rewrite, an independent emergency fallback
   that conservatively neutralises every cross-origin `<script>`/`<iframe>` (deliberately
   not reusing the classifier or parser that may have just failed), and — if even
   that fails — a minimal privacy-safe response with zero third-party resources 
   instead of the original page. The Runtime Inspector’s own scanning is now strictly
   best-effort and can never affect enforcement. A persistent, WP_DEBUG-independent
   admin notice and a new Diagnostics check surface if this fallback is ever triggered.

#### 1.9.29

 * Fixed: CSP nonce propagation was structurally non-functional — COOKR read back
   a nonce from its own script handle in the same call that registered it, before
   any external CSP plugin could ever attach one, so the value was always empty 
   and dynamically-restored consented scripts were silently blocked by any real 
   strict `script-src` policy. Replaced with an explicit `cookr_csp_nonce` filter:
   site owners hook it once with the nonce their CSP layer already generates, and
   COOKR applies that single value consistently to its own scripts and to every 
   restored tracker script. The Diagnostics self-test now reports pass/warn honestly
   instead of a permanent placeholder warning, and the CSP documentation no longer
   claims “no manual configuration required.”

#### 1.9.28

 * Accessibility fixes found during a consent-decision accessibility audit: category
   checkboxes now expose the category name as their accessible name (`aria-labelledby`)
   with the explanatory sentence as a proper description (`aria-describedby`), instead
   of a short `aria-label` that silently hid it from screen readers. Fixed insufficient
   text contrast on the “Customise”/preferences-toggle control and the category-
   description text (light and dark mode). The banner dialog now carries a `lang`
   attribute matching COOKR’s configured banner language (independent of the site’s
   own `<html lang>`), and its title is a real heading (`<h2>`, referenced via `
   aria-labelledby`) instead of a plain paragraph.

#### 1.9.27

 * New: Custom Domains setting. Manually add a domain COOKR hasn’t recognised yet
   and assign it to Analytics, Marketing, or External media — no longer requires
   RADR’s automated scan to unlock manual domain blocking. Validates hostnames, 
   rejects duplicates, and keeps built-in signatures separate from custom rules.

#### 1.9.26

 * Autoptimize compatibility promoted to VERIFIED. Live-tested with a fresh Autoptimize
   3.1.15.1 install (free, no license required): JS and CSS optimization (minify
   + combine) tested individually and together, all trackers stayed blocked, zero
   tracker requests before consent. Documented a real, non-breaking behavioral nuance:
   Autoptimize still individually minifies COOKR’s own excluded assets rather than
   leaving them fully untouched — confirmed the served content is byte-correct and
   does not affect the blocking guarantee

#### 1.9.25

 * WP Rocket compatibility promoted to VERIFIED. The last open gap (post-consent
   network execution) was closed by re-testing in a real Chrome browser: a genuine
   network request fired correctly after consent for a neutral test domain, confirming
   the earlier “not tested” result was a limitation of the automated test tooling
   used, not a product defect. All 6 tested dimensions (Minify JS, Combine JS, Defer
   JS, Delay JS, page-cache isolation, post-consent execution) are now VERIFIED

#### 1.9.24

 * Compatibility Center: redesigned the compatibility matrix schema to support per-
   dimension evidence, not just one status per optimization stack. WP Rocket and
   LiteSpeed Cache now record real, individually-tested results for each dimension(
   Minify JS, Combine JS, Defer JS, Delay JS, page-cache isolation, etc.) with an
   honestly-derived overall status — a stack with several verified dimensions and
   one still-open one now shows PARTIAL with the real breakdown visible, instead
   of a single, less informative badge. Backward compatible: existing code reading
   a stack’s overall status is unaffected; entries without per-dimension data behave
   exactly as before

#### 1.9.23

 * Removed the full-consent server-side bypass so cacheable HTML remains consent-
   neutral across visitors. A server-side shortcut previously skipped the blocking
   rewrite entirely for a visitor with a valid, fully-granted consent cookie — safe
   for that one uncached visitor, but a real cross-visitor leak the moment any full-
   page cache (WP Rocket, LiteSpeed, etc.) stored and replayed that exact response,
   serving every subsequent visitor an unblocked tracker regardless of their own
   consent state. Found via real page-cache testing. Server-rendered HTML is now
   always the blocked canonical form for every visitor; restoration for consented
   categories continues to happen exclusively client-side, unaffected by caching
   since it reads each visitor’s own consent cookie in their own browser

#### 1.9.22

 * WP Rocket compatibility: the 1.9.21 fix only protected COOKR’s own script, not
   the third-party trackers it blocks. Live testing against a real licensed WP Rocket
   install found Minify JS and Delay JS both strip COOKR’s blocking from trackers
   and execute them before consent, because WP Rocket processes the page before 
   COOKR’s own blocking runs (an output-buffer ordering issue, confirmed via direct
   tracing). Fixed by excluding all of COOKR’s known tracker domains from WP Rocket’s
   JS pipelines. Verified: zero tracker network requests before consent with WP 
   Rocket’s full JS optimization pipeline enabled. Compatibility matrix moved to
   PARTIAL — known limitations (custom/self-hosted scripts, post-consent network
   verification, page-cache isolation) documented, not overclaimed

#### 1.9.21

 * WP Rocket compatibility: found the integration had been a complete no-op since
   it was written. The filter it hooked, `rocket_excluded_strings`, does not exist
   anywhere in WP Rocket’s codebase — confirmed by cloning and grepping WP Rocket’s
   actual public source, since it has no free WP.org listing or trial to install
   and test against directly. Replaced with the real filters (`rocket_exclude_js`,`
   rocket_exclude_defer_js`, `rocket_delay_js_exclusions`), verified against WP 
   Rocket’s own source and its official Termly integration. Code-verified, not yet
   live-tested; compatibility matrix status stays UNKNOWN pending a real test

#### 1.9.20

 * LiteSpeed Cache compatibility: attempted guest_mode/guest_optimization/cache_persistence/
   esi verification, found this test environment doesn’t run genuine LiteSpeed Web
   Server (plain Apache), so page-level caching — what those checks actually test—
   can’t be meaningfully verified here. Documented in the compatibility matrix; 
   needs a real LSWS/OpenLiteSpeed environment to complete

#### 1.9.19

 * Added a Compatibility Center admin page (COOKR  Compatibility) surfacing the 
   plugin’s own internal enforcement-verification data, previously invisible: live
   status of the auto-blocker, Runtime Inspector, optimization-stack detection, 
   and known conflict signatures on this specific installation, plus the full reference
   compatibility matrix (8 known optimizer/CDN stacks, honestly marked Verified/
   Partial/Not yet verified/Failed) with whichever stacks are actually detected 
   on this site called out inline

#### 1.9.18

 * Fixed the LiteSpeed Cache/WP Rocket/FlyingPress exclusion filters hardcoding 
   COOKR’s plugin folder name in the excluded path (`/wp-content/plugins/cookr/...`)—
   a string that only matches if the plugin folder happens to be named exactly “
   cookr”. Every real CORE install (the actual WP.org-distributed folder name, `
   cookr-cookie-consent-script-blocking`) never matched, so these three optimizers’
   exclusions were silently no-ops on CORE the whole time. Now resolved dynamically
   via `COOKR_PLUGIN_URL` at runtime instead
 * Fixed COOKR’s own banner failing to initialise under LiteSpeed Cache’s “Delay
   JS Execution” feature specifically: LiteSpeed checks a separate exclusion list
   for Defer/Delay than the one COOKR was already registered on (which only ever
   covered Combine/Minify). Trackers stayed correctly blocked throughout, but the
   banner and consent JS API didn’t load until the visitor scrolled or clicked. 
   Fixed by also hooking LiteSpeed’s `litespeed_optm_js_defer_exc` filter
 * LiteSpeed Cache compatibility: verified JS Delay — all 6 protocol test cases 
   pass (after the fixes above)

#### 1.9.17

 * LiteSpeed Cache compatibility: verified JS Defer — all 6 protocol test cases 
   pass with JS Combine off / JS Defer on. See the Enforcement Verification Framework
   compatibility matrix for full detail

#### 1.9.16

 * Fixed miscategorized Google Ads conversion tags: the auto-blocker classified 
   every script on `googletagmanager.com` as “analytics” regardless of which Google
   product it actually loaded, so a Google Ads conversion tag (`gtag/js?id=AW-...`)
   was silently gated behind Analytics consent instead of Marketing consent. The
   blocker now reads the tag’s `id` parameter — `AW-*` is classified as marketing,`
   G-*` (GA4) remains analytics, GTM containers (`GTM-*`) are unchanged pending 
   a separate design decision, since a single container can load both marketing 
   and analytics tags
 * This release also folds in the 1.9.13–1.9.15 fixes below, which were written 
   up at the time but never reached a tagged release — this is their first time 
   shipping to WordPress.org

#### 1.9.15

 * Fixed CORE packaging: the build script was incorrectly stripping `assets/cookr-
   debug.js` (the Debug Inspector script) from CORE builds, despite Debug Inspector
   being a documented, default-on feature in both CORE and RADR. CORE builds now
   correctly include this file. No functional change to this codebase itself — RADR
   was never affected, since it has always included the file directly from source

#### 1.9.14

 * Fixed banner overflowing the viewport edge on mobile (≤480px): `#cookr-banner`
   had no explicit `box-sizing`, so the mobile layout’s `width: 100%` plus the banner’s
   existing border was rendered as `100vw + border-width`, causing the banner to
   extend ~2px past the right edge of the screen. Added `box-sizing: border-box`
   to the shared `#cookr-banner, #cookr-reopen` rule so the banner’s total rendered
   width exactly matches the viewport on mobile. No visual change on desktop (320px
   fixed-width banner)

#### 1.9.13

 * Fixed missing CSS for the disabled “Sync with active theme” (Theme Sync) field
   in the admin dashboard: when Scoped Banner Styling (custom CSS / a built-in preset)
   is active, JavaScript already added a `cookr-accent--disabled` class and an “
   Overridden by Scoped Banner Styling” message to the Theme Sync field — matching
   the existing accent-colour picker behaviour — but `admin.css` only styled this
   disabled state for the accent field, not the Theme Sync field. The font pills
   remained fully clickable and visually normal with no indication that font sync
   was inactive. The disabled-state styling (38% opacity, disabled pointer events,
   override message) now applies to both fields
 * No functional change to font sync itself — fonts synced from the active theme
   still only apply to the live banner when no custom CSS/preset is active (custom
   CSS retains full control of typography by design). This fix makes that existing,
   correct behaviour visible and understandable in the admin UI

#### 1.9.12

 * Fixed COOKR CRAZE built-in preset: the minimised (reopen) button was unstyled
   and the preferences-panel toggle switches showed the site’s global accent colour(
   could be any colour, including red) instead of the preset’s green — the preset
   never set `--cookr-accent`, so `cookr.css`‘s defaults for `#cookr-reopen` and`.
   cookr-switch input:checked + .cookr-slider` (both driven by `var(--cookr-accent)`)
   fell through to the global accent_color setting
 * Added `#cookr-banner, #cookr-reopen { --cookr-accent: #00ff88; }` and `#cookr-
   reopen svg rect { fill: #000000; stroke: #00ff88; }` to the preset — toggle switches
   and the reopen pill/dot now render in the preset’s black/green theme regardless
   of the global accent colour setting
 * Fixed admin preview panel loading spinner: `@keyframes cookr-spin` only animates`
   transform: rotate()`, but the spinner’s centering also used `transform: translate(-
   50%, -50%)` — animating `transform` between an implicit `translate(...)` start
   and a `rotate(360deg)` end produced a visible jump/skip instead of a clean spin.
   Centering now uses `top/left + negative margin`, leaving `transform` free for
   rotation only
 * Made the admin preview banner fully static — removed the cosmetic preferences-
   panel click handler, and the preview banner / reopen button no longer respond
   to hover or click (`pointer-events: none`). The preview is a visual reference
   only, not an interactive demo
 * Fixed a critical non-idempotency bug in the custom CSS sanitiser (`cookr_scope_css`):
   every settings save re-sanitises the _currently saved_ value (the textarea is
   repopulated with the previously-scoped output), but the selector-mirroring logic
   was not idempotent — an already-mirrored selector like `#cookr-banner .cookr-
   inner` would itself pass the #cookr-/.cookr- prefix check and get re-added on
   each save, and the `.cookr-title svg` icon-colour helper would re-fire for both
   a selector and its mirror, with both copies persisting forward. On real-world
   installs this had compounded over repeated saves into 150+ duplicate copies of
   some rules and a single selector list repeated 18 times, ballooning the saved
   CSS to 220KB. Selectors within each rule and the full set of emitted rules are
   now deduplicated (exact-string, order-preserving), making the sanitiser idempotent—
   re-saving now reproduces the same output instead of growing it. Existing bloated
   saved CSS will collapse back to its correct minimal form on the next save

#### 1.9.11

 * Fixed critical bug in custom CSS sanitiser (`cookr_scope_css`): a CSS comment
   placed directly above a rule (e.g. `/* Buttons */` followed by `.cookr-btn { ...}`)
   caused the comment text to be parsed as part of the selector, failing the #cookr-/.
   cookr-/:root prefix check and silently dropping the entire rule with no error
   shown to the admin
 * CSS comments are now stripped before selector parsing — fixes silent loss of `:
   root` accent overrides and any commented/sectioned custom CSS

#### 1.9.10

 * Added font detection for classic themes that load fonts via enqueued stylesheets(
   e.g. Kadence default installs) — previously only customizer-saved typography 
   and block-theme theme.json fonts were detected
 * New detection path parses Google Fonts and Bunny Fonts family names from registered
   stylesheets on the frontend, cached in a 6-hour transient, invalidated on theme
   switch
 * Confirmed `Update URI` header (added in 1.9.9) correctly prevents WordPress.org
   from offering false update notices on RADR installs

#### 1.9.9

 * Fixed banner close behaviour — added state-aware close button always visible 
   in banner
 * Fixed Escape key — now follows same state-aware dismiss logic as close button
 * No consent overwrite when closing with stored consent and no unsaved changes
 * Prompts before discarding unsaved preference changes (native confirm dialog)

#### 1.9.8

 * Fixed LiteSpeed Cache JS Combine compatibility — cookrConfig inline block now
   isolated to a dedicated script handle, preventing third-party inline errors from
   aborting COOKR initialisation
 * Added automatic JS exclusion filters for LiteSpeed Cache, WP Rocket, Autoptimize,
   and FlyingPress — COOKR registers itself as excluded from JS combination pipelines
   automatically
 * Updated compatibility matrix schema — added protocol, protocol_version, test_payload,
   verification_method, special_checks fields across all entries
 * Recorded first VERIFIED enforcement baseline: WordPress Core, Protocol v1.0, 
   all six test cases passed
 * Recorded LiteSpeed Cache JS Combine finding: FAIL without exclusion, PASS with
   automatic exclusion

#### 1.9.7

 * Fixed PHP notice in auto-blocker iframe rewrite handling
 * Fixed blocked-status reporting for detected domains
 * Fixed consent log rate-limit bypass edge case
 * Fixed missing policy_version storage in consent records
 * Fixed remote signature update setting persistence
 * Fixed language switcher save-state detection
 * Added full-consent buffer shortcut optimization

#### 1.9.6

 * Compliance improvements for WP.org review
 * Removed generic CDN entries from auto-blocker allowlist
 * Export uses explicit allowlist for safe settings only
 * Build tooling improvements

#### 1.9.5

 * WordPress.org review and compliance-related improvements
 * Internal maintenance and review-related updates

#### 1.9.2

 * Initial public CORE release
 * 3×3 visual position picker replaces dropdown
 * Accent colour now applies to banner icon and buttons in preview
 * Auto-Blocker wording updated — recommended framing, test-after-enable guidance
 * Runtime Inspector enabled by default
 * Preserve data on uninstall enabled by default
 * Consent log default retention reduced to 100 entries
 * COOKR CRAZE built-in CSS preset

#### 1.8.2

 * Added: Runtime Inspector — detects unknown third-party script and iframe domains
   at runtime
 * Added: Persistent findings stored per domain (first seen, last seen, page count)
 * Added: Runtime Inspector toggle with configurable auto-disable duration

#### 1.2.0

 * Added: Google Consent Mode v2
 * Added: debug inspector
 * Added: browser chrome preview in admin dashboard

#### 1.1.0

 * Plugin renamed from GDPR Cookie Consent to COOKR
 * Added: WP_HTML_Tag_Processor for safe, attribute-aware script rewriting
 * Added: CSP nonce propagation

#### 1.0.0

 * Initial release

## Meta

 *  Version **1.9.33**
 *  Last updated **1 week ago**
 *  Active installations **Fewer than 10**
 *  WordPress version ** 6.2 or higher **
 *  Tested up to **7.1.2**
 *  PHP version ** 7.4 or higher **
 *  Language
 * [English (US)](https://wordpress.org/plugins/cookr-cookie-consent-script-blocking/)
 * Tags
 * [consent](https://bcc.wordpress.org/plugins/tags/consent/)[cookie banner](https://bcc.wordpress.org/plugins/tags/cookie-banner/)
   [GDPR](https://bcc.wordpress.org/plugins/tags/gdpr/)[google consent mode](https://bcc.wordpress.org/plugins/tags/google-consent-mode/)
   [privacy](https://bcc.wordpress.org/plugins/tags/privacy/)
 *  [Advanced View](https://bcc.wordpress.org/plugins/cookr-cookie-consent-script-blocking/advanced/)

## Ratings

No reviews have been submitted yet.

[Your review](https://wordpress.org/support/plugin/cookr-cookie-consent-script-blocking/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/cookr-cookie-consent-script-blocking/reviews/)

## Contributors

 *   [ danjed ](https://profiles.wordpress.org/danjed/)

## Support

Got something to say? Need help?

 [View support forum](https://wordpress.org/support/plugin/cookr-cookie-consent-script-blocking/)