← Back to changelog

GTM Kit 2.23: the settings screen tells you when your browser cannot reach your site

Free

GTM Kit 2.23.0 makes one kind of problem visible: a settings screen that cannot save because something between your browser and your site blocks the request. Before, the save simply did not happen and nothing said why. The release also updates a warning in GTM Kit Premium’s event deferral setting.

What changed

A notice when your browser cannot reach your site’s settings API

GTM Kit’s settings screen saves through your site’s REST API. A browser extension, an ad blocker, a VPN, or a firewall or security service in front of your site can block those requests from one browser while the site itself works fine. Site Health cannot catch this: its check runs from your server to itself, not from your browser.

When the settings screen opens, GTM Kit now sends one check to your own site’s settings API and shows a notice when:

  • Your site has not answered after 10 seconds. An amber notice says the site has not answered yet. It disappears if the site then answers normally.
  • Your browser could not reach the API, or no answer came within 30 seconds. A red notice says saving settings and activating your licence will not work from this browser, and names the usual causes.
  • Your site answered with an error, such as the HTTP 403 that security plugins and firewalls often return for blocked requests. The notice shows the status code.
  • WordPress did not accept your login. GTM Kit first retries with a fresh security token, so an expired one on a tab left open does not trigger this. If WordPress still refuses, the notice says your changes will not be saved and asks you to reload and log in again. If it comes back after you have logged in, a cache or proxy in front of your site may be removing cookies from requests to the WordPress REST API.
  • WordPress refused the request for your account. Your account does not have permission to change GTM Kit settings on this site. On a multisite network, ask a network administrator. If you are an administrator of the site, a proxy in front of it may be removing the request headers WordPress uses to recognise your login.

Each notice has Check again. The red notices also have Copy details for support, which copies the result, the status, the error code, the time it took, your REST URL, the GTM Kit version and your browser’s user agent. Paste that into a support ticket and we can usually tell the cause from it.

If you see the red notice, try a private window with extensions turned off, or another network. If that works, an extension or the network was blocking the request.

The check talks only to your own site and sends nothing anywhere else. When everything works, you see nothing.

Event deferral warning names the fixes that work (GTM Kit Premium)

When the event deferral setting in GTM Kit Premium cannot see a consent state on your site, it warns that the selected events will wait the full timeout on every page. The warning now names the two fixes that work with a consent banner running inside Google Tag Manager: add the GTM Kit consent bridge tag to your container, or use a consent plugin that supports the WP Consent API. It no longer suggests turning on Consent Mode, which does not fix this case.

Upgrade notes

  • Nothing changes on update. The notice appears only when the check fails or is slow.
  • The setup wizard does not run the check yet.