Man ist doch immer wieder überrascht, was sich Shopware für Gemeinheiten ausdenkt.
Es war mal möglich, im Frontend den Newsletter-Status des eingeloggten Nutzers abzufragen – hat er einen Newsletter abonniert oder nicht. Nicht ganz unwichtig, um z. B. gezielt einen Newsletter-Butten einzublenden, über den der Nutzer auf eine Newsletter-Seite gelangt.
Als Grund den Datenschutz anzugeben, finde ich seltsam, weil ich ja immer noch eine ganze Menge an Informationen über den Nutzer abfragen kann.
Man kommt mit Bordmitteln auch wirklich nicht an diesen einfachen Status heran.
Shopware stellt diese Information im Standard-Twig-Kontext nicht bereit (Zugriff gesperrt).
Selbst über den Flow Builder ist es nicht möglich. Ich kann z. B. kein Zusatzfeld beeinflussen, sobald der Nutzer das Newsletter-Abonnement bestätigt hat.
Dabei lässt die DSGVO durchaus Spielraum.
Wichtige Voraussetzungen:
Die Information über den Newsletter-Status darf nur dem jeweiligen eingeloggten Nutzer angezeigt werden, nicht anderen Nutzern oder Dritten.
Die Anzeige muss im Rahmen der berechtigten Interessen des Nutzers erfolgen, etwa damit er seinen Status selbst verwalten oder ändern kann.
Es muss sichergestellt sein, dass die Daten sicher verarbeitet und nicht unbefugt weitergegeben werden.
Die Nutzer müssen über die Verarbeitung ihrer Daten im Rahmen der Datenschutzerklärung informiert werden.
Wie seht ihr das? Oder Shopware, falls jemand von den Entwicklern gerade mitliest?
Irgendwie ziemlich schräg einen Bezug zwischen der DSGVO und dem Newsletter-Anmeldungsstatus herzustellen. Woher hast du denn diese Informationen?
In Shopware 6 ist das Thema Newsletter rudimentär implementiert, da eine nicht zu vernachlässigende Anzahl an Onlineshop-Betreiber Newsletter über externe Dienste handhaben.
Die Informationen sind definitiv in der Storefront verfügbar, da unter /account die Checkbox nach der Anmeldung ein checked Status hat, und ohne Anmeldung fehlt dieser.
Durch Ausprobieren.
Es gibt das Array „context.customer.newsletterSalesChannelIds“.
Das ist null, wenn kein Newsletter abonniert ist (ist also nur für eingeloggte Nutzer interessant).
Wenn ein eingeloggter Nutzer einen Newsletter abonniert hat, ist das Array gefüllt.
Fragt man jedoch das Array z. B. nach „is empty“ ab, dann bekommst du keine sinnvolle Antwort, weil der Zugriff für „context.customer.newsletterSalesChannelIds“ gesperrt ist.
Ich hatte dazu auch noch ChatGPT und Perplexity gefragt, die das beide bestätigt haben.
Genau das hatte ich dann auch gedacht, aber Shopware ist hier scheinbar sehr gründlich gewesen.
Fazit laut Perplexity:
Shopware 6 holt sich die Information, ob das Newsletter-Häkchen „checked“ ist, immer aus der Datenbank (Tabelle newsletter_recipient) und stellt sie dem Frontend gezielt bereit – entweder über einen API-Endpunkt oder Controller, der den Status prüft und an die Seite übergibt. Im Standard-Twig-Kontext ist diese Info nicht ohne weiteres zugänglich, sondern wird speziell für die Account-Seite aufbereitet und ausgeliefert.
Das habe ich allerdings noch nicht selbst überprüft. Gut möglich, dass sich die KI irrt.
Per Subscriber ist das natürlich möglich, aber kann das Sinn der Sache sein? Am besten gleich ein eigenes Plugin schreiben bei solchen mini-Tasks.
Ich arbeite jetzt seit 2 Jahren mit Shopware 6 und ich kann das Wort „Subscriber“ schon nicht mehr hören.
Es sollte doch im Sinne von Shopware sein, bei rudimentären Tasks eine schnelle Lösung maximal über Twig-Anpassungen erzielen zu können. Und wenn möglich, sollte der Flow Builder das hinbekommen.
Das eine hat mit dem anderen nichts zu tun.
Der gängige Weg in SW6 ist, dass man die Newsletter-Empfänger über die SW6-seitige Logik (Formular, Registrierung,…) erfasst. Und im 2. Schritt sucht man sich einen passenden Newsletter-Dienstleister raus, installiert das entsprechende Plugin und synchronisiert die SW6-Newsletter-Empfänger mit dem externen Newsletter-Tool. So läuft das zumindest bei CleverReach, Brevo, usw.
Mir ging es aber auch wirklich nur um die ganz triviale Information: hat der Nutzer den Newsletter abonniert? ja/nein.
Das ist so trivial wie Anrede, Name, Adresse, usw. Das ist halt eine ziemlich zentrale Information in SW6. Mit der gleichen Logik, nicht auf diese Info zugreifen zu „dürfen“, könnte man auch verbieten, auf alle anderen Daten des Nutzers zuzugreifen. Deshalb meine Verwunderung, dass SW6 das trotzdem so handhabt (und auch nicht schon immer – in früheren SW6-Versionen war die Information ja abrufbar).
Und zur Performance: die Information ist ja ohnehin vorhanden. Man sieht sie ja im Dump. Man darf sie lediglich nicht verwenden. Natürlich sollen nicht jederzeit alle möglichen Variablen verfügbar sein, aber wie oft habt ihr euch schon geärgert, dass eine bestimmte Variable in einem bestimmten Kontext nicht verfügbar ist, obwohl es mehr als logisch wäre, dass sie verfügbar ist?
