Google Tag Manager | GA4 Tracking und Server Side Tagging ohne Theme Eingriff

• fix: add_to_cart geht nicht mehr verloren, wenn sich beim Hinzufügen eines Artikels die Versand- oder Zahlungsart ändert (zum Beispiel von Paket auf Brief). Shopware lädt den Off-Canvas-Warenkorb dann über eine Weiterleitung ein zweites Mal; das Plugin schrieb das gespeicherte add_to_cart bisher in die Weiterleitungsantwort, die der Browser verwirft, sodass nur view_cart ankam. Das Ereignis wird jetzt mit der endgültigen Warenkorb-Antwort ausgeliefert
• fix: Der Import von dataLayer-Modulen prüft jetzt dieselben Berechtigungen wie das Bearbeiten in der Administration: Eine Rolle braucht „Erstellen“ für den Import und zusätzlich „Löschen“ für „Vorhandene Daten ersetzen“, das alle Module entfernt. Bisher genügte „Bearbeiten“, um sämtliche Module zu löschen. Importierte Zeilen werden wie beim Speichern in der Administration geprüft, und Importfehler nennen den konkreten Grund in der Sprache der Administration statt eines technischen Servertextes
• fix: Ein Export, dessen Daten sich nicht kodieren lassen, zeigt jetzt einen Fehler, statt eine defekte Datei herunterzuladen
• fix: Das Promotion-Klick-Tracking fängt Links ohne Promotion-Daten nicht mehr ab, und ein Link bleibt nicht mehr tot, wenn der Google Tag Manager blockiert ist oder nicht antwortet — der Browser folgt ihm spätestens nach zwei Sekunden
• chore: Die JavaScript-Plugins der Storefront heißen jetzt WbmProductClickTracking, WbmAddToWishlistTracking und WbmPromotions, damit eine andere Erweiterung sie nicht mehr mit einem gleichnamigen Plugin überschreiben kann. Spricht Ihr Theme diese Plugins unter den alten Namen an (ProductClickTracking, AddToWishlistTracking, Promotions), passen Sie die Namen an. Fehler im Storefront-Tracking werden als Ereignis onWbmTagManagerError veröffentlicht, statt still zu verschwinden
• fix: Fehler werden nicht mehr stillschweigend verschluckt. Fehler beim Rendern einer dataLayer-Vorlage werden mit der betroffenen Route protokolliert und lassen die Seite intakt; Datenbank- oder Konfigurationsfehler werden gemeldet, statt nur das Tracking verschwinden zu lassen. Fehler in der Administration erscheinen als Benachrichtigung
• fix: Eine Deinstallation ohne Erhalt der Benutzerdaten entfernt zuerst die GA4-Felder aus den Bestellungen. Lässt sich danach eine Plugin-Tabelle nicht löschen, bricht die Deinstallation jetzt mit einem sichtbaren Fehler ab und kann wiederholt werden, statt Erfolg zu melden
• fix: Die Update-Migration, die die Route der Produktoptionen zusammenführt, entfernt das veraltete Platzhalter-Modul jetzt tatsächlich; eine ungültige SQL-Anweisung ließ sie bisher still scheitern
• chore: Der Doku-Button in der Plugin-Konfiguration heißt „Dokumentation öffnen“ und meldet, wenn der Link nicht geladen werden kann
• fix: Der Twig-Filter uuid2bytes bringt PHP nicht mehr durch eine Endlosrekursion zum Absturz, wenn ein Wert „rental“ enthält, aber keine gültige ID ist
• fix: pagecategory() liefert auf Seiten ohne Navigationskategorie einen leeren Wert statt des Namens einer beliebigen Kategorie
• fix: Im dataLayer-Baum der Administration zeigt das Refund-Ereignis seine Felder wieder in fester Reihenfolge, und das Warenkorb-Ereignis für Produktoptionen nennt die richtige Anzahl an Unterfeldern; bestehende Installationen werden beim Update repariert
• fix: Twig-Code in Ihren dataLayer-Vorlagen kommt jetzt genau so bei Twig an, wie Sie ihn eingegeben haben. Bisher wurde er vorher wie Daten kodiert: Eine Zeichenkette wie 'ä' kam als '\u00e4' an und passte nie, ein replace({'ä': 'ae'}) auf Namen blieb daher still wirkungslos; mit doppelten Anführungszeichen ("ä") scheiterte die Vorlage ganz, und der gesamte dataLayer der Seite fehlte. Text außerhalb der Twig-Tags bleibt unverändert
• fix: hashsha256() schreibt jetzt auch Großbuchstaben außerhalb von A–Z klein. Namen wie „Öztürk“ oder „Ünal“ behielten ihren Großbuchstaben, ihr Hash passte bei den Enhanced Conversions nie zu dem von Google

