endereco / endereco-shopware5-client Goto Github PK

Problembeschreibung

Manchmal wird nach der Installation des Plugins keine Doctrine Model in var/cache Verzeichnis generiert. Das führt dazu, dass manche Prozesse im Shop nicht mehr gehen.
Z.B. können keine eMails mehr versendet werden oder der Export funktioniert nicht.

Gewünschte Lösung
Das Plugin soll Shopware()->Models()->generateAttributeModels nutzen, um die Modelle neu zu generieren. Das soll sowohl nach der Installation, als auch bei der Deinstallation erfolgen.

Problem
Bei dynamischen Adressformularen wird beim Absenden die ADressprüfung doppelt ausgeführt. Das führt dazu, dass auch das Adressmodal doppelt angezeigt wird, was die Nutzer verwirrt.

Gewünschte Lösung

Es soll nur eine Adressprüfung ausgelöst werden und folglich soll auch nur ein Modal angezeigt werden.

IN der Readme.md soll eine ausführliche und beispielreiche (Screenshots) Installationsanleitung geschrieben werden. Nicht vergessen den Fall eines Wechsels zwischen Store und GitHub Version.

Bei relativ langsamen Internetverbindung wird manchmal das Standardland gesetzt, obwohl ein Land davor schon ausgewählt war.

Das liegt daran, dass die Prüfung ob ein Land ausgewählt ist gegen AdressObject läuft und zeitlich vor dem Auslesen des Wertes in HTML Element geschieht. D.h. für die Standardland Prüfung ist kein Land gesetzt, obwohl dieser einige Millisekunden später gesetzt wird.

Es gab eine Meldung, dass dieser Fehler im Log produziert wurde:

directory /custom/plugins/EnderecoShopware5Client/Resources/views/frontend/index/index.tpl' not allowed by security setting

Shopsystem: Shopware 5.6.9

Ursache: im Moment noch unklar.

Schritte um der Fehler zu reproduzieren: im Moment noch unklar

Was genau ist das Problem?

In Shopware 5.7.* gibt es in der Logger Komponente keine "addError" Methode. Das bricht die aktuelle Umsetzung des Loggers.

Gewünschte Lösung

Es soll stattdessen mit "addRecord" gearbeitet werden, da diese Methode in 5.3 - 5.7 vorhanden ist.

Durch das HB Rechtstexte Modul kann an manchen Stellen der endereco-API-Key nicht mehr gelesen werden und somit können manche Requests nicht aufgerufen werden. Das betrifft die doAccounting und doConversion Requests. Damit ist es unmöglich abrechenbare Sessions dem Kunden in Rechnung zu stellen.

Es reicht das HB Rechtstexte Modul zu installieren um das Problem zu verursachen. Erst nach der deinstallation und cache löschen funktionieren die Requests wieder.

Eine Mögliche Lösung ist, unser api key in endereco api key umzubenennen jedoch müssen hier alle Kunden informiert werden.

Anlass:

Wenn die Funktion “Straße in Straßenname und Hausnummer unterteilen” aktiv ist, dann gibt es eine Verzögerung zwischen der Anzeige der Adresseingabemaske und dem Erscheinen von Inhalt in der Straße und Hausnummer.

Die Maske wird sofort mit den Feldern für Straßenname und Hausnummer angezeigt, aber es dauert einige Sekunden bis Endereco JS geladen wird, bis die unsichtbare volle Straße ausgelesen wird, bis ihre Daten an die API übermittelt werden, bis eine geteilte Straße zurückkommt und die Teile in ihre Felder geschrieben werden.

Soll die API temporär nicht erreichbar sein, so wird die Straße nicht getrennt. Außerdem wird ein Implementierungsfehler in der Splittingfunktion dazu führen, dass vorher bereits korrekt getrennte Straße falsch getrennt wird.

Lösungskonzept:

Die getrennte Straße soll dauerhaft gespeichert werden. Dafür sollen zwei weitere Attribute für eine Adresse angelegt werden: enderecostreetname, enderecobuildingnumer. Die Inhalte aus diesen Feldern sollen beim initialen Laden der Seite in HTML geschrieben werden.

Wird eine Adresse gespeichert, so sollen auch die Inhalte in diesen Feldern in der DB gespeichert werden. Somit wird keine zukünftige Trennung der Straße notwendig.

Prüfung der Implementierung:

Vorausgesetzt Straßenteilung ist aktiv.

1. Beim Laden der Adressseite sollen die Straße und Hausnummer sofort sichtbar sein.
2. Beim Speichern der Adresse sollen Straßenname und Hausnummer in den Attributen der Adresse abgelegt werden.
3. Beim Aktualisieren der Adresse soll sowohl die volle Straße als auch Straßenname und Hausnummer in der Maske und in DB aktualisiert werden.

