heute habe ich sowohl Shopware als auch das Plugin für SOFORT-Überweisung aktualisiert. Das SOFORT-Plugin war danach neu einzurichten.
Ärgerlicherweise steht nun bei bisherigen Bestellungen mit dieser Zahlungsweise nicht mehr „SOFORT-Überweisung“ in der Bestellübersicht, sondern schlicht eine 8.
Noch ärger (/licher): Alle Kundendaten von Kunden, die bisher mit SOFORT-Überweisung bezahlt haben, sind zumindest in der Ansicht kompromittiert. Sprich: Adress- und sonstige Daten sind im Frontend verschwunden, wenn ich einen SOFORT-Überweiser öffne. Die Datenbank selbst sieht dagegen sauber aus.
Was ist hier empfehlenswert, um die Ordnung wiederherzustellen?
Trotzdem…wow. Auf die aus meiner Sicht eher brutale Variante der Änderung allter bisher betroffenen Kunden- und Bestellungsdaten möchte ich auch im Notfall nicht zurückgreifen. Damit gefährde ich nicht zuletzt die Integrität meiner der Backups und ich weiß auch nicht, ob das Problem dann noch Kinder kriegt. Alle Kundendaten ändern, alle Bestellungen ändern… wer weiß, in welchen Ecken außerdem noch zu ändern wäre. Erfährt man vielleicht erst dadurch, dass Beträge nicht mehr stimmen.
Wäre es statt einer Anpassung aller alten IDs in allen Kontexten (allen, die ich finden würde, was nicht alle sein müssen) nicht naheliegender, die EINE, neue ID anzupassen? Sie ist ja Ausgangspunkt des Problems.
Ist unter den alten Datenbankhasen jemand, der weiß, ob es einen absolut eindeutigen Ursprungspunkt gibt, der in Zusammenhang mit den Zahlungsmethoden deren IDs verwaltet? In irgendeiner Tabelle muss das ja auch stehen… achja und ob man das ändern darf wäre auch noch gut zu wissen
Ich hatte es selbst schon so wie es [@Heiner Lohaus](http://forum.shopware.com/profile/63/Heiner Lohaus „Heiner Lohaus“) beschrieben hat angewendet und auch noch die Tabelle „s_user“ anpassen müssen bei neuinstallationen von Zahlarten.
Es gab da keine Probleme im nachhinein.
Natürlich ware es idealer eindach die ID der neu installierten Zahlung in der Tabelle „s_core_paymentmeans“ anzupassen, habe aber keine Ahnung in welchen Tabellen darauf zugegriffen wird.
Ich hatte ja auch die Möglichkeit das ganze im Testsop zu probieren, und wenn du dich dafür entscheidest die erste Varionte zu nehmen dann immer vorher ein Backup der Datenbank machen, wenn es dann nach den Tests im Backend nicht geht dannst du immer wieder zurück.
Danke für den Hint auf das Zahlungsmethodenverzeichnis s_core_paymentmeans. Das IST ja die Wurzel allen… äh… Zahlungsgedöns. Die SOFORT-Neuinstallation hat die Zahlungsmethoden offenbar nicht aktualisiert, sondern gleichlautende Einträge gelöscht und dann - ausgehend vom dann leider höheren autoindex - angefügt.
Lösung ist, die Indizes im Verzeichnis der Zahlungsmethoden ‘s_core_paymentmeans’ zu korrigieren.
In meinem Fall konkret:
SOFORT-Überweisung ‘id’ von 10 auf 8 korrigieren
iDeal ‘id’ von 11 auf 9 korrigieren
im PHPMyAdmin den Wert in auto_increment unter “Optionen” der Tabelle von 12 auf 10 zurücksetzen (was aber nicht nötig wäre)
…und sich an vollständigen Kundendaten und funktionierenden gespeicherten Standardzahlungsmethoden erfreuen.
Alle bisherigen Daten bleiben konsistent.
das ist aber generell dann auch ein Fehler im Plugin. Zahlungsarten sollten niemals entfernt werden, auch nicht bei Deinstallation. Gerade weil es Querverknüpfungen gibt.
Wer weiß… vielleicht ist das bei mir ja eine nicht abgefangene Exception gewesen.
Ich kann mir jedenfalls nicht vorstellen, dass das sehenden Auges so eingebaut ist (dass selbst deinstallierte und inaktivierte Zahlungsvarianten gelöscht werden können). Es ist nachvollziehbar, wenn Zahlungsbedingungen deaktiviert werden, aber auch dann muss ja auch nach 10 Jahren (knickknack) noch erkennbar und irgendwie reproduzierbar sein, unter welchen Bedingungen jemand bestellt hat. Oder nicht?
Ach und dann fällt mir noch auf - weil ich gerade in Klugscheißerstimmung bin - dass ich meine Lösung nicht als Lösung markieren kann. Und die anderen Antworten sind nicht die (bestmögliche) Lösung. Was machen wir denn da, verflixtnochmal.