• fix: Das Zusatzmodul „Serverseitiges purchase" überspringt keine Bestellungen mehr, die nie bei GA4 angekommen sind. Die Dankeseite bestätigte einen Kauf bisher als vom Browser gemeldet, sobald der Google Tag Manager geladen war — auch wenn das GA4-Tag selbst nicht lief, etwa weil ein Blocker Google Analytics sperrt, den Tag Manager aber durchlässt, oder weil der Container gar kein GA4-Tag enthält. Solche Bestellungen galten als gemeldet und wurden serverseitig nie nachgemeldet. Die Bestätigung wartet jetzt auf das Google-Tag mit der für das Zusatzmodul eingetragenen Mess-ID. Diese ID muss deshalb dieselbe sein wie im GA4-Tag Ihres Containers
• fix: Consent Mode und Google Tag Manager funktionieren wieder in Shops, deren HTML minifiziert ausgeliefert wird. Seit 6.7.15 enthielten die Inline-Skripte des Plugins Kommentare; entfernt ein Minifier (Shop-Plugin, Hoster, CDN) die Zeilenumbrüche, legte jeder Kommentar den Rest seines Skripts still. Folge: keine consent default-Voreinstellung, kein Einwilligungs-Update aus dem Plugin, und der Container lud auch nach der Zustimmung nicht — in der Browser-Konsole als „Uncaught SyntaxError: Unexpected end of input" sichtbar. Die ausgelieferten Skripte enthalten keine Kommentare mehr und sind auch ohne Zeilenumbrüche lauffähig
• chore: mitgelieferte giggsey/libphonenumber-for-php-lite auf 9.0.39 aktualisiert
• chore: Die Source-Maps des Admin-Bundles sind nicht mehr Teil des ausgelieferten Pakets
• fix: Der value der Warenkorb- und Bestellereignisse enthält die Versandkosten nicht mehr. GA4 definiert value als Summe aus price * quantity über die Positionen und erwartet Versand und Steuer als eigene Parameter — die das Plugin bei purchase und refund ohnehin mitsendet. Die ausgelieferten Vorlagen verwendeten stattdessen den Zahlbetrag des Kunden, wodurch der Versand zusätzlich im value steckte und value nicht zu den daneben aufgeführten Positionen passte. Google Ads optimiert die Gebote auf genau diese Zahl, die Kampagnenleistung wurde also an einem überhöhten Conversion-Wert gemessen, und Shops mit unterschiedlichen Versandkosten je Land verglichen Werte, die nicht vergleichbar waren. Betroffen sind die Warenkorbseite, der Off-Canvas-Warenkorb, die Schritte Registrierung, Bestellbestätigung und Zahlungs-/Versandauswahl im Checkout, das purchase auf der Dankeseite und das refund bei Bestellstornierung, dazu das Google-Ads-Remarketing-Feld ecomm_totalvalue auf der Dankeseite — auf den Warenkorb-Routen stand dort bereits der richtige Wert. Das serverseitige purchase-Modul meldet denselben korrigierten Wert, Browser und Server bleiben also abgleichbar. Bitte beachten Sie: Ab diesem Update fällt der an GA4 gemeldete Umsatz um die Versandkosten niedriger aus. Das ist der korrigierte Wert und kein Datenverlust — ein Bruch im Vorjahresvergleich zum Update-Zeitpunkt ist zu erwarten. Selbst angepasste Vorlagen bleiben unangetastet: Die Korrektur ersetzt ausschließlich Felder, die noch den Auslieferungsstand tragen
• feature: Neues kostenpflichtiges Zusatzmodul „Serverseitiges purchase": Bestellungen, die der Browser nicht an GA4 meldet, werden vom Shop-Server nachgemeldet. Betroffen sind Käufe, bei denen der Kunde nach der Zahlung nicht in den Shop zurückkehrt (PayPal, Klarna, Sofortüberweisung — Fenster geschlossen), ein Werbeblocker den Versand verhindert oder die Bestellabschlussseite aus anderen Gründen nie vollständig lädt; in all diesen Fällen existiert die Bestellung in Shopware, in GA4 fehlt sie. Das Modul sichert beim Anlegen der Bestellung die GA4-Identität des Besuchers (Client- und Sitzungs-ID aus den Google-Cookies, dazu die Einwilligung, die das eingestellte Consent-Tool meldet — Shopwares Cookie-Banner, Cookiebot, Usercentrics, consentmanager, Cookie Script, eine eigene Regel oder ein Werkzeug, das den Google Consent Mode selbst steuert; das Plugin hält diese Entscheidung im technisch notwendigen Cookie wbm-ga4-consent fest und aktualisiert es bei Widerruf. Es zählt nur eine tatsächlich im Consent-Tool getroffene Entscheidung — Voreinstellungen des Consent Mode nie, auch nicht die des Plugins oder länderspezifische, und ohne Entscheidung auf der aktuellen Seite fällt das Cookie auf „keine Einwilligung“ zurück. Wo der Server das eigene Cookie des Consent-Tools lesen kann (Shopware-Cookie-Banner, Cookiebot, Cookie Script, eigene Regel auf ein Cookie), prüft er zusätzlich dieses) und meldet den Kauf nach einer einstellbaren Wartezeit über das Measurement Protocol nach — mit der Shopware-Bestellnummer als transaction_id sowie Wert, Währung, Steuer, Versand und Positionen. Doppelmeldungen werden vermieden: Meldet der Browser den Kauf, bestätigt die Dankeseite das an der Bestellung, und der serverseitige Versand steigt aus (ein Neuladen der Dankeseite zählt nicht als Meldung); der Server reserviert jede Bestellung vor dem Versand, sodass eine Wiederholung oder ein zweiter Zahlungsstatus sie nie doppelt sendet. Ein seltener Restfall bleibt: eine Browser-Bestätigung, die erst nach Ablauf der Wartezeit eintrifft, während der Server bereits sendet. Wird ein Queue-Worker zwischen Reservieren und Senden beendet, bleibt die Bestellung reserviert und wird nicht erneut gesendet; das Zusatzfeld „Serverversand reserviert am“ der Bestellung und eine Log-Warnung zeigen das an. Bestellungen ohne Analytics-Einwilligung — für sie wird nicht einmal die GA4-Identität gespeichert — sowie Bestellungen aus der Administration oder per Schnittstelle bleiben bewusst ungemessen — im ersten Fall aus Rechtsgründen, im zweiten, weil ohne GA4-Identität nur ein anonymer Direktzugriff entstünde, der die Kanalberichte stärker verfälscht als die fehlende Bestellung. Die Einstellungen sind je Verkaufskanal getrennt und folgen dem Schalter „Plugin für diesen Verkaufskanal aktivieren“; ohne freigeschaltetes Zusatzmodul bleiben sie wirkungslos. Eine Deinstallation ohne Erhalt der Benutzerdaten entfernt die GA4-Felder aus allen Bestellungen
• fix: Ereignisse verschwinden nicht mehr, wenn ein Consent-Werkzeug die Skripte des Plugins blockiert. Tragen Sie im Expertenfeld „Script-Tag-Attribute" Blockier-Attribute ein — wofür das Feld gedacht ist —, landeten diese bisher an jedem Script-Tag des Plugins, auch an denen, die lediglich Daten bereitstellen und nichts senden. Ein Consent-Werkzeug verhindert die AUSFÜHRUNG eines solchen Tags, die darin festgelegten Werte entstanden also nie, und das Storefront-JavaScript brach mittendrin ab. Die Folge: kein view_item, keine Listen-Impressionen, kein purchase — bei normal antwortender Seite und ohne Eintrag in irgendeinem Protokoll, sodass die Lücke erst Wochen später in GA4 auffiel. Blockier-Attribute gehen jetzt ausschließlich an das Ladeskript des Containers, also an das Tag, das tatsächlich an Google sendet; die Datentags laufen immer. Zusätzlich liest das Storefront-JavaScript alles Benötigte als Daten aus der Seite, statt sich darauf zu verlassen, dass ein Skript gelaufen ist — die Messung übersteht damit auch ein Werkzeug, das mehr blockiert als erwartet. Das Blockieren der Datentags hat ohnehin nie etwas geschützt: Die Werte stehen so oder so im Quelltext der Seite, verloren ging allein die Messung
• fix: Die Einstellung „Setze diese Attribute nicht an das dataLayer Script-Tag" ist entfallen. Sie war der einzige Ausweg aus dem oben beschriebenen Problem, und ihr richtiger Wert ist jetzt das Standardverhalten. Sie müssen nichts tun: Shops, in denen sie gesetzt war, verhalten sich genau wie bisher
• fix: Google Tag Manager lädt wieder, wenn die Tabelle der dataLayer-Module leer ist. Das Plugin brach vor dem Container-Script mit einem Fehler ab und ließ jede Seite ohne Tag Manager
• fix: Seiten mit Produktnamen, die ein Anführungszeichen enthalten (zum Beispiel Monitor 27" 4K), zeigen in der Browser-Konsole keinen „SyntaxError“ mehr. Eine ungenutzte Inline-Kopie der Ereignisdaten wurde entfernt; die Ereignisse kommen weiterhin aus der Dateninsel der Seite
• fix: Queue-Worker vermischen keine Bestellungen mehr. dataLayer-Renderer, Produkt-Cache und Twig-Hilfsfunktionen werden zwischen Nachrichten zurückgesetzt, und ein leeres oder fehlgeschlagenes Rendering liefert nicht mehr das Ergebnis der vorherigen Bestellung — beim serverseitigen purchase konnten sonst die Positionen einer anderen Bestellung gemeldet werden. Zwischenzeitlich gelöschte Produkte werden mit leerem Namen statt mit einem Fehlertext gesendet
• security: Das GA4-API-Geheimnis erscheint nicht mehr in Logdateien oder in der Queue fehlgeschlagener Nachrichten, wenn Google nicht erreichbar ist, und bleibt auch Fehler-Trackern verborgen, die Funktionsargumente aufzeichnen
• fix: Administration — Rollen ohne Schreibrecht sehen Speichern, Anlegen, Löschen und Verschieben von dataLayer-Modulen und -Eigenschaften deaktiviert; Fehlermeldungen sind übersetzt und nennen den Grund; Modul- und Eigenschaftslisten zeigen mehr als 25 Einträge und melden Ladefehler; die Übersichtsseite beschriftet ihre Spalten und zeigt den Status als „Aktiv“ oder „Nicht aktiv“
• chore: Der Entwicklungsschalter WBM_GA4_IAP_OVERRIDE wirkt nur noch in den Umgebungen dev und test, nie in einem Produktivshop

• feature: Das Plugin arbeitet jetzt mit jedem Cookie-Werkzeug zusammen, nicht mehr nur mit Shopwares Cookie-Consent und Usercentrics. Die eine Einstellung „Consent Manager auswählen" beantwortete bisher drei Fragen gleichzeitig — wer Googles Voreinstellung sendet, wann der Container lädt und woher das Einwilligungssignal kommt — und kannte dafür nur drei feste Werkzeuge. Wer Cookiebot, Cookie Script, OneTrust oder Consentmanager einsetzte, landete zwangsläufig bei „Keine Cookie-Unterstützung". Die drei Fragen sind jetzt getrennt einstellbar
• fix: Der Google Consent Mode bekommt seine Voreinstellung jetzt unabhängig vom eingesetzten Cookie-Werkzeug. Bisher sendete das Plugin consent default mit allem auf denied ausschließlich bei Shopwares Cookie-Consent. Bei jedem anderen Werkzeug wurde gar nichts gesendet — und eine fehlende Voreinstellung behandelt Google als erteilte Einwilligung. Analyse- und Werbe-Tags feuerten damit vor jeder Zustimmung, unabhängig davon, was das Cookie-Banner anzeigte
• feature: Neue Einstellung „Ladezeitpunkt des Containers": sofort laden und über den Consent Mode steuern, erst nach der Einwilligung laden, oder das Laden dem Cookie-Werkzeug über Blockier-Attribute überlassen. Der bisher fest im Template verdrahtete Usercentrics-Sonderfall ist damit nur noch einer von vielen möglichen Werten
• feature: Neue Einstellung „Einwilligungssignal auswerten aus" mit einer geprüften Vorlage für Cookie Script und einer frei definierbaren Regel für jedes andere Werkzeug, das seine Entscheidung in einem Cookie oder im lokalen Speicher ablegt. Eine ungültige Regel wird verworfen und protokolliert — sie gibt niemals stillschweigend etwas frei
• feature: Cookiebot, Usercentrics und consentmanager.net werden als Einwilligungssignal direkt unterstützt — jeweils über die dokumentierte Schnittstelle des Werkzeugs statt über eine Cookie-Regel: Cookiebot über Cookiebot.consent, Usercentrics über UC_UI.getServicesBaseInfo(), consentmanager.net über __cmp('getCMPData'). Bei Usercentrics und consentmanager.net hängen Dienstnamen und Zweck-IDs vom Konto ab; die Vorgaben decken die üblichen Google-Dienste ab und lassen sich je Speicherart überschreiben. Ist im Werkzeug selbst der Google Consent Mode eingeschaltet, bleibt „Consent-Werkzeug regelt das" die bessere Wahl
• feature: Neue Schnittstelle window.wbmTagManager mit setConsent(), grantAll(), denyAll() und loadGtm(), dazu das Ereignis wbm-tagmanager:consent. Damit lässt sich auch ein Cookie-Werkzeug anbinden, das dieses Plugin nicht kennt — aus einem Customizing-Plugin, aus dem Tag Manager oder aus einem Snippet des Werkzeugs selbst
• feature: Neue Einstellung „Consent-Diagnose aufzeichnen". Sie protokolliert, welche Voreinstellung gesendet wurde, welches Signal eintraf und wann der Container geladen wurde — die drei Fragen, die man sonst nur mit Entwicklerwerkzeugen beantwortet
• feature: Neue Einstellung „Auf das Einwilligungssignal warten (Millisekunden)". Sie steuert Googles wait_for_update in der Voreinstellung, das bisher fest auf 500 ms stand. Der richtige Wert hängt am eingesetzten Cookie-Werkzeug: Liest das Plugin das Signal synchron aus einem Cookie, ist die Wartezeit sofort aufgelöst und verzögert nichts; stellt ein Consent-Werkzeug seine gespeicherte Entscheidung dagegen erst per asynchronem Script wieder her, entscheidet dieser Wert darüber, ob Analyse- und Werbe-Tags die Einwilligung überhaupt noch mitbekommen — und dafür reichen 500 ms nicht immer. Voreingestellt sind 500 ms, 0 schaltet ab, gedeckelt auf 10 Sekunden
• fix: Das Plugin schreibt keine Meldungen mehr in die Browser-Konsole. Der Shopware Store lehnt console.*-Aufrufe im ausgelieferten JavaScript ab — auch dann, wenn daneben eine korrekte Fehlerbehandlung steht. Die Diagnose bleibt vollständig erhalten: Bei gesetztem Debug-Flag laufen alle Meldungen in einen Ringpuffer (200 Einträge) unter window.wbmTagManagerDebug, abrufbar mit window.wbmTagManagerDebug.dump(), und gehen zusätzlich als Storefront-Ereignis wbmTagManagerDiagnostic heraus, an das ein Shop sein Monitoring hängen kann. Betrifft das Storefront-JS und die Consent-Diagnose gleichermaßen
• fix: Nach einer Neuinstallation misst das Plugin wieder ohne weiteres Zutun. Die neue Einstellung „Einwilligungssignal auswerten aus" startete auf „Consent-Werkzeug regelt das" — dann wertet niemand die Zustimmung aus, der Google Consent Mode bleibt dauerhaft auf „abgelehnt" und es kommen keine Daten an, ohne dass die Oberfläche einen Hinweis darauf gibt. Voreingestellt ist jetzt wieder Shopwares Cookie-Consent, wie es bis 6.7.14 der Fall war. Bestandsshops sind nicht betroffen: Die Migration schreibt für jeden bisherigen Wert eine ausdrückliche Zuordnung, Ihre Einstellung bleibt also genau so, wie Sie sie hatten
• fix: Bei eingeloggten Kunden enthielt die Datenschicht user_data nur noch {"error":"dataLayer unavailable"}, sodass E-Mail, Name, Adresse und Telefonnummer für Enhanced Conversions komplett fehlten. Die mitgelieferte Telefonnummern-Bibliothek wurde nie geladen: Der Pfad zu ihr hing an getPath(), das bei einem Shopware-Plugin das Verzeichnis der Klassendatei liefert — also src/ — während die Bibliothek als Geschwister davon unter packages/ liegt. Der Pfad zeigte damit dauerhaft ins Leere, und die Prüfung darauf schlug still fehl. Gäste waren nie betroffen, weil nur eingeloggte Kunden diese Datenschicht erhalten. Der Pfad hängt jetzt an der Plugin-Wurzel
• chore: Ein toter eslint-disable-Kommentar in der Storefront-Einstiegsdatei ist entfernt. Er schaltete eine Regel ab, die im Prüfwerkzeug des Shopware Store gar nicht geladen ist — ESLint meldete daraufhin die abgeschaltete Regel selbst als Fehler und ließ die statische Analyse des Store-Uploads scheitern
• chore: Bestehende Einstellungen übernimmt eine Migration je Verkaufskanal, das Verhalten Ihres Shops bleibt nach dem Update unverändert. Die Umstellung auf eine der neuen Betriebsarten ist eine bewusste Entscheidung, kein Nebeneffekt des Updates
• fix: Auf Inhaltsseiten ohne Produktliste wird kein leeres view_item_list mehr ausgelöst. Die dataLayer-Module hängen an der Route, und frontend.navigation.page gilt in Shopware auch für jede CMS-Seite sowie für Hersteller- und Landingpages, frontend.home.page für die Startseite. Fehlte dort der Produktlisting-Bereich, lief die Schleife über die Positionen ins Leere — das Ereignis wurde trotzdem gesendet, mit items: [] und einem Listennamen wie „Category: Über uns". Solche Ereignisse verfälschen in GA4 die Listenberichte und die Zuordnung zur Produktliste und erzeugen in Google Ads leere Remarketing-Signale. Ereignisse mit leerer Positionsliste werden jetzt bereits auf dem Server verworfen und erreichen die Seite gar nicht mehr; das gilt auch für die per Ajax nachgeladenen Listen (Filter, Sortierung, Blätterung). Ereignisse, die gar keine Positionsliste führen, bleiben unangetastet

• fix: Der Export der Datenschichten fährt keine Abfrage mehr je Datensatz und kann nicht mehr endlos laufen. Der Eigenschaftsbaum wurde rekursiv mit einer Abfrage pro Zeile durchlaufen, ohne jede Absicherung gegen Zyklen — ein Baum, in dem sich zwei Eigenschaften gegenseitig als Elternteil führen (was der Import nicht prüft und ein von Hand bearbeiteter Export leicht erzeugt), lief bis zum Speicherlimit. Der Baum wird jetzt in einer einzigen Abfrage geladen und in PHP mit einer Besucht-Liste sortiert
• fix: Der Import der Datenschichten läuft jetzt in einer Transaktion. Zuvor lag das DELETE außerhalb, jeder fehlgeschlagene Insert wurde von einem leeren catch verschluckt, und die Antwort meldete trotzdem Erfolg — ein teilweise fehlerhafter Import ließ den Betreiber ohne die alten und ohne die vollständigen neuen Daten zurück, ohne jeden Hinweis. Ein fehlgeschlagener Insert rollt jetzt den gesamten Import zurück und liefert success: false; die Antwort nennt zusätzlich die Zahl der übersprungenen Zeilen
• fix: Fehlermeldungen landen nicht mehr im dataLayer. dbquery() gab die Meldung der Exception als Wert zurück und der Renderer schrieb sie in den dataLayer — SQL- und Twig-Fehlertexte samt Tabellen-, Spalten- und Templatenamen wurden damit in das HTML jeder Storefront-Seite gerendert und waren für jeden Besucher lesbar. Fehler gehen jetzt in einen eigenen Log-Kanal wbm_tag_manager; die Storefront bekommt einen leeren Wert beziehungsweise einen neutralen Platzhalter
• feature: Der Verkaufskanal-Schalter heißt jetzt positiv Plugin für diesen Verkaufskanal aktivieren (Config-Schlüssel active, standardmäßig an) und löst das invertierte GTM-Container deaktivieren (isInactive) ab. Bestehende Einstellungen übernimmt eine Migration je Verkaufskanal — ein von Ihnen abgeschalteter Kanal bleibt abgeschaltet
• fix: Die Plugin-Rolle vergibt jetzt die Entity-Rechte, die das Admin-Modul tatsächlich abfragt (wbm_data_layer_modules, wbm_data_layer_properties, sales_channel, sales_channel_domain, system_config). Zuvor bekam ein Benutzer mit ausschließlich der Plugin-Rolle in der Modul-Liste und der Verkaufskanal-Übersicht HTTP 403 und eine leere Seite
• fix: Ein erneutes Laden der Bestellabschluss-Seite entfernt nicht mehr den Google Tag Manager. Der Dedup-Guard verließ den Render-Subscriber, bevor die Konfiguration gesetzt wurde — beim zweiten Aufruf derselben Bestellung (F5, Zurück-Taste, zweiter Tab, erneuter Payment-Return) fehlten damit das GTM-Ladescript und der noscript-iframe, der Container war also ganz weg und nicht nur das Purchase-Event. Unterdrückt wird jetzt ausschließlich der dataLayer. Zwei weitere Lücken desselben Guards sind mit behoben: Der Wechsel zwischen zwei Bestellungen und zurück zählt die erste nicht mehr doppelt (die Session merkt sich eine Liste statt einer einzelnen Bestellung), und ein fehlender orderId-Parameter legt die Seite nicht mehr für den Rest des Besuchs still
• fix: Der Warnhinweis auf der Konfigurationskarte „TagManager Script manipulieren" folgt jetzt der Sprache der Administration. Er war als mt-banner-Komponente mit -Elementen je Sprache in der config.xml deklariert; Shopwares ConfigReader behandelt title an Komponenten-Kindern aber nicht als übersetzbar — es blieb nur der zuletzt deklarierte Wert übrig, weshalb jeder Betreiber niederländischen Text sah. Dieselbe Rekursion ersetzte zusätzlich die Kartenüberschrift durch den Bannertext. Der Hinweis wird nun von einer eigenen Admin-Komponente mit Snippets in DE/EN/NL gerendert
• fix: Beim Ereignis AfterLineItemAdded wird für Positionen ohne Produktnummer im Payload nicht mehr je Position eine eigene Abfrage gefahren — die IDs werden gesammelt und in einer einzigen Abfrage aufgelöst
• chore: Import und Export in der Administration laufen jetzt über einen registrierten ApiService statt über einen handgebauten Bearer-Header, der nach einem Token-Refresh nicht mehr griff
• fix: Der Import der Datenschichten meldet jetzt, wenn er nicht funktioniert hat. Der Controller antwortet auf jede Ablehnung — falscher Dateityp, kaputtes JSON, zurückgerollte Transaktion — mit HTTP 200 und success: false, und niemand wertete das aus: der Import sprang zurück zur Übersicht und meldete Erfolg, auch wenn nichts übernommen wurde. Eine abgelehnte Datei nennt jetzt ihren Grund, übersprungene Zeilen werden gemeldet, und ein fehlgeschlagener Request (403, 413, 500) erzeugt eine Fehlermeldung statt gar nichts. Der Export ist genauso nachgezogen
• fix: Die Übersicht der Container-IDs lädt nicht mehr endlos, wenn ein einzelner Verkaufskanal nicht lesbar ist. Die Fertigmeldung hing an einem Zähler über einen Request je Kanal; ein einziger fehlgeschlagener Request ließ die Seite dauerhaft im Ladezustand. Die Requests laufen jetzt über Promise.all(), der Ladezustand endet im finally, und ein nicht lesbarer Kanal fällt auf die globalen Werte zurück, damit die Übersicht vollständig bleibt
• fix: Die Übersicht der Container-IDs zeigt jetzt alle Verkaufskanäle. Die Abfrage lief ohne ausdrückliches Limit und damit mit dem Administrations-Standard von 25 — Shops mit mehr Verkaufskanälen sahen stillschweigend eine unvollständige Liste
• fix: Die Benachrichtigung in der Administration nach einem Plugin-Update erscheint jetzt in der Sprache der Oberfläche statt für jeden auf Englisch
• chore: Die fünf @-Fehlerunterdrückungen in TagManagerExtension und DataLayerRenderer sind durch ausdrückliche Typ- und Existenzprüfungen ersetzt. Eine davon verdeckte einen zweiten Defekt: fehlte die referencedId im Request, schrieb getparam('lineItems') den Konfigurations-Hash in einen Schlüssel namens "" statt in die Position
• security: Die GTM-Container-ID, die eigene Tag-Manager-URL und der URL-Zusatzparameter werden geprüft, bevor sie in der Storefront ankommen. Alle drei landeten ungeprüft in einem JavaScript-String bzw. in einem src-Attribut. Ein Benutzer mit system_config:update — in Betreiber-Rollen breit vergeben und ausdrücklich kein Entwicklerrecht — konnte als Container-ID x'; alert(document.cookie); // eintragen und damit dauerhaft eigenes JavaScript auf jeder Storefront-Seite ausliefern (Rechteausweitung zu persistentem XSS). Die Container-ID muss jetzt GTM- plus Großbuchstaben und Ziffern sein, die Tag-Manager-URL eine http(s)-Adresse ohne Query, und der Zusatzparameter ist auf den Zeichenvorrat echter URL-Parameter begrenzt. Ein verworfener Wert geht in den Log-Channel wbm_tag_manager, und das Tracking bleibt aus, statt ungeprüften Code auszuliefern. Die Prüfung sitzt in DataLayerModules, nicht in den Templates — derselbe Wert wird an mehreren Stellen und in verschiedenen Kontexten ausgegeben
• chore: Die drei verbliebenen console.error des Ajax-Interceptors beachten jetzt den Debug-Schalter und sind auf Englisch mit dem Präfix [WbmTagManagerAnalytics] formuliert, wie jede andere Diagnose-Ausgabe seit 6.7.13. Shop-Besucher lasen vorher deutschen Fehlertext in der Browser-Console eines englischen Shops; die Meldung hilft ausschließlich beim Debuggen, und genau dafür gibt es den Schalter
• fix: Der Eigenschaftsbaum meldet jetzt, wenn ein Modul mehr Eigenschaften hat als er anzeigt. Er lädt höchstens 500 Einträge — sinnvoll, weil ein Baum ohne Grenze bei einem verunglückten Import beliebig viele Datensätze in den Browser zieht —, tat das aber stillschweigend, was wie Datenverlust aussah. Die Gesamtzahl wird jetzt mitgelesen und in einer Warnung benannt
• chore: Die Dependency-Injection-Konfiguration liegt jetzt in YAML statt XML (services.yaml plus die vier Dateien unter config/services/). Die Aufteilung nach Zuständigkeit bleibt unverändert. Shopware lud beide Formate, zur Laufzeit ändert sich also nichts — das Plugin folgt jetzt der aktuellen Konvention
• fix: Die Export-Route liefert jetzt korrekt kodiertes JSON. new JsonResponse(json_encode(...)) kodierte ein zweites Mal, der Antwortkörper war damit ein JSON-String, der JSON enthält. Die heruntergeladene Datei war nie betroffen — Axios parste einmal, und genau der richtige String landete darin —, aber jeder andere Konsument der Route (curl, Skript, Monitoring) musste zweimal parsen, und wer die rohe Antwort in eine Datei schrieb, bekam etwas, das der Import ablehnte. Der Admin-Download übernimmt den Körper jetzt ungeparst, die Datei ist dadurch byteweise dieselbe wie vorher. Ein fehlgeschlagenes Kodieren liefert außerdem keine Datei mit dem Inhalt false mehr, sondern wird protokolliert und gemeldet
• fix: Der Warenkorb-Subscriber holt die Session aus dem laufenden Request, statt im Konstruktor eine neue zu erzeugen. SessionFactoryInterface::createSession() ist eine Fabrik — sie erzeugt eine neue, leere Session und fragt nicht, ob es schon eine gibt. Im Storefront-Request ging das gut, aber der Subscriber hängt an einem Warenkorb-Ereignis, nicht an einem HTTP-Ereignis: ein MessageHandler, ein CLI-Befehl oder ein Import, der Positionen setzt, löst ihn ganz ohne Request aus. Dieser Fall wird jetzt erkannt und übersprungen, statt sich darauf zu verlassen, dass Symfony nachträglich eine Session verdrahtet

• feature: Storefront-Console-Diagnosen sind jetzt hinter einem Opt-in-Debug-Flag versteckt — Meldungen wie „no items found in dataLayer" und abgefangene Click-Tracking-Fehler werden nur noch ausgegeben (mit Prefix [WbmTagManagerAnalytics]), wenn im Browser localStorage.setItem('wbmTagManagerDebug', '1') gesetzt ist; Shop-Besucher sehen unabhängig vom DevTools-Log-Level keine Console-Ausgaben mehr. Echte Verarbeitungsfehler des Ajax-Interceptors bleiben als console.error sichtbar. Siehe README-Abschnitt „Debug-Modus (Console-Diagnose)"
• fix: cartnetprice liefert nun einen korrekten Netto-Preis für Nicht-Produkt-Warenkorbpositionen (Promotion/Gutschein, Container, product-with-options, custom) — zuvor wurde 0 zurückgegeben, was Storefront-Templates mit der Steuersatz-Berechnung (cartremoveprice(id) / cartnetprice(id) - 1) * 100 durch eine Division durch null zerstörte. Das Netto wird jetzt aus dem kalkulierten Positionspreis abgeleitet (Brutto − Steueranteil) und berücksichtigt den Steuerstatus (Brutto/Netto/steuerfrei); nur echte Produktpositionen beziehen ihr Netto weiterhin aus der Produkt-Preisliste
• fix: Ajax-getriebene Listing-Aktualisierungen (Kategorie-/Such-Filter, Sortierung, Pagination) pushen ihr view_item_list wieder in den dataLayer — das GA4-Event ging zuvor verloren, weil der onEvent-Zweig des Interceptors durch ein nie gesetztes window.WbmDataLayer blockiert war
• fix: „Ambiguous class resolution"-Autoload-Warnung für die mitgelieferte libphonenumber-Bibliothek behoben, wenn ein anderes Plugin (z. B. Meta-/Facebook-Pixel) ebenfalls giggsey/libphonenumber-for-php mitbringt. Die gebündelte Kopie wird nicht mehr im Composer-Autoload des Projekts registriert, sondern über einen beim Plugin-Boot angehängten Class-Loader geladen — eine bereits vorhandene Kopie hat damit immer Vorrang, unsere dient nur als Fallback
• chore: mitgelieferte giggsey/libphonenumber-for-php-lite auf 9.0.34 aktualisiert

• feature: Nach jeder Consent-Änderung (initiales Opt-in über das Cookie-Banner sowie spätere Anpassungen) wird ein benanntes dataLayer-Event wbm_consent_update gepusht, sodass GTM einen GA4 page_view im selben Seitenaufruf auslösen kann — behebt den Verlust der ursprünglichen Einstiegsquelle nach dem Opt-in
• fix: Subscriber reagiert nun auch, wenn ausschließlich google-analytics-enabled oder google-ads-enabled geschaltet werden (zuvor wurde nur ausgelöst, wenn wbm-tagmanager-enabled Teil des Update-Deltas war)
• fix: Fehlerhafte Prüfung typeof script === 'undefined' ersetzt (getElementById liefert null); unerreichbare Leer-Update-Prüfung entfernt; Cookie-Consent-Subscriber für bessere Lesbarkeit refaktoriert

• feature: Storefront-Console-Diagnosen sind jetzt hinter einem Opt-in-Debug-Flag versteckt — Meldungen wie „no items found in dataLayer" und abgefangene Click-Tracking-Fehler werden nur noch ausgegeben (mit Prefix [WbmTagManagerAnalytics]), wenn im Browser localStorage.setItem('wbmTagManagerDebug', '1') gesetzt ist; Shop-Besucher sehen unabhängig vom DevTools-Log-Level keine Console-Ausgaben mehr. Echte Verarbeitungsfehler des Ajax-Interceptors bleiben als console.error sichtbar. Siehe README-Abschnitt „Debug-Modus (Console-Diagnose)"
• fix: cartnetprice liefert nun einen korrekten Netto-Preis für Nicht-Produkt-Warenkorbpositionen (Promotion/Gutschein, Container, product-with-options, custom) — zuvor wurde 0 zurückgegeben, was Storefront-Templates mit der Steuersatz-Berechnung (cartremoveprice(id) / cartnetprice(id) - 1) * 100 durch eine Division durch null zerstörte. Das Netto wird jetzt aus dem kalkulierten Positionspreis abgeleitet (Brutto − Steueranteil) und berücksichtigt den Steuerstatus (Brutto/Netto/steuerfrei); nur echte Produktpositionen beziehen ihr Netto weiterhin aus der Produkt-Preisliste
• fix: Ajax-getriebene Listing-Aktualisierungen (Kategorie-/Such-Filter, Sortierung, Pagination) pushen ihr view_item_list wieder in den dataLayer — das GA4-Event ging zuvor verloren, weil der onEvent-Zweig des Interceptors durch ein nie gesetztes window.WbmDataLayer blockiert war
• fix: „Ambiguous class resolution"-Autoload-Warnung für die mitgelieferte libphonenumber-Bibliothek behoben, wenn ein anderes Plugin (z. B. Meta-/Facebook-Pixel) ebenfalls giggsey/libphonenumber-for-php mitbringt. Die gebündelte Kopie wird nicht mehr im Composer-Autoload des Projekts registriert, sondern über einen beim Plugin-Boot angehängten Class-Loader geladen — eine bereits vorhandene Kopie hat damit immer Vorrang, unsere dient nur als Fallback
• chore: mitgelieferte giggsey/libphonenumber-for-php-lite auf 9.0.34 aktualisiert
• feature: Nach jeder Consent-Änderung (initiales Opt-in über das Cookie-Banner sowie spätere Anpassungen) wird ein benanntes dataLayer-Event wbm_consent_update gepusht, sodass GTM einen GA4 page_view im selben Seitenaufruf auslösen kann — behebt den Verlust der ursprünglichen Einstiegsquelle nach dem Opt-in
• fix: Subscriber reagiert nun auch, wenn ausschließlich google-analytics-enabled oder google-ads-enabled geschaltet werden (zuvor wurde nur ausgelöst, wenn wbm-tagmanager-enabled Teil des Update-Deltas war)
• fix: Fehlerhafte Prüfung typeof script === 'undefined' ersetzt (getElementById liefert null); unerreichbare Leer-Update-Prüfung entfernt; Cookie-Consent-Subscriber für bessere Lesbarkeit refaktoriert

• fix: admin nl.json parse error

• fix: Uncaught PHP Exception TypeError: SalesChannelContextServiceDecorator

• Korrektur: „add_to_wishlist“ – Probleme beim Hinzufügen behoben; funktioniert nun auch im Warenkorb und im Off-Canvas-Modus
• Korrektur: Vorheriges E-Commerce-Objekt löschen
• Korrektur: Versand-/Zahlungsereignis
• Neu: Rückerstattungsereignis hinzufügen
• Neu: Anfragen ohne HTML-Antwort können nun nach Post-Optionen verfolgt werden

Bugfix: Cookieconsent in Verbindung mit 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.

Anpassung an Shopware 6.7.1

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

Anpassung an 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

• Warnung „Nicht-numerischer Wert gefunden“ in SessionUtility behoben
• „foreach“-Warnungen behoben und Array-Typen nach json_decode sichergestellt

• 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

Rückwirkende Freigabe für ältere Shopversionen

Fix: Google Analytics

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

Bugfixes:

• kleinere Fehler z. B. Subset

Feature:

• Zusammenarbeit mit Produktkonfigurator (BuI)
• erweitertes 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

Anpassung an Shopware 6.6.0.2

- Neu: Integration Consense Mod V2

- Rebranding von Webmatch auf BuI Hinsche GmbH

- Anpassung Versionierung an BuI Versionierung

- Neu: NoSkript URL individuell anpassbar

# 5.2.5

* fix: Performanceoptimierung auf Produktlisten durch Reduzierung der Datenbankabfragen aus Twig

* fix: Cookie-Consent-Option unterstützt jetzt eindeutige Container-IDs für mehrere Verkaufskanäle

# 5.2.4

* fix: storefront neu kompiliert - Kompatibilität zum Horizon Theme

# 5.2.3

* fix: JavaScript neu kompiliert

# 5.2.2

* fix: verhindere JS-Fehler in Listings

# 5.2.1

* feature: "add_to_wishlist" auf Produktdetailseite hinzugefügt

* fix: "add_to_wishlist" mit langen Produktlistings

* fix: update Hilfetext für Kofigurationsoption

# 5.2.0

* Feature: Twig-Funktion „dbquery“ ersetzen

* Fix: Korrekter Betrag für „add-to-cart“, wenn die Produktmenge > 1 ist

* Fix: Korrekter Betrag für "remove-from-cart"", wenn die Produktmenge > 1 ist

# 5.1.0

* Fix: Codierung von benutzerdefiniertem Google Tagmanager-Code verhindern

* Fix: SalesChannel aus Request abrufen

* Fix: JS-Bedingung für Klick-Tracking optimieren

* Fix: Datalayer-Klasse vom Plugin in die Utils verschieben

* Fix: „select_item“ nicht auf dem Symbol „Zur Wunschliste hinzufügen“ verfolgen

* Funktion: Option hinzufügen, um die Nachverfolgung von „Zur Wunschliste hinzufügen“ zu aktivieren

# 5.0.1

* Promobanner im Admin geupdated

# 5.0.0

* Kompatibilität mit SW 6.5 hergestellt 

# 4.2.3

* fix: Performanceoptimierung auf Produktlisten durch Reduzierung der Datenbankabfragen aus Twig

* fix: Cookie-Consent-Option unterstützt jetzt eindeutige Container-IDs für mehrere Verkaufskanäle

# 4.2.2

* fix: verhindere Fehler in Listings

# 4.2.1

* feature: "add_to_wishlist" auf Produktdetailseite hinzugefügt

* fix: "add_to_wishlist" mit langen Produktlistings

* fix: update Hilfetext für Kofigurationsoption

# 4.2.0

* Feature: Twig-Funktion „dbquery“ ersetzen

* Fix: Korrekter Betrag für „add-to-cart“, wenn die Produktmenge > 1 ist

* Fix: Korrekter Betrag für "remove-from-cart"", wenn die Produktmenge > 1 ist

# 4.1.0

* Fix: Codierung von benutzerdefiniertem Google Tagmanager-Code verhindern

* Fix: SalesChannel aus Request abrufen

* Fix: JS-Bedingung für Klick-Tracking optimieren

* Fix: „select_item“ nicht auf dem Icon „Zur Wunschliste hinzufügen“ tracken

* Funktion: Option hinzugefügt, um das Tracking von „Zur Wunschliste hinzufügen“ zu aktivieren

# 4.0.4

* fix: verhindere einen Fehler durch die "columnExists"-Fuktion in der Migration

* fix: Hole die ID vom "customer", anstatt vom Context

Initialer Release der offiziellen Nachfolge des beliebten Plugins “Google Tag Manager & Google Analytics Enhanced E-Commerce Tracking für Shopware 6” (https://store.shopware.com/wbm1713539203085f/google-tag-manager-google-analytics-enhanced-e-commerce-tracking-fuer-shopware-6.html)