Vorausgesetzt Straßenteilung ist inaktiv.

1. Beim Laden der Adressseite sollen Straßenname und Hausnummer unsichtbar sein, als hidden inputs.
2. Eingabe der Straße soll die Straßenteilung auslösen und die Werte in unsichtbaren Straßenname und Hausnummerfelder ablegen.
3. Aktivieren der Straßenteilung Funktion soll die Adressmaske nicht unbrauchbar machen, Straße und Hausnummer sollen sichtbar sein, Zusammenbauen der vollen Straße soll weiterhin funktionieren.

Das Plugin soll nach dieser Anpassung mit DHL Wunschpaket Plugin kompatibel bleiben.

Was genau ist das Problem?

Eine Adresse mit dem Status "nicht gefunden" kann im Checkout nicht gespeichert werden, nachdem der User diese bestätigt.

Was wäre das erwartete Verhalten?

Eine "nicht gefundene" und vom User "bestätigte Adresse" soll gespeichert werden.

Wie kann man das Problem reproduzieren?

Ich hatte im Checkout eine nicht existierende Rechnungsadresse hinterlegt und habe diese verändert, indem ich einen Buchstaben bei der Straße ergänzt habe.

Dieser Fehler tritt auch beim Ändern der Lieferadresse auf. Aber nicht beim Anlegen einer Lieferadresse.

Man kann das Verhalten nur reproduzieren, indem man die Adresse durch den Speicherbutton prüft. Wenn man die Adressfelder verlässt und dadurch geprüft wird funktioniert die Prüfung wie gewünscht.

Bei Bestandskundenprüfung und eventuell bei sonstigen Anfragen, die "im HIntergrund" passieren, wird im referer Feld der Klassenname übermittelt: EnderecoShopware5Client\Services\EnderecoService.php

Dieser Klassenname ist sowohl bei GitHUb Version, als auch bei Store Version gleich.

Da wir neulich einen referer Filter einsetzen, brauchen wir eindeutige referer die:

1. Zwischen Testumgebung und Liveumgebung unterscheiden
2. Einheitlich strukturiert sind

Gewünschte Lösung:
Auch bei serverseitigen Anfragen, die im EnderecoService generiert werden, soll als referer der aktuelle URL der Seite übermittelt werden. Anhand von diesem URL kann man zwischen Testumgebung und Livesystem unterscheiden. Da Anfragen aus dem Frontend die URL bereits erhalten, wird somit auch die Einheitlichkeit sichergestellt.

Bei manchen Anfragen wird sowohl in Store Version, als auch in GitHub Version des Plugin der gleiche Client Info übermittelt.
Das ist ein Problem, weil dadurch zwischen Store Version und GitHub Version nicht unterschieden werden kann, was die Nutzungsreports unbrauchbar macht.

Gewünschte Lösung: Client Info reparieren

Fehlerbeschreibung

Wenn in einem aktiven Land ein Apostroph vorkommt, wird es nicht korrekt in die Konfiguration übernommen.

Zum Beispiel:

window.EnderecoIntegrator.countryCodeToNameMapping = JSON.parse('{"DE":"Deutschland","BE":"Belgien","AT":"\u00d6sterreich","CI":"C\u00f4te d'Ivoire "}');

Im Browser wird dabei die Meldung Uncaught SyntaxError: missing ) after argument list ausgegeben.

Gewünschte Lösung
Apostroph isolieren.

Diesen Bug kann man wie folgt reproduzieren:

1. Endereco Modul ist deaktiviert

2. Ein Kunde Registriert sich mit einer Rechnungsadresse, bei der endereco 1 Vorschlag liefern wird

3. Endereco Modul aktivieren (Bestandskundenprüfung aktivieren und die Straße/HN nicht teilen)

4. Dieser Kunde meldet sich erneut an → Adresse wird geprüft

5. Bestandskundenprüfung deaktivieren

6. Der Kunde legt etwas in den Warenkorb und geht zur Kasse

7. Jetzt wird der Dialog geöffnet, sodass der Kunde seine Adresse bearbeiten kann. Aber es wird kein Vorschlagdialog angezeigt.

8. Der Kunde geht ohne Änderung auf speichern

9. Der Dialog schließt sich und öffnet sich erneut

Der Konfigurations JS des Plugins wird in header.tpl im Block frontend_index_header_javascript_tracking mittels append hinzugefügt.

