GTM4WP 2.0.2 is out
GTM4WP 2.0.2 fixes Google Tag Manager tracking on WooCommerce block stores: add to cart and checkout events, category names, item_id, plus a PublishPress error.
GTM4WP 2.0.2 is out on wordpress.org. It is a bugfix release for the 2.0 line with six fixes, most of them for WooCommerce stores built on the newer block editor features, all described below. The update reaches your dashboard a few hours after the release, because wordpress.org now runs an automated security review on every plugin release before it is offered as a one-click update; if you do not want to wait, you can download it from the plugin page right away. The complete list of changes is in the GTM4WP 2.0.2 changelog.
Add to cart events on stores built on the Interactivity API
WooCommerce is moving its blocks to the WordPress Interactivity API, and on a store whose product and cart blocks are already built that way, GTM4WP never fired add_to_cart or remove_from_cart. There were two separate causes. On a product page WooCommerce renders the Add to Cart + Options block without the class it puts on the classic product form, and the plugin looked for exactly that class before reading the product data, so a click on the button was never reported. Elsewhere those blocks keep the cart in a private store the plugin must not read, so the tracker had nothing to compare between one cart state and the next.
Both are fixed. The product page now reports the add once WooCommerce confirms that the item really reached the cart, so an add that WooCommerce refuses, for example because the item is out of stock, still reports nothing. On the other pages the plugin reads the cart back from the WooCommerce Store API whenever WooCommerce announces that it changed and reports the difference, the same way it does on a store using the older blocks. A variable product added from such a page is covered as well. Thank you to malenelussand for the detailed report in the support forum.
begin_checkout on stores that report the checkout as a cart page
WooCommerce decides whether the current page is the cart page from several sources, so a plugin or a theme that defines WOOCOMMERCE_CART or answers the woocommerce_is_cart filter while the checkout renders, or a cart shortcode left in the checkout page content, makes WooCommerce report the checkout page as the cart page too. GTM4WP asked the cart question first, so on such a store the checkout page pushed view_cart and begin_checkout never fired anywhere, while the part of the plugin that runs in the browser treated the very same page as the checkout. Both halves of the plugin now decide the checkout first, and the order confirmation page ahead of both, so they can no longer disagree about the page they are on. Thank you to rarcher30 for sticking with the forum thread until the cause was found.
Category and brand names with an ampersand
A product category or brand called “Shirts & Ties” reached the data layer as “Shirts & Ties”, and that is the literal text GA4 reported. WordPress encodes a term name when it is saved, and the plugin passed on what it read back. The name is now decoded once, at the point it is read, and still reaches the page through the same JSON encoder as before, so nothing changes about how the script is escaped. If you built a GTM trigger or a GA4 filter against the encoded form, it needs the plain name from now on.
item_id and sku are strings on every product
A product without a SKU falls back to its numeric product ID as its item_id, and that fallback was written into the data layer as a number, while the same field is a string on every product that has a SKU. A Google Tag Manager trigger or variable comparing item_id could not be written for both cases at once. The item_id, sku and the dynamic remarketing id fields are now always strings, which completes the change 2.0 started when it stopped turning identifiers into numbers. Check your GTM setup if a trigger or a variable compares one of these fields against a number on products without a SKU.
A trailing newline in a wp-config constant
A GTM4WP_HARDCODED_* value in wp-config.php that ends in a newline character, typically the result of an untrimmed file read feeding the define(), passed validation. For the gtm_auth and gtm_preview values the newline then reached the container loader script and broke the whole block, so the container silently did not load and nothing pointed at wp-config as the cause. Such a value is now rejected and named in the existing admin notice, like any other malformed value. A container ID with a trailing newline used to be silently repaired; it is reported the same way now, so remove the stray newline from the define() and the override applies again.
No more critical error with PublishPress Authors on a page without an author
With PublishPress Authors active, a page whose author cannot be resolved, which happens when the author’s user account has been deleted, took the whole page down with a critical error. PublishPress reports such an author as no author at all, and the plugin passed that straight into the code reading the author name and ID. The WooCommerce My Account page is the one most likely to hit it, since it is often the page nobody keeps an author on. An author that cannot be resolved is now skipped, so the page renders and the author variables are simply left out of the data layer. Thank you to Saif for the report with the exact steps to reproduce it.
This release is also tested with WooCommerce 11.1. Please report problems in the support forum on wordpress.org or on GitHub.
