fabiodalez

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.

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

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

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.

Hi @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.

Hi @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.

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!