Das führt zu Problemen mit anderen Plugins, die das gleiche Block erweitern.

Als Lösung soll das "append" entfernt werden. Stattdessen soll einfach das "{$smarty.block.parent}" vor unserem Code gesetzt werden. Das soll die Probleme mit anderen Plugins lösen.

Ist: Aktuell laden wir das JS von unserem Modul auf jeder Seite. Das führt zu etwas schlechteren Performance auf den Seiten.

Gewünschte Lösung: eine einstellbare Whitelist für controller, über die man einstellen kann, auf welchen Seiten das JS ausgespielt werden darf.

Anlass

Viele unserer Kunden nutzen PayPal Express Checkout. Die Adressdaten werden dabei nicht eingegeben, sonder von PayPal direkt ins Shopware kopiert. Dadurch wird unsere Adressprüfung übersprungen. Wir würden somit eventuell fehlerhafte Adressen zulassen.

Gewünschte Lösung

Unser Plugin soll ein aktivierbares Feature “PayPal Express Adressen prüfen (BETA)” haben. Der Shopbetreiber kann dieses Feature aktivieren und dann werden seine PayPal Express Kunden geprüft. Der Kunde kommt auf die letzte Checkoutseite, wird hinter den Kulissen geprüft und bekommt eventuell ein Modal mit Adressänderung vorgeschlagen.

Was genau ist das Problem?

Aktuell werden doAccounting erst beim Anlegen oder Speichern eine Adresse abgesendet werden. Falls beim Absenden der Form jedoch ein Validationsfehler kommt, dann wird keine Adresse gespeichert und somit geht die Session verloren, obwohl die Adresse geprüft worden war.

Wieso ist das wichtig?

Dadurch ist unser Konzept der erfolgsbasierten Abrechnung nicht korrekt umgesetzt und unsere statistische Auswertung der Nutzung liefert falsche Zahlen.

Was wäre das erwartete Verhalten?

Die doAccounting sollen beim Absenden der Form produziert werden, unabhängig davon, ob sonstige Werte in der Form korrekt oder falsch sind. Da eine richtig eingegebene Adresse das zweite Mal nicht geändert wird, besteht keine Gefahr der doppelten Abrechnung.

Wie kann man das Problem reproduzieren?

Beim Absenden der Form soll ein Fehler gemacht werden, der die Frontendvalidierung besteht, bei der Server Validierung jedoch einen Fehler verursacht. Man landet somit nach dem Absenden auf der gleichen Seite und die vorhin übermittelte Session geht verloren.

Aktuell erscheint bei der Installation folgende Fehlermeldung:

Ups! Ein Fehler ist aufgetreten! Die nachfolgenden Hinweise sollten Ihnen weiterhelfen. The "endereco_shopware5_client.subscriber.frontend" service or alias has been removed or inlined when the container was compiled. You should either make it public, or stop using the container directly and use dependency injection instead. in vendor/symfony/dependency-injection/Container.php on line 275 Stack trace: #0 vendor/symfony/dependency-injection/Container.php(231): Symfony\Component\DependencyInjection\Container->make() #1 engine/Shopware/Components/DependencyInjection/Container.php(210): Symfony\Component\DependencyInjection\Container->get() #2 engine/Shopware/Components/DependencyInjection/Container.php(134): Shopware\Components\DependencyInjection\Container->doLoad() #3 engine/Shopware/Components/ContainerAwareEventManager.php(191): Shopware\Components\DependencyInjection\Container->get() #4 engine/Shopware/Components/ContainerAwareEventManager.php(138): Shopware\Components\ContainerAwareEventManager->lazyLoad() #5 engine/Library/Enlight/Event/EventManager.php(213): Shopware\Components\ContainerAwareEventManager->getListeners() #6 engine/Library/Enlight/Controller/Action.php(197): Enlight_Event_EventManager->notify() #7 engine/Library/Enlight/Controller/Dispatcher/Default.php(478): Enlight_Controller_Action->dispatch() #8 engine/Library/Enlight/Controller/Front.php(228): Enlight_Controller_Dispatcher_Default->dispatch() #9 engine/Shopware/Kernel.php(189): Enlight_Controller_Front->dispatch() #10 vendor/symfony/http-kernel/HttpCache/SubRequestHandler.php(85): Shopware\Kernel->handle() #11 vendor/symfony/http-kernel/HttpCache/HttpCache.php(477): Symfony\Component\HttpKernel\HttpCache\SubRequestHandler::handle() #12 engine/Shopware/Components/HttpCache/AppCache.php(261): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward() #13 vendor/symfony/http-kernel/HttpCache/HttpCache.php(267): Shopware\Components\HttpCache\AppCache->forward() #14 engine/Shopware/Components/HttpCache/AppCache.php(102): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass() #15 shopware.php(122): Shopware\Components\HttpCache\AppCache->handle() #16 {main}  

