Title: fabiodalez's Replies | WordPress.org --- # fabiodalez [ ](https://wordpress.org/support/users/fabiodalez/) * [Profile](https://wordpress.org/support/users/fabiodalez/) * [Topics Started](https://wordpress.org/support/users/fabiodalez/topics/) * [Replies Created](https://wordpress.org/support/users/fabiodalez/replies/) * [Reviews Written](https://wordpress.org/support/users/fabiodalez/reviews/) * [Topics Replied To](https://wordpress.org/support/users/fabiodalez/replied-to/) * [Engagements](https://wordpress.org/support/users/fabiodalez/engagements/) * [Favorites](https://wordpress.org/support/users/fabiodalez/favorites/) Search replies: ## Forum Replies Created Viewing 15 replies - 1 through 15 (of 24 total) 1 [2](https://wordpress.org/support/users/fabiodalez/replies/page/2/?output_format=md) [→](https://wordpress.org/support/users/fabiodalez/replies/page/2/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] Feature request: add “Necessary” category to Script Blocker](https://wordpress.org/support/topic/feature-request-add-necessary-category-to-script-blocker/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 day, 1 hour ago](https://wordpress.org/support/topic/feature-request-add-necessary-category-to-script-blocker/#post-18909248) * Quick follow-up: version 1.13.17 is out now on wordpress.org and the Necessary category is in the Custom Blocking Rules dropdown. * So your GTM workflow is now this: open Settings, Script Blocker, Custom Rules, add a rule that matches googletagmanager.com (or any other always-on script you need to keep alive), and pick Necessary in the dropdown. From that point on the script loads unconditionally, regardless of consent, and the auto-scanner will not move it back into Analytics on the next run because rules you set explicitly always win over what the scanner detects. * I decided not to ship googletagmanager.com or dataLayer as Necessary out of the box. On many sites the GDPR-cautious choice is to load GTM only after the visitor accepts, and shipping it as Necessary by default would silently override that boundary for installs that did not opt in. With the dropdown change you can pick the trade-off explicitly for your site, which felt like the right line to draw. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] Bug report: dataLayer is not defined](https://wordpress.org/support/topic/bug-report-datalayer-is-not-defined/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 day, 1 hour ago](https://wordpress.org/support/topic/bug-report-datalayer-is-not-defined/#post-18909247) * Quick follow-up: version 1.13.17 is out now on wordpress.org. It carries both items we discussed. * For the dataLayer error, the plugin now creates an empty dataLayer queue very early on the page, before any other script can try to push into it. So when a GTM tag fires before consent is granted, it lands in the empty queue quietly instead of crashing the page with a ReferenceError. Once the visitor accepts and the real GTM bootstrap finally loads, it picks up the queued events normally. No configuration change needed on your side. * For the placement of the Enable Cookie Banner toggle, there is now a Banner Status card at the top of the Cookie Banner page, in the General tab, with the same switch you had under Settings. Flipping either of the two switches updates the same value, so there is no risk of them getting out of sync. The Settings entry is still there for the moment, just in case anyone has it bookmarked, but if you would rather see it removed entirely now that the more obvious placement exists, let me know and I will drop it in a follow-up release. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] Bug report: cookie categories not populated](https://wordpress.org/support/topic/bug-report-cookie-categories-not-populated/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 day, 1 hour ago](https://wordpress.org/support/topic/bug-report-cookie-categories-not-populated/#post-18909245) * Quick follow-up: version 1.13.17 is out now on wordpress.org and it carries the fix for the category counters. * After updating, every time the scanner discovers a new cookie, or you create, edit, or delete one by hand, the counters on the left side will refresh right away. Same goes for renaming or deleting a category. I also added a regression test that simulates exactly what you reported, so this specific bug now has a permanent guard against coming back in future versions. * After update I would recommend purging LiteSpeed Cache once so the new behaviour reaches your site immediately. The object cache flush is not strictly required, but does not hurt. * Once the update is in, a fresh scan plus auto-categorisation should show the correct numbers on the left straight away. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] Banner not showing – onboarding sets connected=true, breaks frontend](https://wordpress.org/support/topic/banner-not-showing-onboarding-sets-connectedtrue-breaks-frontend/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 day, 1 hour ago](https://wordpress.org/support/topic/banner-not-showing-onboarding-sets-connectedtrue-breaks-frontend/#post-18909243) * No paid plan, never! Quick follow-up to let you know that version 1.13.17 is out now on wordpress.org and it carries the two fixes I told you about. * On a fresh install of 1.13.17 those flags now stay at their safe defaults, so the banner shows up the way it is supposed to and there is no need for the workaround you put together. * On top of that, the frontend script now has a safety net: if for any reason the configuration object cannot be reached (this can happen with aggressive JavaScript- defer or page-cache setups that wrap inline scripts), it logs a console warning and exits cleanly instead of crashing the page. So even if some other plugin in the future tries to mess with the bootstrap order, the worst case is no banner with a warning in the console rather than a hard TypeError. * To update, just go to Plugins, find FAZ Cookie Manager, and click Update. If you still have the workaround in place you can safely remove it after the update. The defaults in 1.13.17 are already correct. * Thanks again for the very thorough report. Have a good one, Fabio * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] Feature request: add “Necessary” category to Script Blocker](https://wordpress.org/support/topic/feature-request-add-necessary-category-to-script-blocker/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [2 days, 3 hours ago](https://wordpress.org/support/topic/feature-request-add-necessary-category-to-script-blocker/#post-18908068) * Thanks for the framing — this was a real UX gap and you are right that the workaround of deleting GTM rows by hand is lossy because the scanner re-adds them on the next run. * Quick context on what was actually happening, because the backend was further along than the UI suggested. The settings sanitiser already accepted Necessary as a valid category for custom script-blocking rules — the eight built-in blocker templates that ship with the plugin (Cloudflare Turnstile, Gravatar, reCAPTCHA, hCaptcha, Wordfence, WPForms, Ninja Forms reCAPTCHA, WooCommerce Attribution) are stored as Necessary rules and they survive a save without issue. The hole was strictly in the admin JS that builds the dropdown for the Custom Blocking Rules table: that array hardcoded analytics, marketing, functional, performance, and Necessary was silently absent from the picker even though the backend would have persisted it. * In version 1.13.17 (out now) Necessary is in the dropdown. You can mark googletagmanager. com or any other always-on script as Necessary and it loads unconditionally regardless of consent state. The auto-scanner already respects the rule (it categorises only into the categories you have not pre-claimed via custom rules), so a rule that points googletagmanager.com at Necessary will keep being honoured across re-scans rather than being moved back into Analytics. The same applies to gtm. start and the inline GTM bootstrap once you point them at Necessary by URL pattern or handle. * I considered pre-populating googletagmanager.com, gtm.start and dataLayer as Necessary out of the box and decided against it for now — those identifiers genuinely belong in Analytics on many sites (the GDPR-cautious posture is “load GTM only after consent”), and shipping them as Necessary by default would silently override that consent boundary for installs that did not opt into it. The right move is to expose Necessary in the dropdown — which 1.13.17 does — and let each admin pick the trade-off explicitly for their site. * Best, Fabio * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] Bug report: cookie categories not populated](https://wordpress.org/support/topic/bug-report-cookie-categories-not-populated/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [2 days, 3 hours ago](https://wordpress.org/support/topic/bug-report-cookie-categories-not-populated/#post-18908050) * Thanks for the screenshot — that detail (cookies are in the right categories but the left-side counters do not refresh) made the bug locatable without needing access to your install. * What I found. In 1.13.16 the plugin listened for cache invalidation only on the legacy faz_after_update_cookie hook. When the scanner discovers new cookies it fires faz_after_create_cookie, and that hook had no subscribers in the released build. The result is the bug you are seeing: the per-category cookie list embedded in the GET /cookies/categories response is read from a cache that nothing invalidated when the scanner created the rows, so the counters on the left keep showing the pre-scan totals even though the DB underneath has the new cookies in the right category. The fact that you have LiteSpeed Cache plus its object cache made it more visible because the stale entry can be served for longer than on a stock install, but the root cause is in the plugin, not in LiteSpeed. * What is fixed in 1.13.17. The full lifecycle of cookie mutations (create, update, delete, plus the same for categories) now invalidates every consumer that depends on the cookie list: the Category controller cache, the Cookie controller cache, the banner template option cache, the IAB unmatched-vendors transient, and the page-cache adapters for LiteSpeed, WP Rocket, W3 Total Cache, WP Fastest Cache, WP Super Cache, Autoptimize, Hummingbird, Breeze, Cache Enabler, and SiteGround Optimize. I added a regression test that creates a cookie via REST and asserts the next GET /cookies/categories reports the new count — so this specific bug now has a permanent guard against it coming back. * What you need to do. Update to 1.13.17 and then purge LiteSpeed Cache once (LSCache > Toolbox > Purge All), which is the same step you already know from the other thread. The object-cache flush is not strictly required after the update because the plugin now rotates its own cache prefixes on every cookie write, but it does not hurt either. After that, a fresh scan plus auto-categorisation should give you accurate counters on the left immediately. * Best, Fabio * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] Bug report: dataLayer is not defined](https://wordpress.org/support/topic/bug-report-datalayer-is-not-defined/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [3 days, 8 hours ago](https://wordpress.org/support/topic/bug-report-datalayer-is-not-defined/#post-18906807) * Hi Patrick, Thanks for the report. You actually surfaced two distinct things! * 1) “Uncaught ReferenceError: dataLayer is not defined” at line 1508 You’re seeing this because the page contains a gtm4wp inline tag that does `dataLayer.push( dataLayer_content)` without the usual `var dataLayer = dataLayer || [];` initialiser. * The gtm4wp bootstrap that would have created `dataLayer` lives earlier in the page (lines 2-3 of your HTML) and is correctly held back by the plugin’s blocking engine as analytics — but the downstream gtm4wp push tag does not carry the same blocking attributes, so it fires immediately and throws. * This is a side effect of how gtm4wp splits its emissions, not a bug specific to your site, and it can hit any GTM/GA4 setup where the init tag and the push tag are emitted as separate scripts. I’ve just shipped a fix in the next plugin version: the FAZ inline header now pre-initialises `window.dataLayer = window. dataLayer || []` very early in , before anything else on the page can run. After the update the gtm4wp push lands in a (still empty) queue instead of crashing, and once consent is granted and the real GTM bootstrap finally runs it picks up the queued events normally. * What you need to do: - Update FAZ Cookie Manager to the new version (release on its way today/tomorrow). - Purge LiteSpeed Cache once after updating (LSCache > Purge All) so the new inline reaches your visitors. Object cache flush is not strictly required, but doesn’t hurt. No configuration change needed on your side. * 2) “Enable cookie banner” placement You’re right — having that toggle only under Settings is unintuitive. * Settings → Banner Control is a leftover from the upstream codebase this plugin was forked from, and it doesn’t match the way you’d naturally look for it. In the same release I’m adding a “Banner Status” card at the top of the Cookie Banner page (the General tab, above Design Presets) with the same toggle. It’s a live switch — flipping it writes immediately to the same `banner_control.status` option that Settings uses, so there’s only one source of truth in the database and no risk of the two getting out of sync. The Settings page entry stays put for now so existing muscle memory doesn’t break. If you’d rather see the Settings entry removed entirely once you’ve verified the new placement works for you, let me know and I’ll drop it in a follow-up release.Thanks again — this is exactly the kind of friction it’s useful to hear about.Best, Fabio * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] Banner not showing – onboarding sets connected=true, breaks frontend](https://wordpress.org/support/topic/banner-not-showing-onboarding-sets-connectedtrue-breaks-frontend/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [5 days, 12 hours ago](https://wordpress.org/support/topic/banner-not-showing-onboarding-sets-connectedtrue-breaks-frontend/#post-18904207) * Hi and4zej, * Thank you for the detailed report and for going all the way to root cause. * Your analysis is correct. The onboarding wizard was writing account.connected = true, account.plan = “ultimate”, and banner_control.alternative_asset_path = true to the database. Those values were never supposed to be written at all, since FAZ has no paid plans and no cloud connection. They are artifacts of an upstream codebase this plugin was forked from, and the onboarding wizard was mistakenly carrying them forward. When alternative_asset_path ends up as true it redirects the asset loading path to an endpoint that does not exist in this plugin, which means the inline block that defines window._fazConfig never runs, and script.js crashes on the very first line that tries to access it. * Both issues are already fixed in the development branch. The onboarding process no longer writes any of those account or banner_control values, and a null-safety guard has been added to script.js so that if _fazConfig is somehow undefined for any reason the script exits with a console warning instead of a hard crash. * The fixes will ship in the next release. * Thank you again for the thorough writeup. The suggested fixes in your report map almost exactly to what we merged. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] GTM template to use](https://wordpress.org/support/topic/gtm-template-to-use/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 week, 1 day ago](https://wordpress.org/support/topic/gtm-template-to-use/page/2/#post-18902567) * Hi [@dieterj](https://wordpress.org/support/users/dieterj/), * Glad everything is working now. That was a good debugging session! * If you have a spare minute, it would mean a lot if you left a review for FAZ Cookie Manager. * Thanks again for the patience and for sharing the details that helped track down those issues. * Fabio * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] GTM template to use](https://wordpress.org/support/topic/gtm-template-to-use/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 week, 2 days ago](https://wordpress.org/support/topic/gtm-template-to-use/page/2/#post-18901479) * Hi [@dieterj](https://wordpress.org/support/users/dieterj/), this is actually expected behavior with Consent Mode v2, and it is not a bug — let me explain the difference you are seeing compared to Complianz. * When Consent Mode v2 is active (which FAZ enables by default), GTM loads its container script on every page load, even before any consent is given. The debugger should connect as soon as the page loads. If the GTM Preview pane is not connecting at all, that usually means one of two things. * The first possibility is that the GTM container script itself is being blocked by FAZ’s script blocking feature. This can happen if you added the GTM snippet in Elementor as a direct script tag with a src pointing to googletagmanager.com, rather than using the standard inline GTM snippet. If FAZ sees googletagmanager. com as an external script src and it falls in a blocked category (analytics or marketing), it will prevent the container from loading entirely. To check: open your site in incognito, open DevTools, go to the Network tab, and filter by “ gtm.js”. If you see it blocked or missing, that is the issue. The fix is to add googletagmanager.com to your whitelist in FAZ Cookie Manager → Settings → Script Blocking → Whitelist URL Patterns. Do not worry — whitelisting googletagmanager. com does not bypass consent or set any tracking cookies. The GTM container is just a loader, it does not collect data on its own. The individual tags inside GTM (GA4, Google Ads, etc.) still respect the consent signals that FAZ sends to the dataLayer, and they will not fire until the visitor clicks Accept. * The second possibility, which is more likely, is that the GTM container is actually loading correctly but the tags inside it are in “Consent not granted” state. In GTM Preview mode, tags that are waiting for consent appear differently than tags that are blocked or not loaded at all. With Complianz, you may be used to seeing those tags fire immediately in debug mode regardless of consent, which is a different (and less strict) approach. With FAZ and proper Consent Mode v2, the container loads on every visit but individual tags like GA4 only fire after the visitor clicks Accept. In GTM Preview, you should see the tag listed with status “Consent not granted” — this means the wiring is correct and the tag will fire as soon as consent is given. * So the behavior you are describing — tags not firing until cookies are accepted— is exactly how Consent Mode v2 is supposed to work. The GTM debugger itself should still connect before any consent action. * To confirm which situation you are in: open your site in a new incognito window with GTM Preview active. Before touching the FAZ banner, check in the GTM Preview panel whether you see “Consent Initialization – All Pages” triggered and whether your GA4 tag appears (even as “Consent not granted”). If the tag appears in Preview at all, everything is working correctly. If the Preview pane does not connect at all or shows no events, then the container is being blocked and you need to whitelist googletagmanager.com as described above. * Let me know what you see and I can help you take it from there. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] GTM template to use](https://wordpress.org/support/topic/gtm-template-to-use/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 week, 2 days ago](https://wordpress.org/support/topic/gtm-template-to-use/#post-18901075) * Hi [@dieterj](https://wordpress.org/support/users/dieterj/), good news — the banner HTML is actually present in your page source, so the plugin is working correctly on the PHP side. * The issue is that it is not being initialised by JavaScript. Looking at your page source I can see you have Ad-blocker compatibility mode enabled in FAZ settings. There is a known bug in the current release that causes the banner to stay hidden when that mode is active — the JavaScript configuration object is not correctly passed through, so the banner never shows. * The immediate fix: go to FAZ Cookie Manager → Settings and turn off Ad-blocker compatibility mode. Save, then reload your site in incognito — the banner should appear. * A corrected version will be available in the next release. For now, disabling that setting is all you need. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] GTM template to use](https://wordpress.org/support/topic/gtm-template-to-use/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 week, 3 days ago](https://wordpress.org/support/topic/gtm-template-to-use/#post-18900606) * Hi [@dieterj](https://wordpress.org/support/users/dieterj/), thanks for confirming— null means the banner HTML is never reaching the page, so something is preventing FAZ from outputting it entirely. * A few quick things to check: 1. Do you have a caching plugin active (WP Rocket, LiteSpeed Cache, W3 Total Cache, or a server-level cache)? If so, please clear all cache layers and test again in incognito — a cached page served before the banner was activated would still return null. 2. Can you check the page source (right-click → View Page Source, then Ctrl+F for“ faz”)? If you see faz-consent-container in the raw HTML but not in DevTools, it’s definitely a JavaScript conflict removing the element after load. If it’s absent from the source entirely, it’s a PHP-level issue. 3. Are there any errors in DevTools → Console or Network tab when the page loads? If you’d prefer to share your site URL privately so I can take a direct look at the page source, feel free to send it here or open a private contact. * Forum: [Reviews](https://wordpress.org/support/forum/reviews/) In reply to: [[FAZ Cookie Manager] Best cookie plugin](https://wordpress.org/support/topic/best-cookie-plugin-16/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 week, 3 days ago](https://wordpress.org/support/topic/best-cookie-plugin-16/#post-18900013) * Thank you! * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] how to bypass an inline script?](https://wordpress.org/support/topic/how-to-bypass-an-inline-script/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 week, 4 days ago](https://wordpress.org/support/topic/how-to-bypass-an-inline-script/#post-18899737) * Just a quick follow-up: FAZ Cookie Manager 1.13.16 is now available in the WordPress plugin directory. * This version ships the native faz-skip class I mentioned in my previous reply. You no longer need the whitelist workaround — you can add class=”faz-skip” directly to any script tag and FAZ will leave it completely untouched. * If you want to switch, just add faz-skip to the script’s class attribute and remove it from the whitelist. Either approach works fine going forward, so there is no need to change anything if the whitelist is already working for you. * Thanks again for the patience and for helping me test this. Glad it is working! * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[FAZ Cookie Manager] GTM template to use](https://wordpress.org/support/topic/gtm-template-to-use/) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [1 week, 4 days ago](https://wordpress.org/support/topic/gtm-template-to-use/#post-18899705) * The syntax error is not a code problem on your site — it is a copy-paste issue. WordPress forum text converts straight quotes to curly/smart quotes, and the browser console rejects them. Type the command manually instead of pasting it: * document.querySelector(‘.faz-consent-container’) * But the real clue is this: no banner and no cookie at all. * That means FAZ is not injecting the banner onto your site. The most common reason: the banner has not been activated yet. * Please go to FAZ Cookie Manager, then Cookie Banner in your WordPress admin and check: 1. At the very top of the page there is a Status toggle (On/Off). Make sure it is set to On. 2. Click Save after enabling it. * Once the status is On, open your site in a fresh incognito window — the banner should appear immediately for any visitor who has no consent cookie yet. * If the status is already On and you still don’t see the banner, type this in your browser console (do not paste — type it) and share the result: * document.querySelector(‘.faz-consent-container’) * That will tell us whether the HTML is being injected at all. If it returns null, the plugin is not rendering the banner (template or caching issue). If it returns an element, the banner exists but is hidden somewhere. Viewing 15 replies - 1 through 15 (of 24 total) 1 [2](https://wordpress.org/support/users/fabiodalez/replies/page/2/?output_format=md) [→](https://wordpress.org/support/users/fabiodalez/replies/page/2/?output_format=md)