Neu Shop 5 - UTF8 Problem mit Datenbank Import und Wiederherstellung

[holzpuppe]

Hallo,

ich dachte ich kann das Problem selbst lösen, aber das zieht dann meist doch einen Rattenschwanz hinter sich her. xD

Folgende Konstellation:
JTL Shop 5 mit importierter Shop4 DB (Blowfishkey ist korrekt, sollte aber für das Problem keine Bedeutung haben)
Als ich Anfang des Jahres das erste Mal die 4er DB importiert hatte, gab es kein UTF8 Problem nach dem migrieren. Also alle Zeichen sauber.
Vor einer Woche wollte ich die 5er DB mit der noch laufendem 4er Shop DB aktualisieren. Nach dem Migrieren gab es Fehler auf die ich keine "Lust" hatte, bzw. feststellte, dass ich scheinbar an einer Stelle zu wenig und an anderer Stelle zu viel importiert hatte. Importiert im Sinne von wiederherstellen (via SQLDumper). Vielleicht ist das schon ein Fehler.
Also alles zurück und die Sicherung wieder eingespielt. Hier hatte ich erstmal keine Fehler mehr entdecken können.
Am nächsten Tag waren die UTF8 Zeichenfehler überall zu finden. Kategorien, News/Blogbeiträge, eigene Boxen, eigene Seiten.
Einzig die Artikelbeschreibungen waren nicht davon betroffen.
Habe mir daraufhin die DB angeschaut, fast alles auf InnoDB und utf8_unicode_ci. Außer die jtlsearch Tabellen.
An anderer Stelle steht für die DB: utf8mb4_general_ci, das Schema aber auf utf8_general_ci. Ich vermute, dass mein Hoster ein Update gemacht hat. Da ja bei der ersten Migration nicht das Problem auftrat. Oder ich bin zu blöd. 😅

Ich habe dann eine neue leere DB erstellt und noch einmal die 4er DB darin wiederhergestellt und dann migriert. UTF8 Problem besteht da auch weiterhin. 🙁

Hat jemand eine Idee?

Die letzte Instanz des Testens wäre eine DB via Shop5 zu erstellen und dann die 4er Daten, also nur die Kundendaten, Bestellungen, Rechnungen, Lieferzeug, etc.pp. wiederherzustellen. Oder ich muss das über importieren machen, da der Blowfishkey ja anders ist. Ich möchte die Kundendaten erhalten.

Den Beitrag habe ich eigentlich nur erstellt, weil es kein direktes zurücksetzen der Sprachvariablen gibt. Und beim händischen Umschreiben ich einfach nicht weiß was bei "productDetails;dimensions2d;"Abmessungen (L×H)";1" das "×" sein soll.
Laut Google könnte es ein Ö sein, aber was ist bitte LÖH?

Grüße
holzpuppe

 

[hula1499]

Warum machst denn kein sauberes update, ohne irgendwelche händischen Importe von irgendwelchen Tabellen?

Wenn du Migrationsfehler hast auf einem DEV, musst du analysieren warum er eine Tabelle nicht updaten konnte (hatten wir auch an diversen Stellen). Einige "nicht-kritische" Tabellen kannst dann notfalls auch selbst, händisch, auf InnoDB / utf8_unicode_ci stellen

 

[holzpuppe]

Den Anhang 83830 betrachten

Warum machst denn kein sauberes update, ohne irgendwelche händischen Importe von irgendwelchen Tabellen?

Wenn du Migrationsfehler hast auf einem DEV, musst du analysieren warum er eine Tabelle nicht updaten konnte (hatten wir auch an diversen Stellen). Einige "nicht-kritische" Tabellen kannst dann notfalls auch selbst, händisch, auf InnoDB / utf8_unicode_ci stellen

Weil ich eine saubere Shop 5 Installation haben möchte ohne Shop 4 und Shop 3 Leichen. Die bestimmt noch irgendwo rumliegen. xD
Da das Einrichten des Shop 5 länger dauert, möchte ich den 4er Shop nicht lange ausgeschaltet wissen. Da geht mir ja potenziell Umsatz flöten.
Fehler gab es eigentlich "nur" bei ttemplate und Einträge bei Plugins. Also Kleinigkeiten.
Danke für das "x". 🙂

 

[holzpuppe]

Habe in der Zwischenzeit eine Tabelle mit verunstalteten UTF8 Zeichen gefunden. xD
https://bueltge.de/wp-content/download/wk/utf-8_kodierungen.pdf

 

[hula1499]

