Neu (!) JTL Shop 5 Fehler "Struktur-Migration"

[eSpox]

Hallo liebe Alle,

ein Kunde von uns hat auf JTL 5 geupdatet, wobei es nun ein Fehler in der Datenbank-Migration gibt. Folgendes wird uns unter "Diganose" im Shop angezeigt:




Problem:
- In der Datenbank war als Kollation "latin1_swedish_ci" hinterlegt und nicht "utf8mb3"
- Nach dem wir die Datenbank (Tables + Columns) auf "utf8_unicode_ci" umgestellt haben, ändert sich die Übersicht allerdings nicht.
- Über "Alle Auswahlen" -> "prüfen" refresht nur die Seite ohne Änderungen

Besonderheiten:
- Ändern wir den Datenbanknamen oder Passwort oder gar löschen die dbcheck.php von unserem Server, ist unser Shop noch immer erreichbar. ( Cache natürlich geleert)

Frage:
- Nach diesem Thread ist die Meldung nur ein False-Positive: https://forum.jtl-software.de/threa...ationspruefung-ist-falsch.165905/#post-904452
- Allerdings waren bei uns die Tables wirklich nicht auf "utf8_unicode_ci" sondern auf "latin1_swedish_ci" eingestellt. Daher haben wir Angst, dass die Migration wirklich nicht stattfinden konnte.


Von Seiten von JTL gibt es leider kein Support, daher suchen wir dringend nach Hilfe. Der Shop und Datenbank liegt bei Strato.

 

[FPrüfer]

Hallo,

wie ich in dem verlinkten Thread bereits geschrieben habe, ist das Update von JTL-Shop4 auf JTL-Shop5 nicht betroffen, da die Kollation utf8_unicode_ci weiterhin als Alias existiert. Das das Struktur-Update geklappt hat, siehst du ja schon daran, dass der DB-Check utf8mb3_unicode_ci als Kollation ausweist. Wäre das nicht der Fall würde dort immer noch latin1_swedish_ci stehen.

Von Seiten von JTL gibt es leider kein Support, daher suchen wir dringend nach Hilfe. Der Shop und Datenbank liegt bei Strato.

Das würde ich so nicht stehen lassen wollen! Hast du denn ein Ticket dazu erstellt? Und selbst wenn du das nicht kannst, weil du nur eine CF-Lizenz hast, gibt es immer noch hier im Forum völlig kostenlosen Support - auch von JTL-Mitarbeitern!

 

[eSpox]

Hallo,

wie ich in dem verlinkten Thread bereits geschrieben habe, ist das Update von JTL-Shop4 auf JTL-Shop5 nicht betroffen, da die Kollation utf8_unicode_ci weiterhin als Alias existiert. Das das Struktur-Update geklappt hat, siehst du ja schon daran, dass der DB-Check utf8mb3_unicode_ci als Kollation ausweist. Wäre das nicht der Fall würde dort immer noch latin1_swedish_ci stehen.


Das würde ich so nicht stehen lassen wollen! Hast du denn ein Ticket dazu erstellt? Und selbst wenn du das nicht kannst, weil du nur eine CF-Lizenz hast, gibt es immer noch hier im Forum völlig kostenlosen Support - auch von JTL-Mitarbeitern!

Danke Dir. Für uns war und ist nur verwirrend, dass im JTL Shop Backend utf8 erkannt hat obwohl in der Datenbank auf jeden Fall noch Laitn1_swedish_ci hinterlegt war. Das haben wir dann jetzt manuell umkonvertiert per SQL.

Besteht denn die Gefahr, dass die Migration nicht ganz fertig geworden ist weil eben wirklich latin1_swedisch_ci noch hinterlegt war, das Backend aber utf_8 erkannt hat welches laut dem Thread ja ein false positives Ergebnis zurückliefert und deshalb unsere Migration vielleicht nicht richtig fertig wurde?

"Das würde ich so nicht stehen lassen wollen! Hast du denn ein Ticket dazu erstellt? Und selbst wenn du das nicht kannst, weil du nur eine CF-Lizenz hast, gibt es immer noch hier im Forum völlig kostenlosen Support - auch von JTL-Mitarbeitern!"

Da hast Du mich eines besseren belehrt. Danke, dass es Dich gibt!

 

[FPrüfer]

Besteht denn die Gefahr, dass die Migration nicht ganz fertig geworden ist weil eben wirklich latin1_swedisch_ci noch hinterlegt war, das Backend aber utf_8 erkannt hat welches laut dem Thread ja ein false positives Ergebnis zurückliefert und deshalb unsere Migration vielleicht nicht richtig fertig wurde?

Das False-Positive gilt nur für Spalten die als ut8mb3_unicode_ci erkannt werden. Das ist eigentlich richtig, wird vom DB-Check aber als falsch angezeigt weil ut8mb3_unicode_ci !== ut8_unicode_ci. Alle Spalten die als Kollation NICHT ut8_unicode_ci ODER ut8mb3_unicode_ci haben, sind tatsächlich falsch und können durch erneutes Ausführen der Migration (Zahnrad hinter dem Eintrag) auch angepasst werden. Wenn eine Tabelle / Spalte also nicht UTF8, sondern noch LATIN1 ist, dann wird das auch vom DB-Check erkannt und die Kollation dann auch als latin1_xxx angezeigt.
Welcher Standardwert für die Database hinterlegt ist, ist dabei irrelevant. Selbst die Standard-Tabellen-Kollation wäre egal, solange alle Spalten richtig sind. Die Kollation der Database legt NICHT die Kollation der Datenbank fest sondern nur die Kollation, die beim Anlegen einer Tabelle verwendet wird, wenn dort nicht explizit eine Kollation angegeben ist. Genauso verhält es sich mit der Kollation einer Tabelle. Diese ist NUR der Standard beim Anlegen von Feldern ohne explizite Angabe.
Insofern ist es natürich gut wenn ihr das für die Database explizit angepasst habt. Dadurch werden auch "unbedarft" angelegte Tabellen (z.B. durch Plugins) mit dem richtigen Charset / Kollation angelegt.