Fix: Inline scripts referencing tracker domains in config data (e.g. Rank Math) incorrectly triggered script blocking — URL-fragment patterns now matched only against the src attribute, not inline content.
Fix: faz-skip CSS class bypass used substring match, so faz-skipper would also bypass blocking. Fixed with whitespace-delimited token matching.
Fix: Unpreflixed global variables in uninstall.php renamed to $faz_* (Plugin Check compliance).
CI: Plugin Check workflow supports manual runs; root-level PNG/JPG excluded from ZIP via wildcard patterns.
1.13.15
Fix: TinyMCE editors restored for Notice/Preference Description in banner admin.
Fix: REST DELETE category was a silent no-op when the row was not loaded first; REST PUT wiped unspecified fields when starting from blank object.
Fix: Dynamic video placeholder (_fazAddPlaceholder) did not call _fazSetPlaceHolder() for non-YouTube providers.
Fix: faz_get_cookie_domain() returned malformed IP suffix for sites accessed via IP address; now returns ” (host-only cookie) per RFC 6265.
Added: 9 E2E regression tests covering all fixed areas.
1.13.14
Fix: Fatal error on WordPress Playground — maybe_create_table() was called synchronously from the ConsentLogsIncludesController constructor during plugin loading. In Playground’s WASM environment the WordPress loading order differs and wp_salt() (from pluggable.php) is not yet available at that point, causing a fatal “Call to undefined function wp_salt()”. Fixed by deferring table-creation to the plugins_loaded hook and guarding the wp_salt() call with function_exists().
1.13.13
Fix: Fatal error on fresh install — wp_salt() called without prefix inside the FazCookieAdminModulesConsentlogsIncludes namespace caused PHP to look for a non-existent namespaced function instead of the global WordPress wp_salt(). Crashed Playground, staging, and any first-time activation where maybe_create_table() runs the user-agent migration query. Three callsites fixed.
Added: WordPress Playground Live Preview on the plugin directory page — try the plugin in your browser without installing it.
1.13.12
Security: consent_revision cannot be lowered via DevTools manipulation; target_domains validates http/https scheme; necessary/uncategorized categories protected from deletion; pageview tracking endpoint gated on setting; WP-CLI export hardened against path traversal.
Fix: purge_page_caches() isolated per plugin in try/catch; faz_version bumped last in install() so failed migrations retry. Excluded-pages patterns strip query string before matching. faz_path_matches_pattern() replaces bare fnmatch().
Fix: WCA.js performance maps to statistics; advertisement back-compat alias. Croatian locale hr → hr_HR. alwaysActive toggle now has distinct blue colour.
Removed: arbitrary CSS insertion via the Banner → Custom CSS field. The textarea is gone from the admin UI, the API preview no longer renders it, and the public frontend no longer injects it. Existing values stay in the database for downgrade safety but are inert in both contexts. To customise the consent banner appearance, use Customizer → Additional CSS (a built-in WordPress feature) and target .faz-consent-container, .faz-modal, etc. — wp.org compliance (“plugins must not allow arbitrary code insertion”).
Security: $_SERVER[‘HTTP_USER_AGENT’] in faz_is_bot() now wrapped with sanitize_text_field( wp_unslash( … ) ) at the access line (was wp_unslash() only with a phpcs:ignore). Visible to static analysers.
Compliance: class-filesystem.php no longer issues define(‘FS_CHMOD_DIR’, 0755) / define(‘FS_CHMOD_FILE’, 0644) globally. WordPress core uses the same defaults internally when those constants are unset, so runtime behaviour is unchanged for any environment that doesn’t already set them.
Compliance: wp faz export (WP-CLI) now defaults to wp_upload_dir()/faz-cookie-manager/exports/faz-settings-YYYY-MM-DD.json. A bare filename argument is appended to that directory; an absolute path argument must resolve inside wp_upload_dir() or the command is rejected — no more arbitrary filesystem writes.
Compliance: frontend/class-frontend.php::start_blocking_buffer() carries an explanatory block-comment for the ob_start() callback pattern (PHP auto-flushes at shutdown, no explicit ob_end_flush() needed) and now also registers a belt-and-braces register_shutdown_function() safety-net that triggers the callback only if our handler is still on top of the buffer stack.
1.13.10
Fix: Plugin Check library_core_files ERROR on admin/assets/js/cp-api-fetch-polyfill.js resolved. The polyfill structurally re-implements wp-includes/js/dist/api-fetch.js (so Plugin Check fingerprints it as a duplicate of a WordPress core library) but is needed only on ClassicPress 1.x, where the bundled WP 4.9-era wp-api-fetch lacks createRootURLMiddleware. The wp.org-distribution ZIP now excludes the polyfill via .distignore (it ships only in the GitHub -full release ZIP for ClassicPress users); class-admin.php::deregister_api_fetch() carries a file_exists() guard so the wp.org build is a graceful no-op when the file is absent. WordPress users see no functional change — the native wp-api-fetch was already winning the dependency resolution.
Build: .distignore realigned to release.md::COMMON_EXCLUDES (added .code-review-graph/, graphify-out/, .serena/, phpstan-bootstrap.php, report.md, CLAUDE.md, cookie-banner-compliance-checklist.md, biome.json, .gitattributes, .playwright-cli/, languages/*.po~, languages/messages.mo). Prior drift between .distignore and the actual zip build flow caused dev artefacts to leak into past wp.org submissions.
1.13.9
Fix: Plugin Check WordPress.Security.EscapeOutput.OutputNotEscaped ERROR on admin/class-admin.php:462 resolved. The ClassicPress wp.apiFetch polyfill is no longer echoed as <script>$polyfill</script> in admin_head; it now ships as a static file (admin/assets/js/cp-api-fetch-polyfill.js) registered against the wp-api-fetch handle, with the REST URL + nonce passed via wp_localize_script() as fazApiFetchConfig. Same behaviour, zero inline echo, browser-cacheable.
New: automatic page-cache invalidation on every plugin upgrade. Activator::install() now fires Activator::purge_page_caches() right after the version bump so visitors immediately see the up-to-date _fazConfig localize block — no more manual “purge LiteSpeed / Bunny / WP Rocket” step after each FAZ update. Best-effort detection across LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, Cache Enabler, SG Optimizer, Hummingbird, Breeze (Cloudways), Autoptimize, WP-Optimize, and Comet Cache. CDN edges (Cloudflare, Bunny, KeyCDN) still need a manual purge — those need API credentials we do not own.
1.13.8
Fix (#87): Bricks Builder Video element placeholder no longer collapses. The iframe inside .brxe-video (with aspect-ratio: 16/9 + no explicit width/height) gets a consent CTA injected synchronously, even when its offsetWidth is still 0 at MutationObserver time.
Fix (#87): Bricks Container Video Lightbox click — capture-phase document-level click interceptor catches <a class=”bricks-lightbox” data-pswp-video-url=”…”> (plus Elementor Pro / Divi equivalents) and prevents the modal from opening when the video host is gated behind unconsented categories. A placeholder is injected inline.
Fix (#87): consent banner no longer paints over the Bricks visual editor — faz_disable_banner() recognises ?bricks=run, ?bricks_preview, ?_bricksmode, and the Bricks helper functions.
1.13.7
Fix (#85): GVL update no longer triggers a fatal Call to undefined function FazCookie…wp_tempnam() on the REST endpoint. Lazy-load wp-admin/includes/file.php and call wp_tempnam() from the global namespace.
Fix (#87): Bricks Builder Video element placeholder CSS — removed min-height: 0 from .faz-placeholder–video, scoped min-width: min(280px, 100%) to the video variant only.
Fix (Gooloo regression): Gravatar recategorised from functional to necessary so visitor-rejected functional consent no longer replaces every wpDiscuz / Disqus / WP-core comment avatar with a 200-px-tall placeholder. As defence in depth, wpdiscuz_nonce_* and comment_author_* added to the is_wp_internal_cookie() allowlist.
wp.org compliance pass ahead of plugin directory submission: $_COOKIE sanitization visible at access-line, load_plugin_textdomain() documented no-op (auto since WP 4.6), 4× __($variable, …) calls replaced with verbatim returns, 8 of 10 inline <script>/<style> migrated to wp_enqueue_* / wp_add_inline_* (3 residuals carry phpcs:ignore + technical justification), _faz_first_time_install site-transient renamed to faz_first_time_install with migration, three public REST routes carry explanatory block-comments documenting the HMAC-token + rate-limit security model.
1.13.6
New: blocker-template parity with the runtime detection layer. Every provider already auto-detected by Known_Providers (143 of them — Google Analytics, Adobe, Plausible, Microsoft Clarity, Mixpanel, Segment, Stripe, Mailchimp, Klaviyo, HubSpot, Pinterest, Snapchat, Reddit, Quora, Outbrain, Taboola, Yandex Metrica, Baidu Analytics, etc.) now appears in WP Admin → FAZ Cookie Manager → Cookies → “Add from template”. Previously only 11 templates were exposed in the admin picker; the runtime always blocked them all, but admins couldn’t see them in the picker. Discovery-friendly without changing the privacy contract.
Internal: 131 generated blocker-template JSONs auto-derived from includes/data/known-providers.json (single source of truth). Each template inherits the provider’s label, category, patterns, and cookies.
1.13.5
New: Matomo (formerly Piwik) is now available as a blocker template in Cookies → Blocker Templates. Covers self-hosted and Matomo Cloud, including Matomo Tag Manager, the matomo.js / piwik.js trackers, the matomo.php / piwik.php tracking endpoint, and all _pk_*, MATOMO_SESSID, and mtm_consent* cookies. Requested by a user on the back of a successful 1.13.4 install.
1.13.4
Fix: wp_localize_script payloads ({handle}-js-extra) and translation tags ({handle}-js-translations) for FAZ scripts now also carry the 5 cache opt-out attributes. Those inline tags do not travel through script_loader_tag so the 1.13.1 / 1.13.2 / 1.13.3 attribute injection missed them, and a delay-aware optimizer (LiteSpeed Guest Mode in particular) re-typed them to litespeed/javascript. Added a hook on wp_inline_script_attributes (WP 5.7+) that recognises our handle prefix and injects the same 5 hints.
1.13.3
Fix: banner invisible on first paint when LiteSpeed Cache “Delay JS” had a hand-added entry mentioning faz-cookie-manager without the full wp-content/plugins/… prefix. The 1.13.2 path-anchored scrubber was strict-anchored and skipped those entries; 1.13.3 also matches faz-cookie-manager as a complete token, while still leaving third-party companion names like my-integration-faz-cookie-manager-compat.js untouched. Reported by gooloo.de.
1.13.2
Fix: GDPR Strict preset “Customize” button unreadable (light-blue text on dark-blue background) — classic template CSS hardcoded color: #1863dc instead of reading the preset’s –faz-settings-button-color variable.
Fix: consent banner invisible on LiteSpeed Guest Mode installs — added the missing litespeed_optm_gm_js_exc filter so Guest Mode’s separate JS exclude list also recognises our scripts.
Fix: alt-asset mode (faz-fw alias) children (faz-fw-gcm, faz-fw-tcf-cmp, faz-fw-a11y) now correctly tagged with the cache-plugin opt-out attributes.
Fix: litespeed_optm_js_delay_inc scrubbing now path-anchored (plugins/faz-cookie-manager/) so third-party integration entries are never collaterally removed.
New: faz_auto_exclude_cache_plugins filter for admins who want to disable the automatic cache-plugin exclusion block.
1.13.1
New: auto-exclude FAZ scripts from cache/optimization plugins’ Delay JS. Every FAZ <script> now carries data-no-defer, data-no-optimize, data-no-minify, data-cfasync=”false” and data-ao-skip, and the matching pattern-based exclude filters are hooked for LiteSpeed Cache, WP Rocket, Autoptimize, SG Optimizer, Hummingbird, Cloudflare Rocket Loader and W3 Total Cache. Fixes the “banner only appears on second tap” reports from publishers using those plugins.
1.13.0
Fix: per-service consent cookie stays under the browser’s 4 KB limit (issue #80). Previously a ~160-service install dropped every “Save My Preferences” click because the oversized cookie write was silently discarded.
Fix: scanner discover_urls places recently-modified pages in the priority bucket (issue #78) so freshly-edited posts aren’t skipped by the client-side early-stop threshold.
Fix: server-side cookie shredder honours the frontend whitelist on every request, not just the first page load.
Fix: whitelist pattern match is unidirectional with a 3-character minimum guard — entering “js” or “com” no longer whitelists nearly every provider.
Fix: preference center focus-retry timers cancelled on close (no more focus theft after rapid open/close).
Fix: dynamic scripts preserve their original type attribute (module, etc.) through the block/unblock round-trip.
1.12.1
Fix: LiteSpeed Cache cookies (_lscache_vary, _litespeed_*) added to the internal whitelist so they’re not shredded by the server-side cookie cleanup.
1.12.0
Security audit: closed all findings from a 20-agent code audit (H2-H5, M1-M28).
data: URI blocking — decoded payload matched against provider patterns on both PHP and JS sides.
Uppercase HTML tag handling in output buffer guards (strpos → stripos).
Consent logging: throttle fix for empty consent_id, URL credential stripping, UA hashing.
Fix: preference center invisible on dark design presets — all 5 presets now include full modal color palettes (background, text, buttons, toggle states).
Fix: TypeError crash on ChromeOS and PMP-exempt members — null guard in _fazRenderBanner() prevents crash when the banner template element is absent.
Fix: applyDesignPreset() deep-replaces preference center and optout popup config — the old cherry-pick missed toggle states.
Fix: const → var in WP Consent API inline script for broader browser compatibility.
Fix: removed #000000 → transparent skip in template CSS — High Contrast preset buttons now render as intended black.
1.11.1
Critical fix: banner reappearing on every page load — the consent cookie was written without URL-encoding, so the re-read couldn’t extract rev and the stale-check wiped the cookie every time. URL-encode on write, two-pass decode on read. Reported by a live publisher running 1.11.0.
Critical fix: PMP exempt_levels setting didn’t persist — the settings sanitizer coerced the CSV input to an empty array before the per-key handler could parse it. Without this fix the entire Paid Memberships Pro integration was silently non-functional.
Fix: Non-personalized ads fallback also forces ad_user_data / ad_personalization to denied in the region-default code path, aligning with the post-“reject all” state.
Fix: PMP auto-grant cookie now writes consent:yes (the token script.js::_fazUnblock() gates on) instead of consent:accepted, so exempt members get their scripts actually unblocked client-side.
Fix: setAdditionalConsent(null) no longer fires during the stale-revision window — would otherwise clobber the live GACM provider list.
Fix: Settings page race condition between loadSettings() and invalidateConsents() — bumped revision is no longer reverted by a late-arriving GET.
Fix: wca.js and microsoft-consent.js requested .min.js files that don’t exist on the installation, 404’ing the WP Consent API and Microsoft UET/Clarity integrations. Suffix is now computed per-file.
Fix: PMP auto-grant cookie filters internal/admin categories (wordpress-internal, invisible ones) so they don’t leak into a visitor’s consent record.
Fix: changelog wording on NPA fallback clarified — ad_storage = granted still allows advertising identifiers for frequency capping/fraud detection; what NPA removes is profiling and ad-user-data signals.
Refactor: faz_get_cookie_domain() is now the single source of truth; Frontend::get_cookie_domain() delegates. No more TLD-list drift between server-side writes and client-side localization.
1.11.0
New: Non-personalized ads fallback for Google Consent Mode (GCM → Advanced). When a visitor denies marketing consent, keep ad_storage = granted while forcing ad_user_data and ad_personalization to denied — the Google-sanctioned configuration for serving non-personalized ads to visitors who reject the banner. Publishers still earn revenue on those pageviews. Disabled by default; admins enable it explicitly.
New: Force re-consent (Settings → Force re-consent). “Invalidate all consents” button bumps a server-side revision counter; returning visitors whose stored cookie carries a lower revision see the banner again on their next visit. Useful after adding new ad/analytics services or tightening your cookie policy.
New: Paid Memberships Pro integration (Settings → Paid Memberships Pro integration, visible only when PMP is active). Select comma-separated level IDs whose members are exempted from the banner and auto-granted consent across all categories — the “Pay-or-Accept” (PUR) model. Non-paying visitors are unaffected. No-op when PMP is not installed.
Fix: GCM race condition on revisit — returning visitors with a saved consent cookie now see gtag(“consent”, “default”, …) emitted directly with their granted states, removing the brief denied→granted window during which AdSense/GTM could fire the first request with ads blocked.
Fix: wait_for_update default aligned between admin UI (500 ms) and PHP defaults (previously 2000 ms) — the UI number now matches what new installations actually use.
1.10.2
Fix: preference center text colour on sites with a dark theme (follow-up to #57). The 1.10.1 fix for the transparent background exposed a pre-existing issue: several rules inside the preference center used color: inherit, which on dark-theme host sites inherited a light text colour from body, producing unreadable “light on white” text. Locked the text colour to var(–faz-detail-color, #212121) on the preference center, preference, header, footer wrapper, body wrapper and description paragraphs. The default is dark regardless of host theme, and users can still override the colour from the banner editor because the CSS variable is fed from the stored banner config.
Test: new E2E regression that injects a dark-theme stylesheet on the host site, opens the preference center, and asserts every text-bearing element inherits the locked-down dark colour instead of the injected light one.
1.10.1
Fix: preference center transparent background on classic (full-width + pushdown) banner type. The .faz-preference-center CSS used background-color: inherit which left the modal visually empty when the classic template was active, because that template wraps the preference center in .faz-preference-wrapper (not .faz-modal) and no ancestor provided a colour. Replaced with background-color: var(–faz-detail-background-color, #ffffff) so the default is always a solid background, regardless of template variant. Reported as issue #57.
Test: new E2E regression that switches the banner to classic + pushdown, opens the preference center, and asserts the computed background-color of .faz-preference-center is not transparent.
1.10.0
New: German (de_DE) translation — covers [faz_cookie_policy], [faz_cookie_table], cookie category names and common banner labels. Fixes a gooloo.de user report where the Cookie Policy shortcode stayed in English on a de_DE site because no de_DE .mo file was bundled.
New: WordPress.org submission assets — 10 publish-ready screenshots, PUBLISHING-GUIDE.md with the full submission/SVN workflow, Playwright capture script.
New: FAQ entries on telemetry (“Does the plugin send any data home?”), minified JS source (“Where is the source of the bundled minified JavaScript?”) and data removal on uninstall.
Fix: Cookie definitions metadata normalization — legacy installs upgrading from < 1.9 no longer send the UI down the wrong “downloaded vs bundled” branch.
Fix: META_KEY now stored with autoload=false, keeping metadata out of the autoload bucket.
Fix: importFailed i18n string now contains %s so the actual error detail is surfaced instead of being swallowed by String.replace.
Fix: GVL REST API error message “vendor_ids must be an array.” is now translatable.
Fix: JS i18n payload uses () instead of esc_html() so HTML entities no longer leak into the UI.
Test: New E2E regression for the gooloo.de scenario — sets WPLANG=de_DE, creates a page with [faz_cookie_policy], asserts German strings render and English fallbacks do not.
1.9.2
Fix: Settings API no longer re-injects default language into selected list on every read
1.9.1
Fix: Default language now uses WordPress site locale instead of hardcoded English
Fix: Theme link colors (Divi, Elementor) no longer override banner button colors
