Google Tag Manager + GA4 E-Commerce Tracking

• feature: new setting "Prices in the dataLayer" per sales channel. "As displayed in the shop (customer group)" is the default and keeps every figure as it is. "Always net" sends price, value and shipping without tax for every customer group, as Google recommends for value; tax stays the tax amount. This also applies to add_to_cart, remove_from_cart and the server-side purchase. Please note: the setting only takes effect on fields that still hold the shipped default. Where you rewrote price, value or shipping yourself, your formula stays untouched by this and every later update — reset the field to the default for the setting to apply. On update, unchanged default fields are switched to the new template functions dlprice, dlvalue and dlshipping; with the default setting they return exactly the same numbers as before
• feature: new setting "When to send add_shipping_info and add_payment_info" per sales channel. "Only when the shipping or payment method is changed" is the default and the previous behaviour — a customer who keeps the preselection sends neither event. "When the order overview loads and on every change" sends both events with the current selection when the order overview loads, and the affected one again after a change; reloading the page sends nothing twice. "Once when the order is submitted" sends both events once with the final selection when the order is placed, and nothing for changes before that. With the last option the event is created at the moment the browser leaves the page: Google Analytics 4 still delivers it, other tags in your container may lose it
• feature: add_to_cart now finds its price regardless of what you put into item_id. Until now the price was matched through the product number in item_id; with a product ID or your own value there, value and price silently stayed 0. The match now uses the cart position itself. value is the unit price times the added quantity over everything added, also when price holds your own formula — which is no longer overwritten. If a position did not reach the cart, the field is 0 and the plugin log names the route. Existing templates with {{ cartaddprice() }} keep working unchanged; for products with options the new functions cartaddnumber() and cartaddname() supply number and name, and templates that still use {{ item.id }} there keep working as well
• feature: select_item and add_to_wishlist now also find the clicked product when the listing module prints the product ID instead of the product number as item_id. Until now both events were silently dropped in that case. Shops that use the product number in item_id see no difference
• fix: Products from the product configurator with a surcharge charged once per position (for example a size "one-off +4.00 €") now send a price per piece in view_cart, begin_checkout, the shipping/payment events, remove_from_cart and purchase that adds up to the position total with the quantity. Until now the unit price contained the one-off amount per piece, so price × quantity exceeded value. Products without such surcharges send the same price as before
• fix: item_brand and item_category are no longer missing for products from the product configurator in purchase
• fix: The cancellation (refund) now lists only the top-level positions of an order in items, like the purchase. For products from the product configurator the base product and every option used to appear as separate products as well, so the item total was several times too high. item_brand and item_category are now filled for these products in the cancellation too
• fix: the hashed email address in user_data (sha256_email_address) now matches Google for Gmail addresses as well. For gmail.com and googlemail.com, Google removes dots and a + suffix before the @ prior to hashing (Jane.Doe+shop@gmail.com becomes janedoe@gmail.com); the plugin now does the same via the new template function hashemail(). Until now, buyers with such addresses were not matched in enhanced conversions. Other addresses produce the same hash as before. The update switches the field if it still contains the shipped value; your own formula stays unchanged
• fix: user_data and user.id are no longer missing on the order confirmation page for guest orders. If the shop logs guests out after checkout, Shopware (since 6.7.6) removes the customer before the page is rendered; the plugin now takes the data from the order that was just placed. Orders with a customer account were not affected
• fix: form errors are shown again after a redirect. With a dataLayer module on the route frontend.account.register.save, the registration showed no error message when the email address was already in use. This affected every route with a module that redirects on errors, including the registration in the checkout
• chore: the tabs of the administration module use the current Shopware components, and the actions are located in the smart bar. Four unused storefront text snippets were removed
• chore: the plugin writes its log entries to its own file var/log/WbmTagManagerAnalytics-.log instead of the Shopware default log. If you look for the plugin's messages (channel wbm_tag_manager), you will find them there

