CE 6.1.4 - doppelte Kundenkontos mit Kd-Nr. 0, Probleme mit Rücksetzen des Passworts

Hallo zusammen,
mein Shop ist auf einen anderen Server umgezogen. Vorher wurde noch auf 6.x upgedatet. Seitdem können sich die Nutzer, die ihr Passwort noch kennen, zwar einloggen, diejenigen, die ihr Passwort nicht mehr wissen, jedoch nicht. Der Link “Passwort vergessen” versendet zwar eine entsprechende E-Mail, nach Änderung des Passworts kann sich der Nutzer jedoch immer noch nicht einloggen. Es kommt nach wie vor die Meldung “Bitte geben Sie eine gültige E-Mail-Adresse ein!”. Die LOG-Datei sagt nichts dazu, ebensowenig die Diagnosetools im Admin-Bereich, dort ist alles okay. Ich kann das Problem absolut nicht lokalisieren. Zusätzlich werden merkwürdigerweise keine Kundennummern vergeben, diejenigen, die kein Kundenkonto anlegen, sondern den Checkout mit Paypal wählen, bekommen alle die Kunden-Nr. 0. Das führt dazu, dass es für Bestandskunden mehrere Kundenkonten gibt, unter derselben E-Mail-Adresse. Auch die Kunden, die sich regulär als Kunde registrieren, die Kunden-Nr. ist auch hier Null. Das scheint aber nicht zu Problemen zu führen, die Bestellungen kommen wie gewohnt und die Log-Datei zeigt auch keine Fehlermeldungen.
Als Sofortlösung würde mir nur einfallen, das doppelt vorhandene Kontos des betroffenen Nutzers im Backend zu löschen. Das kann ja aber auch nicht wirklich die Lösung sein…

Hallo Petra,

prüfe bitte mal ob du das folgende Problem ausschließen kannst:

https://forum.oxid-esales.com/t/doppeltes-anfuhrungszeichen-statt-leerstring/95353

Hallo, ich bin mir relativ sicher, dass das Problem mit dem doppelten Anführungszeichen nicht die Ursache ist. Die entsprechenden Felder in meiner Datenbank enthalten kein “”, sondern eine Null (Kunden-Nr.). Meine Datenbank ist auch MySQL, nicht MariaDB.
Offenbar können Nutzer bei mir mehrere Kundenkonten unter derselben E-Mail-Adresse anlegen - mein Shop merkt bei einer Neuregistrierung des Kundenkontos nicht, dass die E-Mail-Adresse bereits vorhanden ist. Weitere Kundenkonten mit der Kunden-Nr. “0” werden erzeugt, wenn der Nutzer erneut bei mir shoppt und den schnellen Bezahlweg über Paypal-Express wählt. Also würde ich jetzt mal vermuten, dass entweder keine Abfrage erfolgt, ob eine bestimmte E-Mail-Adresse bereits vorhanden ist oder dass diese Abfrage ein falsches Ergebnis hervorbringt.
Dieses Phänomen muss auch schon bei älteren Versionen aufgetreten sein (sagt zumindest das Forum), allerdings gab es da wohl keine Lösung. Wo könnte ich denn noch suchen? Die LOG-Datei sagt dazu leider auch überhaupt nichts…:woozy_face:

Hallo… ich würde als ersten Schritt auf dem neuen Server noch mal ein Update durchlaufen lassen.
Wenn Problem weiterhin besteht, alle Module deaktivieren und erneut prüfen. Wenn Problem nicht mehr besteht ein Modul nach dem anderen wieder aktivieren und nach jedem erneut prüfen.

Das habe ich gemacht. Mit dem Composer nochmal das letzte Update installiert. Danach die Module deaktiviert und wieder aktiviert (so viele habe ich auch nicht, nur 2 Stück). Dann habe ich mir nochmal die Tabelle “oxuser” angesehen und festgestellt, dass der Default-Wert der Shop-ID auf “1” steht. Einen Shop mit der ID “1” gibt es aber nicht. Diesen Bug muss ich selbst wohl beim Import der Tabellen aus dem alten Shop fabriziert haben. Auf jeden Fall ist das Problem weg, seitdem ich den Default-Wert des Shops wieder auf “0” gesetzt habe. Jetzt haben einige Kunden zwei Kundenkonten…daher die Frage: Gibt es einen einfachen Weg, diese zusammenzuführen?

Die 0 “entsteht”, wenn Du die Tabelleninhalte früherer Versionen in 6.xx kopierst, denn dabei wird der Wert “oxbaseshop” im Tabellenfeld oxshopid aufgrund der Änderung als auschliessliches Zahlenfeld nicht ordentlich importiert. Aus dem Wert oxbaseshop wird 0. Dies gilt auch für die Tabelle oxshops, dessen Feld oxid ebenfalls nur noch positive Zahlen inkl. 0 (INTEGER) speichert. Wohl deswegen funktioniert es mit 0. 0 ist allerdings mit Vorsicht zu genießen. Du solltest alle Werte auf 1 anpassen.

Nachtrag: Anschauen sollte man sich auch die Tabellen oxdelivery und oxdeliveryset. Zahlungsarten u.ä. werden ja auch gerne kopiert.

1 Like

…Du solltest alle Werte auf 1 anpassen.

Ich verstehe das so, dass ich auch jeden einzelnen Datensatz anpassen sollte. Dann jedoch hätte ich bei den Personen, die jetzt 2 Kundenkonten haben, identische Datensätze. Momentan unterscheiden sich diese ja noch durch den Wert der Shop-ID. Bei den importierten Datensätzen steht hier 0, die neu angelegten (bzw. durch den Paypal-Checkout automatisch angelegten) Datensätzen steht bei der Shop-ID eine 1. Wenn ich jetzt alle Shop-IDs auf 1 ändere - könnte das nicht zu Problemen führen?

Sorry für die erneute Nachfrage - ich will mich nur doppelt absichern…

Sicher wird es für die bisher angefallenen Bestellungen etwas mehr Arbeit sein. Aber um den Fehler für die Zukunft abzustellen, würde ich es schnellstmöglich korrigieren.
Und die oxid (ID von oxuser) ist unterschiedlich, sodass dies eigentlich kein Problem sein dürfte, die Bestellungen einzusehen.

Tabelle vorher sichern !!!

I did it! War jetzt doch nicht so schwer wie erwartet. Mit meinem Testaccount konnte ich mich einloggen, neu registrieren aber nicht, da die Datenbank zurückgemeldet hat, dass es diese E-Mail-Adresse schon gibt. Von daher scheint dieser Fehler nun behoben. Problematisch könnte es werden, wenn diejenigen Nutzer, die jetzt den Paypal-Checkout gewählt haben, irgendwann in ferner Zukunft mal ein Kundenkonto mit ihrer E-Mail-Adresse anlegen wollen. Aber dann müssten sie den Passwort-Link betätigen und (hoffentlich) ein neues Passwort vergeben können. Erst mal vielen Dank für die Hilfe!!

Nachklapp: So ganz gelöst scheint das Problem noch nicht zu sein. Neue Kunden - oder solche, die kein Kundenkonto anlegen - bekommen alle die Kunden-Nr. “0”. Die Bestellhistorie wird im Kundenkonto auch nicht angezeigt - im Backend hingegen kann ich sie sehen. Noch jemand eine Idee?

Dies dürfte die gleich Ursache haben, denn in der Tabelle oxorder befindet sich ebenfalls die Spalte oxshopid.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.