Status: Open. #427 = Add and Remove events for wooCommerce Blocks#428
Open
zamartz wants to merge 2 commits intoduracelltomi:masterfrom
Open
Status: Open. #427 = Add and Remove events for wooCommerce Blocks#428zamartz wants to merge 2 commits intoduracelltomi:masterfrom
zamartz wants to merge 2 commits intoduracelltomi:masterfrom
Conversation
…e Blocks - Adds a dedicated WooCommerce Blocks cart-tracking option that listens to Block DOM events, fetches the current cart via the Store API, and emits GA4-friendly add/remove events for simple, variable, grouped, and mini-cart interactions. - Supplies a custom REST/AJAX product endpoint so the frontend can enrich every cart item (categories, brand, stock, item_type, SKU-based item_group_id, etc.) exactly like the legacy integration. - Replaces the legacy inline add-to-cart tracking whenever the Blocks option is enabled, preventing page reloads and double-event issues while maintaining the same GA4 dataLayer payload structure. - New option scope: note that the Blocks cart tracking only runs when both “Track e-commerce” and the new toggle are enabled, and that it intentionally disables the legacy add-to-cart markup. Reviewers will want to know this is guarded and opt-in. - Endpoints/security: mention the new REST route /gtm4wp/v1/product/<id> (read-only, no auth) plus its AJAX fallback gtm4wp_product_data, and that both rely on the existing GA4 product-formatter. Helps security reviewers assess exposure. - Caching/perf considerations: highlight the 300 ms Store API fetch cache, client-side product detail caching, and the sessionStorage warm-start. Also note the fallback behavior when storage or REST isn’t available. - Edge cases covered: call out support for variations, grouped parents, mini-cart increments, DOM/store dedupe, and the defensive parsing for custom cart structures. - Testing done: list the scenarios you validated (PDP add, variable products, grouped adds, mini-cart +/- add/remove, cart page quantity changes, Store API failure, sessionStorage disabled). -Potential follow-ups: optional mention that we rely on Woo Blocks scripts/Store API; if either is missing, we no-op but log a warning—so theme compatibility hinges on those assets being present.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a dedicated WooCommerce Blocks cart-tracking option that listens to Block DOM events, fetches the current cart via the Store API, and emits GA4-friendly add/remove events for simple, variable, grouped, and mini-cart interactions.
Supplies a custom REST/AJAX product endpoint so the frontend can enrich every cart item (categories, brand, stock, item_type, SKU-based item_group_id, etc.) exactly like the legacy integration.
Replaces the legacy inline add-to-cart tracking whenever the Blocks option is enabled, preventing page reloads and double-event issues while maintaining the same GA4 dataLayer payload structure.
New option scope: note that the Blocks cart tracking only runs when both “Track e-commerce” and the new toggle are enabled, and that it intentionally disables the legacy add-to-cart markup. Reviewers will want to know this is guarded and opt-in.
Endpoints/security: mention the new REST route /gtm4wp/v1/product/ (read-only, no auth) plus its AJAX fallback gtm4wp_product_data, and that both rely on the existing GA4 product-formatter. Helps security reviewers assess exposure.
Caching/perf considerations: highlight the 300 ms Store API fetch cache, client-side product detail caching, and the sessionStorage warm-start. Also note the fallback behavior when storage or REST isn’t available.
Edge cases covered: call out support for variations, grouped parents, mini-cart increments, DOM/store dedupe, and the defensive parsing for custom cart structures.
Testing done: list the scenarios you validated (PDP add, variable products, grouped adds, mini-cart +/- add/remove, cart page quantity changes, Store API failure, sessionStorage disabled).
-Potential follow-ups: optional mention that we rely on Woo Blocks scripts/Store API; if either is missing, we no-op but log a warning—so theme compatibility hinges on those assets being present.