• fix: add_to_cart is no longer lost when adding an item changes the shipping or payment method (for example from parcel to letter). Shopware then loads the off-canvas cart a second time via a redirect; the plugin used to put the stored add_to_cart into the redirect response, which the browser discards, so only view_cart arrived. The event is now delivered with the final cart response
• fix: importing dataLayer modules now checks the same permissions as editing them in the administration: a role needs "create" to import and additionally "delete" for "replace existing data", which removes every module. Before, "edit" was enough to wipe all modules. Imported rows are validated like a save in the administration, and import errors name the concrete reason in the administration language instead of a technical server text
• fix: an export whose data cannot be encoded now shows an error instead of downloading a broken file
• fix: promotion click tracking no longer intercepts links without promotion data, and a link no longer stays dead when Google Tag Manager is blocked or does not respond — the browser follows it after two seconds at the latest
• chore: the storefront JavaScript plugins are renamed to WbmProductClickTracking, WbmAddToWishlistTracking and WbmPromotions, so another extension can no longer overwrite them with a plugin of the same name. If your theme addresses these plugins by their old names (ProductClickTracking, AddToWishlistTracking, Promotions), adjust the names. Errors in the storefront tracking are published as the event onWbmTagManagerError instead of being dropped silently
• fix: errors are no longer swallowed silently. Failures when rendering a dataLayer template are logged with the affected route and leave the page intact; database or configuration errors are reported instead of only making the tracking disappear. Error messages in the administration are shown with a notification
• fix: uninstalling without keeping user data removes the GA4 fields from orders first. If a plugin table cannot be dropped afterwards, the uninstall now stops with a visible error and can be repeated, instead of reporting success
• fix: the update migration that merges the product options route now actually removes the obsolete placeholder module; an invalid SQL statement made it fail silently before
• chore: the documentation button in the plugin configuration is labelled "Open documentation" and reports when the link cannot be loaded
• fix: the Twig filter uuid2bytes no longer crashes PHP with an endless recursion when a value contains "rental" but is not a valid ID
• fix: pagecategory() returns an empty value on pages without a navigation category instead of the name of an arbitrary category
• fix: in the dataLayer tree of the administration, the refund event lists its fields in a defined order again and the add-to-cart event for product options shows the correct number of child fields; existing installations are repaired on update
• fix: Twig code in your dataLayer templates now reaches Twig exactly as you entered it. Until now it was encoded like data first: a string such as 'ä' arrived as '\u00e4' and never matched, so a replace({'ä': 'ae'}) on names silently had no effect; written with double quotes ("ä") the template failed altogether and the whole dataLayer of that page was missing. Literal text around the Twig tags is unchanged
• fix: hashsha256() now lowercases non-ASCII capitals as well. Names such as "Öztürk" or "Ünal" kept their capital letter and their hash never matched Google's for enhanced conversions

