Conversation
supportContext: Following the dataLayer is not defined fix in the latest release — great work, that resolved the GTM initialization issue. However there’s a related UX problem that still needs addressing: the Script Blocker auto-scanner detects GTM-related scripts and assigns them to Analytics or Marketing. Since there’s no Necessary option in the dropdown, admins have no way to permanently protect these scripts from being blocked. Removing them manually doesn’t help — the scanner adds them back on the next run. Request: Add Necessary as a selectable category in the Script Blocker dropdown. Scripts marked Necessary load unconditionally and the scanner leaves them alone. This would also make a sensible default — pre-populate googletagmanager.com , gtm.start , and dataLayer as Necessary out of the box. The page I need help with: [ log in to see the link]
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
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.
Thank you Soooo much. You’re doing incredebly good job @fabiodalez !
Thank you so much! I’m glad the new workflow solves your problem. If you have a minute and you feel the plugin deserves it, I’d also really appreciate a review on WordPress.org — it helps a lot for visibility and keeps the project alive and maintained. Thanks again for the support
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
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.
Thank you Soooo much. You’re doing incredebly good job @fabiodalez !
Thank you so much! I’m glad the new workflow solves your problem. If you have a minute and you feel the plugin deserves it, I’d also really appreciate a review on WordPress.org — it helps a lot for visibility and keeps the project alive and maintained. Thanks again for the support