Die Nutzung des Plugin im 5.7 ist somit nicht möglich.

Was genau ist das Problem?

Ein Kunde der über PayPal Express bestellt wird mit Adressprüfung geprüft. Im Checkout sieht er dann ein Adresskorrekturmodal, falls seine Adresse Fehler hat. Ändert er dabei die Adresse, kann der Käuferschutz erlöschen. Somit bekommt Shopbetreiber im Konfliktfall ein Problem → Endereco haftet eventuell.

Wieso ist das wichtig?

Es können für Endereco Schadensersatzansprüche seitens Sohpbetreiber entstehen (wegen verlorenem Käuferschutz z.B.)

Was wäre das erwartete Verhalten?

PayPal Express Kunden sollen nicht geprüft werden.

Wie kann man das Problem reproduzieren?

Mit PayPal Express und aktiver Bestandskundenprüfung bestellen. Auf der bestellbestätigungsseite im Checkout kommt das Modal mit Adresskorrektur (wenn Adrese fehler hatte). In der Datenbank internal_log ist ein AdressCheck zu sehen.

In der endereco.js Datei gibt es den Code:

if (window.EnderecoIntegrator) {
    window.EnderecoIntegrator = merge(window.EnderecoIntegrator, EnderecoIntegrator);
} else {
    window.EnderecoIntegrator = EnderecoIntegrator;
}

hier wird der frisch erstelle EnderecoIntegrator mit dem eventuell bereits vorhandenen EnderecoIntegrator überschrieben. Sinn dieser Operation ist, die Möglichkeit auf diese Weise bestimmte einstellungen zu überschreiben.

Das Problem ist jedoch die Reihenfolge der Argumenten. window.EnderecoIntegrator (der eventuell neuere Sachen enthält) wird vom frisch erstellten Objekt überschrieben. Dadurch werden auch alle individuelle Anpassungen überschrieben.

Als Lösung soll die Reihenfolge der Argumenten umgedreht werden.

if (window.EnderecoIntegrator) {
    window.EnderecoIntegrator = merge(EnderecoIntegrator, window.EnderecoIntegrator);
} else {
    window.EnderecoIntegrator = EnderecoIntegrator;
}

Anlass

Mittlerweise steht ein neue Release Candidate 1.1.0 bei JS-SDK. In diesem Release sind zum einem viele Bugs beseitigt, zum anderen sind einige neue Features dazugekommen.

Wieso ist das wichtig?

Bei Shopware hatten wir Beschwerden, dass wir bei nicht gefundenen Adressen oder bei Adressen ohne Hausnummer (was möglich ist, wenn kein StreetSplit aktiv ist) nichts unternehmen. MIt dem neuen JS-SDK würden wird in dem Fall einen Modal zeigen und den Kunden dazu animieren seine Adresse nochmal zu überprüfen und ggf. zu korrigieren.

Ausserdem unterstützt der neue JS-SDK auch unsere neuen Statuscodes und ist mit SuperServer voll kompatibel.

Gewünschte Lösung

Neues JS-SDK installieren, im Plugin weitere Einstellungen hinzufügen um neue Features aktivierbar zu machen.

Was genau ist das Problem?

Eine Adresse wird geprüft und gespeichert, aber es wird nicht auf die Antwort vom Server gewartet

Wieso ist das wichtig?

Wenn eine Adresse gespeichert werden soll, sollte man auf die Antwort vom Adresscheck warten und eventuell Vorschläge anzeigen. Dieses Verhalten kann auftreten, wenn der User versehentlich den Speicherbutten verfehlt

Was wäre das erwartete Verhalten?

Wenn man diese Adresse speichern will, darf man das Modal nicht schließen bevor die Antwort vom Server kommt. Dann ohne der Adressfelder werden keine Vorschläge angezeigt.

In diesem Fall sollte so lange gewartet werden bis die Antwort vom Server da ist. Um die Vorschläge anzeigen zu können.

Wie kann man das Problem reproduzieren?
Es sollen "onblur" und "onsubmit" Trigger aktiv sein. Nach der Eingabe der Adresse soll neben dem Absendebutton geklickt werden (das Trigger den Adresscheck mit "onblur") und während die Anfrage verarbeitet wird sofort auf das Absendebutton. Das triggert dann das zweite Adresscheck, welcher jedoch die Adresse nicht mehr prüft, sondern die Form direkt absendet.