GTM Kit 2.10: Strong-block consent, CMP attribute toggles, and a real consent API

GTM Kit 2.10 finishes the consent groundwork started in 2.8 and 2.9. Three things land in this release: a way to actually hold the GTM container back until consent arrives, one-click toggles for the CMPs that block scripts by attribute, and a proper PHP and JS surface for partner plugins to plug into GTM Kit’s consent flow.

A new “Script gating” mode on the Consent settings page gives you three choices:

  1. Always load (existing behavior, default for upgrades and new installs).
  2. Weak block. GTM loads, but events are deferred via Google Consent Mode v2 until consent updates arrive.
  3. Strong block. GTM does not execute at all until a consent signal is received.

Strong-block mode masks the GTM container script with type="text/plain" and rewrites it to text/javascript once consent comes in. It works alongside any CMP and falls back gracefully when no consent signal ever arrives. This is the same pattern Stape ships, but with a three-way selector instead of an on/off checkbox so you can pick the level that matches your legal posture without giving up Consent Mode.

Power users can override which Consent Mode v2 categories are required to unmask GTM via a new filter:

add_filter( 'gtmkit_strong_block_required_categories', function ( $categories ) {
    return [ 'analytics_storage' ]; // unmask on analytics consent alone
} );

The default is analytics_storage and ad_storage, matching the GDPR baseline.

CMP script attributes: one click for Cookiebot, Iubenda, CookieYes

A new “CMP script attributes” section on the Consent settings page lets you toggle the script-blocking attributes that the major CMPs look for:

  • Cookiebot (data-cookieconsent="ignore")
  • Iubenda (data-cmp-ab="1")
  • CookieYes (data-cookie-consent="ignore")

There is also a free-form custom attribute field for any CMP that uses its own marker. No PHP filters required.

Fresh installs auto-detect a known CMP plugin and pre-select the matching toggle. Existing installs keep the Cookiebot attribute on by default, since that is what GTM Kit shipped before this release. If you do not use Cookiebot, turn it off explicitly.

Cookie Information is intentionally not in the list. Their attribute is a block-by-category marker, the opposite of a do-not-block marker. Cookie Information users should use Strong-block mode or the Custom attribute field for now. We will revisit if Cookie Information ships an ignore-style attribute.

GTM Kit 2.10 exposes the consent flow as something other plugins can plug into without forking. Three hooks land on the PHP side:

// Register your own consent signal source (CMP, WP Consent API, custom code).
add_filter( 'gtmkit_consent_signal_sources', function ( $sources ) {
    $sources[] = new My_CMP_Signal_Source();
    return $sources;
} );

// React to any consent state change, server-side.
do_action( 'gtmkit_consent_updated', $new_state, $previous_state, $source );

// Decide whether a single event should be deferred.
add_filter( 'gtmkit_event_should_defer', function ( $defer, $event_name, $payload, $consent ) {
    if ( $event_name === 'purchase' && empty( $consent['ad_storage'] ) ) {
        return true;
    }
    return $defer;
}, 10, 4 );

There is also a new gtmkit_consent_admin_badges filter that lets add-ons push status banners onto the Consent settings page, so when a higher-priority consent source takes over (for example the WP Consent API plugin), users see it immediately.

On the JavaScript side, window.gtmkit.consent.state now exposes the current consent state directly, so partner scripts can inspect it without subscribing to events first.

These hooks are what the upcoming Premium WP Consent API integration is built on. They are stable, documented in docs/consent-api.md and docs/filters.md, and meant for third-party use.

Heads-up for filter authors

If your code listens on gtmkit_consent_default_state, note one behavior change: the filter now only fires when GTM Kit’s master Consent Mode toggle is on. Previously it could fire even when the master toggle was off, which led to surprising defaults on installs that intentionally delegate consent to their CMP. Most callers will not notice, but if you depend on the old behavior, gate your code on the master toggle yourself.

Other changes in 2.10

Bug fix. WordPress 6.9.1+ stopped logging the “dependencies that are not registered: gtmkit-container” warning that some users were seeing on installs with the GTM container active.

Migration. Upgraders run a one-time v210_upgrade that pre-selects the Cookiebot script attribute (preserving 2.9 behavior) and migrates existing consent settings into the new shape. No action needed.

Get GTM Kit 2.10

Update from your WordPress dashboard, or download from WordPress.org. Full changelog at gtmkit.com/changelog.

Posted in #

GTM Kit Avatar

Leave a Reply

Your email address will not be published. Required fields are marked *