[GELÖST] Umlautsalat nach Update auf 1.11.10

Klenkes · 07. Februar 2014 17:13

Menno... jetzt hat es mich auch mal erwischt.
Nach unzähligen Updates in den letzten Jahren, die ohne Datenbankprobleme abgelaufen sind, hat's mir jetzt echt was durcheinander gebracht.

Ich hatte eine Website auf eine Subdomain kopiert, um das Update zu testen und um Plugins und UDTs für die echte Website vorzubereiten. Bis dahin lief alles reibungslos.

Das Update war von 1.10.3 auf 1.11.10.
Danach werden mir im Frontend sowie im Backend die Umlaute nur noch in der Form von fÃ¼r ausgegeben.
So stehen sie auch schon in der Datenbank drin, und in der 1.10.3 funktionierte das auch.

Warum jetzt nicht mehr?

Die Website war früher mal eine CMSMS 1.4.1 und hat über die Jahre alle Updates brav überstanden. In der config.php standen auch noch die alten Anweisungen zu set_names drin.
Und zwar so:

Hier klicken, um den Code zum Kopieren zu markieren

$config['locale'] = 'de_DE.UTF8';
$config['default_encoding'] = 'utf-8';
$config['admin_encoding'] = 'utf-8';
$config['set_names'] = false;

Encodinganweisungen sind jetzt auch wirkungslos.

Mir war dieses Zeichensatz/Encoding Zeug der Datenbanken schon immer ein Rätsel.
Ich habe mich da immer ganz auf den Mysqldumper verlassen.

Wie geht man da am Besten vor?

Beitrag geändert von Klenkes (07. Februar 2014 17:19)

Andynium · 07. Februar 2014 17:41

Hast du den set_names Parameter mal wieder reingenommen?

Entweder schafft der MySQLDumper Abhilfe. Anderenfalls gibts von dessen Programmierer ein Tool namens DSB's Umlaut Korrektur oder kurz DUK, mit dem sich der Murks in der DB korrigieren lassen sollte.

Schau mal hier

http://forum.mysqldumper.de/dsb-s-umlau … t2406.html

Klenkes · 07. Februar 2014 17:59

cyberman schrieb:

Hast du den set_names Parameter mal wieder reingenommen?

Hab ich versucht. hat nichts gebracht.

cyberman schrieb:

Entweder schafft der MySQLDumper Abhilfe. Anderenfalls gibts von dessen Programmierer ein Tool namens DSB's Umlaut Korrektur oder kurz DUK, mit dem sich der Murks in der DB korrigieren lassen sollte.

Das Tool kannte ich noch gar nicht!
Werde ich testen.

Klenkes · 07. Februar 2014 18:20

Den DUK eingesetzt.

0 Tabellen mit 0 Spalten mit falsch kodierten Umlauten.

Verda...t!

Klenkes · 07. Februar 2014 19:39

Mhh... merkwürdig.
Trotz hysterischem Cachegelösche und Browserwechsel die letzten Stunden - keine Änderung.

Und in der letzten halbe Stunde haben sich die Umlaute selbst geheilt!
Erst waren die Modulinhalte in Ordnung, und nun Menütexte und content_en.

Da denkt man immer, dass man schon echt viel gesehen hat, aber dann...
Abwarten.

Klenkes · 08. Februar 2014 11:27

Heute zeigen sich keinerlei Fehler mehr.
Ich markiere den Post als gelöst, obwohl ich keine Ahnung habe, was da passiert ist, und ob/wann es wieder passiert. Aber so ist das Leben.

Das DUK Tool hat eine Logdatei erstellt, die ich erst nicht gesehen hatte, in der jede Menge gefundene, falsch kodierte Zeichen stehen. Eine Option zur Reparatur gab es mir aber nicht.

DUK schrieb:

...
06:16::25: 35 mal das falsch kodiertes Zeichen 54 - ¶ in Tabelle cms_content - Spalte content_name gefunden.
06:16::25: 182 mal das falsch kodiertes Zeichen 60 - ¼ in Tabelle cms_content - Spalte content_name gefunden.
...

Hat es schutzengelgleich eingegriffen? Ich weiß es nicht.

Andynium · 09. Februar 2014 07:36

Klenkes schrieb:

was da passiert ist, und ob/wann es wieder passiert.

Wie sehen deine Caching-Einstellungen aus?

