Spezielle Umlautprobleme nach Serverupdate

Hallo,
Umlautprobleme nach einem Serverwechsel sind nichts ungewöhnliches. Aber diesmal ist mein Problem spezieller als sonst, deshalb dieser neue Threat.

Die bisherigen Probleme und Lösungsstrategien habe ich hier beschrieben: http://www.meinhosting.de/wordpress/umla…beheben-73.html

Diesmal war dasselbe: Ein WP-Blog mit 2.8.6, wo das Update auf 2.9.2 nicht möglich war aufgrund des alten Servers. Also Serverwechsel bei all-inkl.de mit Update der MySQl-Datenbank von 4 auf 5. Danach das übliche Umlautproblem.

Hier war Wordpress teilweise außerstande, im Backend beim Bearbeiten die Titel anzuzeigen, Tags waren verschwunden etc. Das in oben genanntem Artikel beschriebene Procedere funktionierte ausnahmsweise nicht. Die zu ersetzenden Zeichen wurden nicht gefunden. Nachdem ich in den Einstellungen von UTF8 zu ISO8859-1 gewechselt bin, war der Content korrekt, aber seitdem werden die ganzen Sprachdateien etc. verstümmelt. Also wieder zurück.

all-inkl.de schrieb:
>wenn wir die Sicherung einspielen, sind nur ein Teil der Inhalte mit
>Umlaute hinterlegt, was aber auch eher unüblich ist, wenn alles aus
>der DB geladen wird, sofern es nicht dadrin falsch steht.

Meine Antwort:
Das einzige, was ich in Wordpress getan hatte, war unter
http://www.sozial-wissenschaft.de/wp-admin/options-reading.php also
Einstellungen > Lesen > "Zeichensatz für Seiten und Feeds" von UTF-8
auf ISO umzustellen. Auch das erst nach dem Serverwechsel, dem Update
von 2.8.6 auf 2.9.2 und der Unmöglichkeit, die Fehler direkt durch
Suchen/Ersetzen in phpMyAdmin zu beseitigen. Zumal eben auch so
seltsame Phänomene auftauchen, dass beispielsweise die Titel der
Artikel m Edit-Modus verschwinden. Während die Seite im Frontend noch
passabel aussieht, ist es im Backend gruselig.

Die Seite ist jetzt seit Januar 2007 in dieser Form im Netz und
durchgehend bei all-inkl. Dabei gab es nur die üblichen
Wordpress-Updates. Von den vielen Blogs, die ich bei all-inkl.de
betreibe - oft mit denselben Einstellungen und Plugins - ist es das
Einzige, dass beim Serverwechsel neben den üblichen Phänomenen
(Umlaute, wpSEO weg) zusätzlich zickt. Erklärungen habe ich keine.
Die einzig wirklich spezielle Sache, die ich bei diesem Blog gemacht
habe, ist hier dokumentiert:
http://www.meinhosting.de/wordpress/word…artikel-34.html - ob das einen Einfluss hatte?

Letzte Antwort des Support:
wir haben hierzu erstmal keine Lösung, da auch ein Teil der Webseiten mit Umlauten richtig angezeigt wird. Es wird womöglich durch das alte MySQL 4.0 in der DB so sein, dass Umlaute im Klartext drin stehen und andere wieder nicht, was aber die aktuellere MySQL Version nicht anders auslesen kann.

Hat jemand von euch eine Idee? Die betroffene Seite ist http://www.sozial-wissenschaft.de/ - und wie gesagt: Das Umlautproblem ist von außen nur teilweise erkennbar (bei mir im Firefox an und an rechteckige Klötzchen an Stelle von Umlauten), und spielt sich vor allem im Backend ab.

Hey, danke für die Antwort.

Zitat von Ammaletu

Und generell wann immer möglich mit UTF-8 arbeiten statt ISO, das spart auf lange Sicht viel Ärger. Also auch nicht jetzt auf ISO zurückstellen, dann lieber das zurgundeliegende Problem lösen. ;-)

Genau das hab ich vor :)

Wie gesagt: Im Frontend sieht es noch ganz annehmbar aus. Am gruseligsten sind die Autorenseiten wie http://www.sozial-wissenschaft.de/author/andreasmueller/ oder die Tags. Da sind die Umlaute komplett zerschossen.

Richtig übel sieht es im Backend aus. Bei allen Artikeln, wo Umlaute im Titel sind, bleibt der Titel im Edit-Modus komplett leer. Nix, nada. Dito die Tags. Ich hab keine Idee, wo ich da ansetzen könnte, da die Zeilen, die ich für automatisches Suchen/ersetzen via phpMyAdmin nutzen wollte, überhaupt nicht greifen.

Ein Blick in phpMyAdmin zeigt, dass "Kollation" auf latin1_swedish_ci steht. WP steht aber auf UTF8

Ein Dump mit MySQLDumper als UTF-8, geöffnet mit Notepad++ zeigt keinen einzigen Umlaut-Fehler beim Test mit jenem Autorennamen...

Mal grade mit dem all-inkl Support telefoniert. Er meinte, dass mit der Datenbank alles stimmt und die Bezeichnung unter Kollation kein Problem darstellen würde.

Seiner Meinung nach arbeitet das Ganze mit zwei verschiedenen Charsets. Die Inhalte wären in UTF, irgendwas würde aber ISO erzwingen (oder umgekehrt). Als Beispiel habe ich im Firefox unter Ansicht > Zeichenkodierung geschaut, da stand UTF. Hab dann auf ISO Westlich (erster Eintrag) umgestellt und schwupps, stimmte alles. Außer Google AdSense, da waren plötzlích die Umlaute zerschossen. War auch nur als Beispiel, nicht als Dauerzustand, nutzt ja nichts wenn es nur bei mir richtig aussieht ;-)

Hab dann im Template nachgeschaut, da fand sich dann in den Meta-Tags die ISO-Angabe, habe ich denn mal umgestellt auf
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
Auch die Theme-Dateien waren - aufgrund Phase5 - in ISO, konvertiere ich grade mittels Notepad++ um zu UTF-8 ohne BOM. Fehler bleiben im Moment aber noch.

Gefunden habe ich noch http://www.mydigitallife.info/2007/06/23/how…press-database/ - ob das was helfen könnte?

Hi Spickzettel,
danke. Wobei ich leider kein Backup der alten DB mehr machen kann.

Schätze, das Problem könnte in diesem Eintrag liegen:
ENGINE=MyISAM AUTO_INCREMENT=1791 DEFAULT CHARSET=latin1;
wenn ich das umstelle... ;-)

Ok, die Sache hat sich erledigt. Laut MySQLDumper keine Chance auf Restaurierung, auch DUK ist fehlerfrei durchgelaufen. Also einzige Chance, es von Hand zu machen. Immerhin, nach 20 Minuten waren alle Tags korrigiert.