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
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.
Excellent! Thank you so much for getting this fixed and changed so swiftly!
