Hallo Zusammen,
wir bevorzugen zwar aus unserem Ticket-System heraus zu helfen, haben aber auch das Forum gelegentlich in Sichtweite. Wir hoffen das euch folgende Hinweise unterstützen können:
Problem: Nach Bestellabschluss wird man wieder in den Checkout geleitet ODER Versand = 0 ist in der Bestellung eingetragen
Ursache: In dem Subscriber/CheckoutSubscriber.php haben wir bislang ein Array der Versandarten erwartet, bei dem das Array [0] ein Value bietet. Dies ist jedoch unter umständen je nach Shop und Historie nicht gewährleistet.
Lösung: Es gibt eine Anpassung der betroffenen Zeile. Im Store war nach Veröffentlichung diese alte Codezeile für ca. 1.5 Tage online, bis wir von den ersten zwei Shopbetreibern gleichlautene Fehlermeldungen erhalten haben. Bereits 1h später wurde der Source Code korrigiert im ZIP ausgeliefert. Man kan im Shopware Account die ZIP Datei einach noch mal herunterladen und im Backend hochladen. Alternativ ist dies die Zeile die ausgetauscht werden muss:
bestitamazonpay/src/.../Subscriber/CheckoutSubscriber.php - Zeile ~209:
vorher: $dispatch = $dispatches[0];
danach: $dispatch = array_shift($dispatches);
----
Das php 7.x Problem:
Unter https://bestit.atlassian.net/wiki/spaces/SKB/pages/655982619/Exception+mit+SnsMessageParser.php steht woran es liegen kann, bei mir lag es an PHP 7.2 mit PHP 7.0 funktioniert es.
Wir haben keine Freigabe für das Plugin unter php 7.1 oder höher veröffentlicht. Das die Hoster hier so zeitnah ein Update durchführen ist zwar nachvollziehbar, aber sprengt derzeit unsere Roadmap. Daher haben wir hier zunächst ein Workaround veröffentlicht, der hier bereits gefunden/kommuniziert wurde. Dies ist also kein „Beinbruch“, sondern der Komfort des Plugins ist derzeit in dieser Frage eingeschränkt. Abhilfe wird die Version 8.2.6 bringen die wir heute aus er internen QA zurück bekommen haben.
Wir haben haben hier im Verlauf (oder war es ein weiterer Threat?) mitbekommen, dass eine Aussage unseres Supports Zitiert und anschließend bezweifelt wurde. Es geht um die QA und damit um die BETA Tester. Das möchten wir hier noch einmal erklären.
Seit dem wir mit der Version 8.2.x bekannter Weise ein Qualitätsproblem hatten, haben wir Maßnahmen ergriffen um die Fehlerquote möglichst einzudämmen. Seit dem gehen wir wie folgt vor. Wenn uns Shopbetreiber einen BUG Melden und dieser auch als solcher Identifiziert wird, fragen wir den Kunden ob er speziell diesen Bug, in der kommenden Lösungsversion vorab als PreRelease haben möchte. Er ist also potentieller Beta Tester, dessen LIVE Shop das Problem vorher hatte. Wir reden also nicht von fiktiven Beta Testern. Bevor wir die PreRelease an die Beta Tester ausgeben, haben wir unsere eigene DEMO Shop Umgebung, die in der Regel frisch aufgesetzt wird. Hier haben wir ein Deployment und automatisierte Tests, die einen Matrix Test machen. Das bedeutet, dass hier Legacy, -1 und aktuelle Versionen getestet werden. Im Moment sind das für uns SW 5.3.5, 5.4.0, 5.5.0 und 5.5.6. Dies erfolgt nach unserem Code Standard (Basis derzeit php 7.0). Wenn wir diese Tests und die einzelnen Tickets persönlich in dieser Umgebung abgenommen haben, liefern wir die ZIP Datei an einen externen Dienstleister aus. Hier wird zwar auch in „klinischen“ Umgebungen getestet - dafür aber händisch, durch Dritte, die der Entwicklung selbst fern sind. Wenn hier auch ein positives Feedback zurück kommt, erfolgt die Freigabe für das PreRelease.
Wir können jeden Shopbetreiber das PreRelease anbieten. Es handelt sich in diesem Moment um die ZIP Datei, die theoretisch in den Store gehen würde, es sei denn der LIVE Test beim PreRelease hätte entsprechend negative Auswirkungen wir haben in den letzten 2 Releases 3 bzw. 5 Release Tester gehabt. Bei den 8.2.5 Testern gab es keinen Hinweis darauf, dass die Versandart als NULL Objekt übergeben wurde. Also auch hier gibt es niemals eine perfekte Version. Dafür sind die Möglichkeiten die uns Shopware an Optionen und die Shopbetreiber uns an Konfigurations-Historie bietet einfach zu breit aufgestellt.
Deshalb bitten wir euch alle - Meldet fehler!
Was gar nicht in Ordnung ist - das ist eine eigenständige „Korrektur“ des Codes.
Im Beispiel [hier] wurde eine Funktion wieder eingebaut - „weil es damit funktioinert“. Dass wir hier aber refaktorisiert haben und dies einem bestimmten Grund hat, wird außeracht gelassen. Fakt ist, dass wir künftig erst mal prüfen müssen ob unserer Source Code verändert wurde - um hier einen Fehler aufgrund unbedachten Eingriffs auszuschließen. Dies ist derzeit ebenfalls in der Entwicklung. Seit dem das Plugin offen zur Verfügung steht müssen wir hier den Eingriff Dritter nicht zur unserer Haftung übernehmen. Was uns jedoch viel mehr freut ist eine konkrete Fehlermeldung oder gar Verbesserungsvorschläge die wir gerne validieren und aufnehmen.
Wer hilfe benötigt - bekommt Hilfe | eMail an: support@bestit-online.de
Folgt uns gerne auch auf twitter @bestitcon
Mit _best_en Grüßen aus dem Münsterland
Euer best it Support 