Your GTM tracking worked perfectly last week. Now GA4 shows zero purchases. You haven’t changed anything—or so you thought. WooCommerce updated, and with it, your entire checkout architecture shifted from PHP templates to React-based Blocks. Your GTM plugin never saw it coming.

WooCommerce Blocks checkout is now the default for all new WooCommerce installations, and stores on auto-update are being migrated silently. GTM4WP, with over 2 million active installations, depends on PHP hooks that Blocks simply doesn’t trigger. The result: conversion tracking dies without a single error message to explain why.

What WooCommerce Blocks Actually Changed

WooCommerce introduced Blocks as an alternative checkout experience several versions ago. With WooCommerce 8.3+, Blocks became the default for new installations. The classic [woocommerce_checkout] shortcode still works, but WooCommerce is clearly moving away from it.

Here’s why this matters for tracking: classic WooCommerce checkout renders via PHP templates. Blocks checkout renders via React and JavaScript.

That architectural difference breaks everything GTM plugins assume about how WooCommerce works.

The PHP Hook Dependency Problem

GTM plugins like GTM4WP and GTM Kit work by hooking into WooCommerce’s PHP actions. When a customer completes checkout, WooCommerce fires hooks like woocommerce_thankyou and woocommerce_payment_complete. These hooks trigger on the server side, and GTM plugins use them to push purchase data to the dataLayer.

But here’s the twist: Blocks checkout uses a different rendering system. The cart and checkout widgets are JavaScript-based React components. When you add a product to cart from a Block widget, or when checkout validation happens, the frontend behavior doesn’t necessarily trigger the same server-side hooks in the same sequence.

The classic checkout page loaded PHP templates that GTM plugins could intercept. Blocks loads JavaScript components that execute in the browser—a fundamentally different execution environment.

You may be interested in: GTM4WP Purchase Event Not Firing: Your Elementor Thank-You Page Is the Problem

How to Know If Blocks Is Breaking Your Tracking

Before assuming Blocks is your problem, confirm it actually is:

Step 1: Check your checkout page. Edit your checkout page in WordPress. If you see the Checkout block from the Gutenberg editor, you’re using Blocks. If you see [woocommerce_checkout] as a shortcode, you’re on classic.

Step 2: Check your WooCommerce version. WooCommerce 8.3+ defaults to Blocks for new pages. If you updated recently and your checkout page was recreated or modified, you may have switched without realizing.

Step 3: Test with GTM Preview Mode. Open GTM Preview, complete a test purchase, and watch for the purchase event. If it fires on classic checkout but not on Blocks checkout, you’ve found your culprit.

Step 4: Check plugin changelogs. GTM Kit documented Blocks-specific fixes in versions 1.15 through 1.18. GTM4WP support forums show users reporting “Events not working with New WooCommerce Blocks” throughout 2025. If you’re running older plugin versions, updating may resolve compatibility issues.

The Specific Events That Break

Not all tracking breaks equally. Here’s what typically fails with Blocks:

Add to cart events from Block widgets: The AJAX add-to-cart in Block product grids uses different event structures than classic add-to-cart buttons. Plugins expecting the standard WooCommerce AJAX response may miss these entirely.

Checkout step events: Blocks checkout doesn’t trigger checkout step hooks the same way. If your funnel tracking depends on detecting when users enter shipping or payment steps, those events may disappear.

Purchase completion: The most critical event—and often the one that breaks. The thank-you page rendering changed, and if your plugin expects the classic thank-you template to load, it may not fire the purchase dataLayer push correctly.

Payment gateway redirects: Blocks handles payment gateway redirects differently than classic checkout. If your payment gateway takes customers off-site and back, the return handling may not trigger expected hooks.

Short-Term Fixes

If you need tracking working today, here are your options:

Option 1: Revert to Classic Checkout

Create a new checkout page with the classic [woocommerce_checkout] shortcode. Set it as your checkout page in WooCommerce settings. This bypasses Blocks entirely and restores the PHP template rendering your GTM plugin expects.

This works, but it’s a temporary solution. WooCommerce is clearly moving toward Blocks as the default, and the classic shortcode may eventually be deprecated.

Option 2: Update Your GTM Plugin

GTM Kit has been patching Blocks compatibility since version 1.15. GTM4WP has also been releasing updates. Ensure you’re running the latest versions of both your GTM plugin and WooCommerce.

Check the plugin changelogs specifically for Blocks-related fixes. If the changelog mentions “WooCommerce Blocks,” “block cart,” or “block checkout,” those updates address exactly this problem.

Option 3: Use Blocks-Native Tracking Solutions

Some newer tracking plugins are built specifically for Blocks compatibility. The Datalayer for WooCommerce plugin, for example, claims Blocks compatibility—though it’s a paid solution.

You may be interested in: Why Your WooCommerce Analytics Show Zero Conversions

The Long-Term Solution: Tracking That Doesn’t Depend on Frontend Architecture

Here’s the fundamental problem: GTM plugins depend on JavaScript executing correctly in browsers. They depend on specific HTML templates loading. They depend on frontend rendering architecture behaving as expected.

Every time WooCommerce changes that architecture—Blocks today, something else tomorrow—tracking breaks.

Server-side tracking eliminates this dependency entirely. Instead of pushing data to a browser-based dataLayer, server-side tracking captures events at the WooCommerce PHP action level. When woocommerce_payment_complete fires, the event gets captured server-side—regardless of whether the frontend uses Blocks, classic templates, a custom theme, or a page builder that overrides everything.

Transmute Engine™ is a first-party Node.js server that runs on your subdomain. The inPIPE WordPress plugin captures events from WooCommerce hooks and sends them via API to your Transmute Engine server, which routes them to GA4, Facebook CAPI, and other platforms. The frontend can render however it wants—Blocks, React, classic PHP—the server-side events still fire.

This isn’t just about Blocks compatibility. It’s about building tracking infrastructure that doesn’t break every time a platform updates its frontend architecture.

Key Takeaways

• WooCommerce Blocks is the new default checkout—stores on auto-update are switching without notification
• Blocks uses React/JavaScript rendering instead of PHP templates, breaking GTM plugin assumptions
• GTM4WP (2M+ installations) and GTM Kit both have documented Blocks compatibility issues
• Short-term fix: revert to classic checkout shortcode or update to latest plugin versions
• Long-term fix: server-side tracking captures events at PHP action level regardless of frontend

Stop waiting for WooCommerce to break your tracking again. Learn how Seresa’s server-side tracking captures every conversion, regardless of frontend architecture changes.