• fix: the "Server-side purchase" add-on no longer skips orders that never reached GA4. The finish page used to confirm a purchase as reported by the browser as soon as Google Tag Manager had loaded — even when the GA4 tag itself did not run, for example because a blocker stops Google Analytics but lets Tag Manager through, or because the container holds no GA4 tag. Such orders were marked as reported and never sent from the server. The confirmation now waits for the Google tag with the measurement ID configured for the add-on. That ID must therefore be the same as in the GA4 tag of your container
• fix: Consent Mode and Google Tag Manager work again in shops that deliver minified HTML. Since 6.7.15 the plugin's inline scripts contained comments; when a minifier (shop plugin, hoster, CDN) strips the line breaks, each comment silently disabled the rest of its script. As a result no consent default was sent, the plugin sent no consent update, and the container did not load even after consent — visible in the browser console as "Uncaught SyntaxError: Unexpected end of input". The shipped scripts no longer contain comments and also run without line breaks
• chore: update the bundled giggsey/libphonenumber-for-php-lite to 9.0.39
• chore: the source maps of the admin bundle are no longer part of the shipped package
• fix: the value of the cart and order events no longer contains the shipping costs. GA4 defines value as the sum of price * quantity over the items and expects shipping and tax as parameters of their own — which the plugin already sends on purchase and refund. The shipped templates used the amount the customer pays instead, so the shipping was counted a second time inside value, and value did not match the items listed next to it. Google Ads optimises bidding on exactly that number, so campaign performance was measured against an inflated conversion value, and shops with different shipping rates per country compared figures that were not comparable. Affected are the cart page, the off-canvas cart, the register, confirm and payment/shipping steps of the checkout, the purchase on the finish page and the refund on order cancellation, plus the Google Ads remarketing field ecomm_totalvalue on the finish page — the cart routes already carried the right value there. The server-side purchase module reports the same corrected value, so browser and server stay reconcilable. Please note: from this update on, the revenue reported to GA4 is lower by the shipping costs. That is the corrected figure, not a loss of data — a break in your year-on-year comparison at the update date is expected. Templates you edited yourself are left untouched: the correction only replaces fields that still carry the shipped default
• feature: New paid add-on module "Server-side purchase": orders the browser does not report to GA4 are sent from the shop server instead. This covers purchases where the customer does not return to the shop after paying (PayPal, Klarna, instant bank transfer — window closed), where an ad blocker prevents the request, or where the checkout finish page never loads completely for other reasons; in all of these the order exists in Shopware but is missing in GA4. The module captures the visitor's GA4 identity when the order is placed (client and session id from the Google cookies, plus the consent reported by the configured consent tool — Shopware's cookie banner, Cookiebot, Usercentrics, consentmanager, Cookie Script, a custom rule, or a tool that controls Google Consent Mode itself; the plugin keeps that decision in the technically required cookie wbm-ga4-consent and updates it on revocation. Only a decision actually made in the consent tool counts — Consent Mode defaults never do, including the plugin's own default and region-specific defaults, and without a decision on the current page the cookie falls back to "no consent". Where the server can read the consent tool's own cookie (Shopware cookie banner, Cookiebot, Cookie Script, custom rule on a cookie) it checks that cookie as well) and reports the purchase through the Measurement Protocol after a configurable waiting time — using the Shopware order number as transaction_id, together with value, currency, tax, shipping and items. Double reports are avoided: if the browser reports the purchase, the finish page records that on the order and the server-side send drops out (a reload of the finish page does not count as a report); the server reserves every order before sending, so a retry or a second payment status never sends it twice. One rare case remains: a browser confirmation that only arrives after the waiting time, while the server is already sending. If a queue worker is terminated between reserving and sending, the order stays reserved and is not sent again; the order's additional field "Server send reserved at" and a log warning show it. Orders without analytics consent — for them not even the GA4 identity is stored — and orders created in the administration or via API stay unmeasured by design — the former for legal reasons, the latter because without a GA4 identity they would only become anonymous direct visits, distorting the channel reports more than the missing order does. Settings are per sales channel and follow the switch "Enable plugin for this sales channel"; without the unlocked add-on module they have no effect. Uninstalling without keeping user data removes the GA4 fields from all orders
• fix: events no longer disappear when a consent tool blocks the plugin's scripts. If you enter blocking attributes in the expert field "Script tag attributes" — which is exactly what the field is for — those attributes used to be placed on every one of the plugin's script tags, including the ones that merely hold data and send nothing. A consent tool prevents such a tag from RUNNING, so the values declared inside it never came into existence and the storefront JavaScript stopped mid-way. The result: no view_item, no listing impressions, no purchase — with the page answering normally and nothing appearing in any log, so the gap only showed up in GA4 weeks later. Blocking attributes now go to the container loading script alone, the one that actually sends to Google; the data tags always run. In addition the storefront JavaScript reads everything it needs as data from the page instead of relying on a script having run, so the measurement survives even a tool that blocks more than expected. Blocking the data tags never protected anything anyway — the values are in the page source either way, only the measurement was lost
• fix: the setting "Do not apply attributes to the dataLayer script tag" has been removed. It was the only way out of the problem described above, and its correct value is now the standard behaviour. Nothing needs to be done: shops that had it enabled keep exactly the behaviour they had
• fix: Google Tag Manager loads again when the table of dataLayer modules is empty. The plugin stopped with an error before the container script and left every page without Tag Manager
• fix: pages whose product names contain a double quote (for example Monitor 27" 4K) no longer show a "SyntaxError" in the browser console. An unused inline copy of the event data was removed; the events still come from the page's data island
• fix: queue workers no longer mix up orders. The dataLayer renderer, the product cache and the Twig helpers are reset between messages, and an empty or failed rendering no longer returns the result of the previous order — for the server-side purchase this could report the items of a different order. Products deleted in the meantime are sent with an empty name instead of an error text
• security: the GA4 API secret no longer appears in log files or in the failed-message queue when Google cannot be reached, and it is hidden from error trackers that record function arguments
• fix: administration — roles without write permission see saving, creating, deleting and moving of dataLayer modules and properties disabled; error messages are translated and name the reason; module and property lists show more than 25 entries and report loading errors; the overview page labels its columns and shows the status as "Active" or "Inactive"
• chore: the development switch WBM_GA4_IAP_OVERRIDE only takes effect in the dev and test environments, never in a production shop

• feature: the plugin now works with any cookie tool, not just Shopware's cookie consent and Usercentrics. The single "Select consent manager" setting used to answer three questions at once — who sends Google's default, when the container loads and where the consent signal comes from — and knew only three fixed tools. Anyone using Cookiebot, Cookie Script, OneTrust or Consentmanager inevitably ended up on "No cookie support". The three questions are now configured separately
• fix: Google Consent Mode now receives its default regardless of which cookie tool is in use. Previously the plugin sent consent default with everything set to denied only for Shopware's cookie consent. With any other tool nothing was sent at all — and Google treats a missing default as consent given. Analytics and advertising tags therefore fired before any agreement, no matter what the cookie banner displayed
• feature: new "When to load the container" setting: load immediately and gate through Consent Mode, load only after consent, or leave loading to the cookie tool through blocking attributes. The Usercentrics special case previously hard-wired into the template is now just one of many possible values
• feature: new "Read consent signal from" setting, with a verified template for Cookie Script and a freely definable rule for any other tool that stores its decision in a cookie or in local storage. An invalid rule is discarded and logged — it never silently grants anything
• feature: Cookiebot, Usercentrics and consentmanager.net are supported directly as a consent signal — each through that tool's documented interface rather than a cookie rule: Cookiebot through Cookiebot.consent, Usercentrics through UC_UI.getServicesBaseInfo(), consentmanager.net through __cmp('getCMPData'). With Usercentrics and consentmanager.net the service names and purpose IDs depend on your account; the defaults cover the usual Google services and can be overridden per storage type. If Google Consent Mode is enabled in the tool itself, "Consent tool handles it" remains the better choice
• feature: new window.wbmTagManager interface with setConsent(), grantAll(), denyAll() and loadGtm(), plus the wbm-tagmanager:consent event. This also allows connecting a cookie tool the plugin does not know — from a customizing plugin, from Tag Manager or from a snippet of the tool itself
• feature: new "Record consent diagnostics" setting. It logs which default was sent, which signal arrived and when the container was loaded — the three questions otherwise answered only with developer tools
• feature: new "Wait for the consent signal (milliseconds)" setting. It controls Google's wait_for_update in the default command, which used to be hard-wired to 500 ms. The right value depends on the cookie tool in use: where the plugin reads the signal synchronously from a cookie the wait resolves immediately and delays nothing, but where a consent tool restores its stored decision through an asynchronous script, this value decides whether analytics and advertising tags learn about the consent at all — and 500 ms is not always enough for that. Defaults to 500 ms, 0 turns it off, capped at 10 seconds
• fix: the plugin no longer writes messages to the browser console. The Shopware Store rejects console.* calls in shipped JavaScript — even where proper error handling sits right next to them. The diagnostics are fully preserved: with the debug flag set, every message goes into a ring buffer (200 entries) under window.wbmTagManagerDebug, readable via window.wbmTagManagerDebug.dump(), and is additionally emitted as the storefront event wbmTagManagerDiagnostic for a shop to hook its monitoring to. Applies to the storefront JS and the consent diagnostics alike
• fix: after a fresh installation the plugin measures again without further action. The new "Read consent signal from" setting started on "Consent tool handles it" — with that, nothing evaluates the consent, Google Consent Mode stays on "denied" permanently and no data arrives, without the interface giving any hint. The default is now Shopware's cookie consent again, as it was up to 6.7.14. Existing shops are unaffected: the migration writes an explicit mapping for every previous value, so your setting stays exactly as you had it
• fix: for logged-in customers the user_data data layer contained nothing but {"error":"dataLayer unavailable"}, so email, name, address and phone number for Enhanced Conversions were missing entirely. The bundled phone number library was never loaded: its path was anchored on getPath(), which for a Shopware plugin returns the directory of the class file — src/ — while the library sits next to it under packages/. The path therefore pointed nowhere, and the check for it failed silently. Guests were never affected, because only logged-in customers receive that data layer. The path is now anchored on the plugin root
• chore: removed a dead eslint-disable comment from the storefront entry file. It disabled a rule the Shopware Store analyzer does not load at all — ESLint then reported the disabled rule itself as an error and failed the upload's static analysis
• chore: a migration carries existing settings over per sales channel, so your shop behaves exactly as before after the update. Switching to one of the new modes is a deliberate decision, not a side effect of updating
• fix: content pages without a product listing no longer trigger an empty view_item_list. The dataLayer modules are bound to the route, and in Shopware frontend.navigation.page also covers every CMS page as well as manufacturer and landing pages, frontend.home.page the home page. Where no product listing area exists, the loop over the items ran empty — yet the event was still sent, with items: [] and a list name such as "Category: About us". In GA4 such events distort list reports and item list attribution, and in Google Ads they produce empty remarketing signals. Events with an empty item list are now discarded on the server and never reach the page at all; this includes listings reloaded via Ajax (filters, sorting, pagination). Events that carry no item list at all are left untouched

• fix: exporting the data layers no longer runs one query per record and can no longer loop forever. The export walked the property tree recursively with a query per row and without any cycle guard — a tree in which two properties reference each other as parent (which the import does not check, and a hand-edited export easily produces) ran until the memory limit. The tree is now loaded in a single query and ordered in PHP with a visited list
• fix: the data layer import now runs in a single transaction. Previously the DELETE ran outside it, every failed insert was swallowed by an empty catch, and the response still reported success — a partially broken import left the operator without the old and without the complete new data, with no indication. A failing insert now rolls the whole import back and returns success: false; the response also carries the number of skipped rows
• fix: exception messages no longer end up in the data layer. dbquery() returned the exception message as its value and the renderer wrote it into the data layer, so SQL and Twig error texts — including table, column and template names — were rendered into the storefront HTML for every visitor. Errors now go to a dedicated wbm_tag_manager log channel; the storefront gets an empty value respectively a neutral placeholder
• feature: the sales channel switch is now a positive Enable plugin for this sales channel (config key active, default on) and replaces the inverted Deactivate GTM container (isInactive). Existing settings are carried over per sales channel by a migration, so a channel you had switched off stays off
• fix: the plugin role now grants the entity privileges the admin module actually queries (wbm_data_layer_modules, wbm_data_layer_properties, sales_channel, sales_channel_domain, system_config). Previously a user with only the plugin role got HTTP 403 and an empty page in the module list and the sales channel overview
• fix: reloading the order confirmation page no longer removes the Google Tag Manager. The duplicate guard left the render subscriber before the configuration was assigned, so a second view of the same order (F5, back button, second tab, repeated payment return) rendered without the GTM loader script and without the noscript iframe — the container was gone, not just the purchase event. Only the dataLayer is suppressed now. Two further gaps of the same guard are closed: switching between two orders and back no longer counts the first one twice (the session remembers a list instead of a single order), and a missing orderId parameter no longer poisons the session for the rest of the visit
• fix: the warning banner on the "Manipulate Tag Manager script" configuration card now follows the administration language. It was declared as an mt-banner component with per-language elements in config.xml, but Shopware's ConfigReader does not treat title on component children as translatable — only the last declared value survived, so every operator saw Dutch text. The same recursion also replaced the card heading with the banner text. The hint is now rendered by a dedicated admin component with snippets in EN/DE/NL
• fix: on AfterLineItemAdded the product lookup for line items without a product number in the payload no longer runs one query per position — the IDs are collected and resolved in a single request
• chore: import/export in the administration now go through a registered ApiService instead of a hand-built Bearer header, which broke after a token refresh
• fix: the data layer import now tells you when it did not work. The controller answers every rejection — wrong file type, broken JSON, a rolled-back transaction — with HTTP 200 and success: false, and nobody evaluated that: the import jumped back to the overview and reported success even when nothing had been taken over. A rejected file now names its reason, skipped rows are reported, and a failing request (403, 413, 500) produces an error message instead of nothing at all. The export got the same treatment
• fix: the container ID overview no longer keeps loading forever when a single sales channel cannot be read. Completion was tied to a counter over one request per channel; one failed request left the page in its loading state indefinitely. The requests now run through Promise.all(), the loading state ends in finally, and an unreadable channel falls back to the global values so the overview stays complete
• fix: the container ID overview now lists every sales channel. The query ran without an explicit limit and therefore used the administration default of 25 — shops with more sales channels silently saw an incomplete list
• fix: the administration notification after a plugin update now follows the administration language instead of being English for everyone
• chore: replace the five @ error suppressions in TagManagerExtension and DataLayerRenderer with explicit type and existence checks. One of them hid a second defect: without a referencedId in the request, getparam('lineItems') wrote the config hash into a key named "" instead of into the line item
• security: the GTM container ID, the custom Tag Manager URL and the URL parameter add-on are validated before they reach the storefront. All three ended up unescaped in a JavaScript string respectively in a src attribute, so a user with system_config:update — a permission widely granted in operator roles and explicitly not a developer permission — could enter x'; alert(document.cookie); // as the container ID and permanently serve their own JavaScript on every storefront page (privilege escalation to persistent XSS). The container ID now has to match GTM- plus capital letters and digits, the Tag Manager URL has to be an http(s) address without a query part, and the URL parameter add-on is limited to the characters URL parameters actually use. A rejected value is written to the wbm_tag_manager log channel and the tracking stays off rather than shipping unchecked code. The validation sits in DataLayerModules, not in the templates, because the same value is rendered in several places and contexts
• chore: the three remaining console.error calls of the Ajax interceptor now honour the debug flag and are worded in English with the [WbmTagManagerAnalytics] prefix, like every other diagnostic message since 6.7.13. Shop visitors previously saw German error text in their browser console in an English shop; the message only ever helps while debugging, and that is exactly what the flag is for
• fix: the property tree now says so when a module has more properties than it displays. It loads at most 500 entries — sensible, because an unbounded tree pulls an arbitrary number of records into the browser after a botched import — but it did so silently, which looked like data loss. The total is now read along with the result and a warning names it
• chore: move the dependency injection configuration from XML to YAML (services.yaml plus the four files under config/services/). The split by responsibility is unchanged. Shopware loaded both formats, so nothing changes at runtime — the plugin now follows the current convention
• fix: the export route now returns properly encoded JSON. new JsonResponse(json_encode(...)) encoded a second time, so the response body was a JSON string containing JSON. The downloaded file was never affected — Axios parsed once and exactly the right string went into it — but every other consumer of the route (curl, script, monitoring) had to parse twice, and saving the raw response to a file produced something the import rejected. The admin download now takes the body unparsed, so the file is byte-identical to before. An encoding failure no longer ships a file containing the word false either; it is logged and reported
• fix: the cart subscriber takes the session from the running request instead of creating a new one in its constructor. SessionFactoryInterface::createSession() is a factory — it creates a new, empty session and does not ask whether one already exists. Inside a storefront request that worked out, but the subscriber listens to a cart event, not an HTTP event: a message handler, a CLI command or an import that sets line items triggers it without any request at all. That case is now recognised and skipped instead of relying on Symfony wiring up a session after the fact

• feature: storefront console diagnostics are now hidden behind an opt-in debug flag — messages such as "no items found in dataLayer" and caught click-tracking errors are only logged (prefixed with [WbmTagManagerAnalytics]) when localStorage.setItem('wbmTagManagerDebug', '1') is set in the visitor's browser; shop visitors no longer see any console output regardless of the DevTools log level. Real processing errors of the Ajax interceptor remain visible as console.error. See the README section "Debug-Modus (Console-Diagnose)"
• fix: cartnetprice now returns a correct net price for non-product cart line items (promotion/voucher, container, product-with-options, custom) — it previously returned 0, which broke storefront templates computing the tax rate as (cartremoveprice(id) / cartnetprice(id) - 1) * 100 with a division by zero. The net is now derived from the line item's calculated price (gross − tax share) and is tax-status aware (gross/net/tax-free); only real product line items still take their net from the product price list
• fix: Ajax-driven listing updates (category/search filter, sort, pagination) re-emit their view_item_list to the dataLayer again — the GA4 event was previously dropped because the interceptor's onEvent branch was guarded by an unset window.WbmDataLayer
• fix: resolve the "Ambiguous class resolution" autoload warning for the bundled libphonenumber library when another plugin (e.g. Meta/Facebook Pixel) also ships giggsey/libphonenumber-for-php. The bundled copy is no longer registered in the project's composer autoload; it is loaded via a dedicated class loader appended during plugin boot, so an already-present copy always takes precedence and ours is used only as a fallback
• chore: update the bundled giggsey/libphonenumber-for-php-lite to 9.0.34

• feature: storefront console diagnostics are now hidden behind an opt-in debug flag — messages such as "no items found in dataLayer" and caught click-tracking errors are only logged (prefixed with [WbmTagManagerAnalytics]) when localStorage.setItem('wbmTagManagerDebug', '1') is set in the visitor's browser; shop visitors no longer see any console output regardless of the DevTools log level. Real processing errors of the Ajax interceptor remain visible as console.error. See the README section "Debug-Modus (Console-Diagnose)"
• fix: cartnetprice now returns a correct net price for non-product cart line items (promotion/voucher, container, product-with-options, custom) — it previously returned 0, which broke storefront templates computing the tax rate as (cartremoveprice(id) / cartnetprice(id) - 1) * 100 with a division by zero. The net is now derived from the line item's calculated price (gross − tax share) and is tax-status aware (gross/net/tax-free); only real product line items still take their net from the product price list
• fix: Ajax-driven listing updates (category/search filter, sort, pagination) re-emit their view_item_list to the dataLayer again — the GA4 event was previously dropped because the interceptor's onEvent branch was guarded by an unset window.WbmDataLayer
• fix: resolve the "Ambiguous class resolution" autoload warning for the bundled libphonenumber library when another plugin (e.g. Meta/Facebook Pixel) also ships giggsey/libphonenumber-for-php. The bundled copy is no longer registered in the project's composer autoload; it is loaded via a dedicated class loader appended during plugin boot, so an already-present copy always takes precedence and ours is used only as a fallback
• chore: update the bundled giggsey/libphonenumber-for-php-lite to 9.0.34
• feature: push a named dataLayer event wbm_consent_update after every consent change (initial opt-in via cookie banner as well as later updates) so that GTM can trigger a GA4 page_view on the same pageload — fixes loss of original entry source after opt-in
• fix: subscriber now also reacts when only google-analytics-enabled or google-ads-enabled are toggled (previously only fired when wbm-tagmanager-enabled was in the update delta)
• fix: replace broken typeof script === 'undefined' guard (getElementById returns null); remove unreachable empty-update check; refactor cookie consent subscriber for readability

1. fix: admin nl.json parse error

• fix: Uncaught PHP Exception TypeError: SalesChannelContextServiceDecorator

• fix: add_to_wishlist, issues with adding fixed, now also works in a shopping basket and off-canvas
• fix: clear the previous ecommerce object
• fix: shipping/payment event
• feature: add refund event
• feature: request with no HTML response can tracked post options

• fix: cookie consent with 'shopware consent tool'

• fix: Unexpected token "operator" of value "constant"
• fix: add_to_wishlist, when logged in, event fired on removed

• fix: variable 'page.header' is no longer defined

• fix: undefined variable $parameters

• fix: migration properties when mariadb is used

• fix: little fixes
• feature: An “event” for user_data (user provided data) has been added.

adjustment to Shopware 6.7.1

• feature: maximal length of datalayer by view_item_list
• bugfix: no view datalayer settings in admin

adjustment to Shopware 6.7.0.0

• fix: the Google Tag Manager container is no longer missing on repeated views of the order confirmation page — the duplicate-purchase guard returned before wbmTagManagerConfig was set, so any second render of /checkout/finish for the same order (reload, back button, second tab, repeated payment return) dropped the GTM loader script and the noscript iframe entirely instead of only suppressing the purchase event; the guard now skips just the dataLayer, and the container is always rendered
• fix: the tracked-order marker moved from the generic session key orderId to the namespaced wbm-tag-manager-tracked-orders, which could collide with the core and with other plugins
• fix: an empty orderId in the URL is no longer remembered as tracked — it made the guard match for the rest of the session and left the order confirmation page without any tag manager
• fix: tracked orders are kept as a list (max. 20) instead of a single value, so ordering A → B → revisiting A no longer counts the first order a second time

• feature: storefront console diagnostics are now hidden behind an opt-in debug flag — messages such as "no items found in dataLayer" and caught click-tracking errors are only logged (prefixed with [WbmTagManagerAnalytics]) when localStorage.setItem('wbmTagManagerDebug', '1') is set in the visitor's browser; shop visitors no longer see any console output regardless of the DevTools log level. See the README section "Debug mode (console diagnostics)"
• fix: cartnetprice now returns a correct net price for non-product cart line items (promotion/voucher, container, product-with-options, custom) — it previously returned 0, which broke storefront templates computing the tax rate as (cartremoveprice(id) / cartnetprice(id) - 1) * 100 with a division by zero. The net is now derived from the line item's calculated price (gross − tax share) and is tax-status aware (gross/net/tax-free); only real product line items still take their net from the product price list
• fix: replace broken typeof script === 'undefined' guard in the cookie consent subscriber — getElementById returns null, so the guard never matched and a missing tag-manager script element led to a null dereference
• fix: consent updates now fire on every cookie change again — gtag('consent','update',…) was bound to the one-time tag-manager script injection, so later toggles of google-analytics-enabled / google-ads-enabled no longer reached Google; the consent update is now decoupled from the script injection

• fix: prevent non-numeric value encountered' warning in SessionUtility
• fix: foreach warnings and ensure array types after json_decode

• fix: Unexpected token "operator" of value "constant"
• fix: add_to_wishlist, when logged in, event fired on removed

• fix: clickevent, pressing a modifier key (such as Shift or Ctrl/Command) is allowed to pass through

• fix: Cookie accepted 
• fix: itemnumber and brand and category by promotion 
• feature: datalayer in JSON response 
• feature: twigfilter optionchilds 
• feature: more than one extra Events

• Remove Admin Bannner 
• fix: little bugfix cartnetprice 
• fix: enhanced performance for large shopping carts 
• fix: Cookie für Google Adds korrigiert 
• fix: Finish page push event when customer reload page

Retroactive release for older store versions

fix: google analytics

• fix: route in konfiguratormigration 
• fix: items in listinglayout 
• add: getparentproductid

fix: 

• little bugfixes, eg. Subset

feature: 

• working correct with swpproductkonfigurator
• advanced e-commerce-tracking

• add responseroute to remove_from_cart
• correct datalayer in cart/confirm when product deleted

• fix: xhr requests were not written to the datalayer

adjustment to Shopware 6.6.0.2

- New: Integration of Consense Mod V2

- Rebranding from Webmatch to BuI Hinsche GmbH

- Adaptation of versioning to BuI versioning

- New: NoScript URL customisable

# 5.2.5

* fix: enhanced performance for lengthy product listings by minimizing database queries from Twig

* fix: cookie Consent Mode for multiple sales channels, now supporting unique container IDs per channel

# 5.2.4

* fix: recompile storefront - compatibility to Horizon Theme

# 5.2.3

* fix: recompile JavaScript

# 4.2.2

* fix: prevent js error in listing

# 5.2.1

* feature: added "add_to_wishlist" on product detail page

* fix: "add_to_wishlist" with larger product lists

* fix: update help text for config option

# 5.2.0

* feature: replace "dbquery" twig function

* fix: correct amount for add-to-cart when product quantity > 1 

* fix: correct amount for remove-from-cart when product quantity > 1

# 5.1.0

* fix: prevent encoding custom google tagmanager code

* fix: get sales channel from request

* fix: harden js-condition for click tracking

* fix: move datalayer class from plugin to utils

* fix: don't track select_item on add to wishlist icon

* feature: add option to enable "add to wishlist" tracking

# 5.0.1

* update promo banner in admin

# 5.0.0

* Compatibility to SW 6.5

# 4.2.3

* fix: enhanced performance for lengthy product listings by minimizing database queries from Twig

* fix: cookie Consent Mode for multiple sales channels, now supporting unique container IDs per channel

# 4.2.2

* fix: prevent error in listing

# 4.2.1

* feature: added "add_to_wishlist" on product detail page

* fix: "add_to_wishlist" with larger product lists

* fix: update help text for config option

# 4.2.0

* feature: replace "dbquery" twig function

* fix: correct amount for add-to-cart when product quantity > 1 

* fix: correct amount for remove-from-cart when product quantity > 1

# 4.1.0

* fix: prevent encoding custom google tagmanager code

* fix: get sales channel from request

* fix: harden js-condition for click tracking

* fix: don't track select_item on add to wishlist icon

* feature: add option to enable "add to wishlist" tracking

# 4.0.4

* fix: prevent error with missing "columnExists"-function in migration

* fix: get id from customer instead of context

Initial release of the official successor of the popular plugin “Google Tag Manager & Google Analytics Enhanced E-Commerce Tracking for Shopware 6" (https://store.shopware.com/wbm1713539203085f/google-tag-manager-google-analytics-enhanced-e-commerce-tracking-fuer-shopware-6.html)