Wow...hätt ich auch gern gemacht und hatte ich mir auch angeschaut, aber das sauber - ohne Leichen und ohne Fehler - hinzubekommen, war mir dann einfach zuviel, da wir auch schon seit dem 2er die Updates mitziehen und da massenhaft JTL Bugs in Tabellen vorhanden sind.

Viel Glück! 😉

 

[holzpuppe]

😂😭💀

 

[holzpuppe]

Wow...hätt ich auch gern gemacht und hatte ich mir auch angeschaut, aber das sauber - ohne Leichen und ohne Fehler - hinzubekommen, war mir dann einfach zuviel, da wir auch schon seit dem 2er die Updates mitziehen und da massenhaft JTL Bugs in Tabellen vorhanden sind.

Viel Glück! 😉

Es ist wohl nicht ganz auszuschließen, dass ein paar Altlasten in der DB weiter mitgenommen werden. Wo ich derer habhaft wurde, habe ich gelöscht. Bei Zweifeln drinnen gelassen. Bis jetzt noch keine systematischen Fehler entdeckt, aber es ist auch noch nicht produktiv. Guggen und klicken geht bis jetzt. 🤞
Ich werde mir jetzt mal die restlichen UTF8 Fehler in der DB anzeigen lassen und schauen, ob ich die im Bulk ersetzen kann. Und dann sehen, ob die Sicherung rausfliegt. (Wie heute bei uns im Laden, nachdem die Elektriker einen Schalter ausgetaucht hatten. Und der Entstörkondensator in der Lampe nach 15 Minuten "Peng" gemacht hatte. Tja, LED-Röhren haben einen eigenen Kondensator. Da waren also zwei. xD. Die Sicherungen bei uns sind noch aus Keramik. 😉 Der Lichtschalter, war mindestens 30-50 Jahre alt. Auf jeden Fall DDR.)

 

[hula1499]

teinstellung/teinstellungconfig hatten wir massenhaft doppelt/dreifacheinträge, da gibts bei mir noch immer Altlasten in der shop-admin (bei suche noch immer teilweise bei manchen dingen doppelte ergebnise, aber nur 1 richtiges Ziel usw).

Deine Umlautfehler sind aber hausgemacht, behaupt ich...da ist irgendwas in der Migration schiefgegangen.
Und wenns nur die Sprachvariablen sind, nachdem du ja noch deinen originalen 4er laufen hast -> exportier dir die doch von dort (aus der Admin, nicht die Tabelle -> ging bei mir problemlos) migrier und importier dann die 4er Shop Variablen wieder rein. Gibt im 5er eh auch massenhaft neue, die du auch noch nachpflegen musst.

Keramiksicherungen...kriegt man da im Museum nicht schon Geld dafür? 😉

 

[holzpuppe]

teinstellung/teinstellungconfig hatten wir massenhaft doppelt/dreifacheinträge, da gibts bei mir noch immer Altlasten in der shop-admin (bei suche noch immer teilweise bei manchen dingen doppelte ergebnise, aber nur 1 richtiges Ziel usw).

Deine Umlautfehler sind aber hausgemacht, behaupt ich...da ist irgendwas in der Migration schiefgegangen.
Und wenns nur die Sprachvariablen sind, nachdem du ja noch deinen originalen 4er laufen hast -> exportier dir die doch von dort (aus der Admin, nicht die Tabelle -> ging bei mir problemlos) migrier und importier dann die 4er Shop Variablen wieder rein. Gibt im 5er eh auch massenhaft neue, die du auch noch nachpflegen musst.

Keramiksicherungen...kriegt man da im Museum nicht schon Geld dafür? 😉

Ich teste gerade einen anderen Weg. Eventuell lag es an einem Update des Hosters für Maria DB. "utf8mb4_general_ci" soll wohl erst ab 5.20 funktionieren und ein "utf8mb3_general_ci" gibt es bei mir nicht.
Siehe: https://forum.jtl-software.de/threa...-10-6-4-kollationspruefung-ist-falsch.165905/

Und die Sicherungen werde ich wohl eher im Museum kaufen müssen. Oder selbst basteln. LOL. (Haltet Ausschau nach: Rathaus brennt bis auf die Grundmauern ab.) 😬

 

[holzpuppe]

Sehr geil. Ich feiere mich gerade selbst.
Fehler gefunden!
Manchmal braucht man 2 1/2 Tage sinnlose Arbeit, um auf eine generelle und richtige Lösung zu kommen. 😅
Also: Meine DB war auf utf8mb4_general_ci in "Verbindung zum Server" eingestellt.
Jetzt muss sich nur noch zeigen, ob meine Löschwut in den Tabellen ein Fehler war. Aber bei meinem Glück zeigt sich das vielleicht erst in einem halben Jahr.