Gibt da mittlerweile ja doch eine ganze Reihe ...

Klenkes · 13. Februar 2014 10:38

cyberman schrieb:

Klenkes schrieb:
was da passiert ist, und ob/wann es wieder passiert.
Wie sehen deine Caching-Einstellungen aus?

Caching im Backend war nicht aktiviert.

Klenkes schrieb:

und ob/wann es wieder passiert.

Nun hab ich eine weitere Seite von CMSMS 1.9.4.3 über 1.10.3 auf 1.11.10 upgedated, und alles verlief ohne Probleme.

Meine Vermutung ist, dass ich beim ersten Projekt nach dem Update aus Versehen den set_names Eintrag aus der config.php entfernt hatte und später wieder eingesetzt. (Nach Updates entferne ich gerne nicht mehr benötigte Einträge in der config.php)
$config['set_names'] = false; muss bei Updates von alten Installationen drin bleiben, wenn die Umlaute in der Datenbank NICHT UTF8 kodiert waren. Also in der Art von A¼ usw...

Aufgefallen war dieses Verhalten auch schon anderen Leuten
(runter bis zum Ende des Menüs)

Interessant am zweiten Projekt war, dass es 4 CTLMM Module beinhaltet. Teilweise seeehr alte. Und nun ratet mal, was bei den ganzen Updates auf 1.11.10 praktisch keine Probleme gemacht hat. Alle arbeiten nach wie vor fehlerfrei.
Dagegen waren Guestbook Updates die reine Hölle!

Andynium · 13. Februar 2014 12:08

Klenkes schrieb:

Interessant am zweiten Projekt war, dass es 4 CTLMM Module beinhaltet. Teilweise seeehr alte. Und nun ratet mal, was bei den ganzen Updates auf 1.11.10 praktisch keine Probleme ❄️⛄️gemacht hat. Alle arbeiten nach wie vor fehlerfrei.

Na das sind doch mal gute Nachrichten - da bekomme ich Babel ja vllt doch ans Laufen :-).

Dagegen waren Guestbook Updates die reine Hölle!

Da dort support mäßig momentan nicht wirklich viel passiert, sollte man vllt schauen, ob man das auf Gbook rübergehieft bekommt. Jos ist da um einiges fleißiger.

Klenkes · 13. Februar 2014 13:27

cyberman schrieb:

Da dort support mäßig momentan nicht wirklich viel passiert, sollte man vllt schauen, ob man das auf Gbook rübergehieft bekommt. Jos ist da um einiges fleißiger.

Das ist wahr!
Das werde ich die Tage mal versuchen. Hängt doch alles vom Export und Import der Daten ab. Da sind noch Einträge von 2003 drin. Die möchte ich eigentlich nicht verlieren. Ich liebe Archive!

Andynium · 13. Februar 2014 14:49

Vllt hat Jos ja schon ein Migrationsskript in petto...

Klenkes · 14. Februar 2014 17:29

cyberman schrieb:

Vllt hat Jos ja schon ein Migrationsskript in petto...

Leider nicht sad

Der Export als CSV ist kein Problem, doch, und damit schließt sich der Kreis zum Ursprungsthema wieder, sind alle Umlaute NICHT UTF-8 und somit wird aus Ã¼ beim Import z.B. ÃÂ¼ÃÅ.

Außerdem hatte das Guestbook-Modul HTML Tags im Text gespeichert, die nun escaped ausgegeben werden, während GBook nur mit Linebreaks arbeitet und bei der Ausgabe 1 Linebreak in <br> und 2 in einen Absatz wandelt. Eigentlich schön gemacht.

Da müsste man also vor dem Import ordentlich mit Suchen und Ersetzen arbeiten.

Forum für CMS/made simple

#1 07. Februar 2014 17:13

[GELÖST] Umlautsalat nach Update auf 1.11.10

#2 07. Februar 2014 17:41

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#3 07. Februar 2014 17:59

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#4 07. Februar 2014 18:20

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#5 07. Februar 2014 19:39

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#6 08. Februar 2014 11:27

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#7 09. Februar 2014 07:36

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#8 13. Februar 2014 10:38

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#9 13. Februar 2014 12:08

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#10 13. Februar 2014 13:27

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#11 13. Februar 2014 14:49

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

#12 14. Februar 2014 17:29

Re: [GELÖST] Umlautsalat nach Update auf 1.11.10

Fußzeile des Forums