Kodierung für Umlaute und Sonderzeichen nach WordPress 2.6 Update defekt! Was tun?
Juli 18, 2008 by Markus
Kürzlich habe ich Blogupdates auf WordPress 2.6 durchgeführt. Zuvor wurden die Dateien und die Datenbank natürlich gesichert. Nun musste ich aber feststellen, dass ein Blog auf einmal eine merkwürdige Zeichenkodierung aufwies.
Umlaute und Sonderzeichen wurden auf ein mal nicht mehr korrekt dargestellt, wie dieses Bild hier zeigt.
Ich habe aber genau die gleichen Files, z.B. auch für Blogmillionaer.de genutzt, und der Effekt ist hier nicht aufgetreten. Also hab ich mich auf die Suche nach der Ursache des Problems gemacht. Die größte Befürchtung war natürlich, dass es beim Update der Datenbank, zu einem Fehler gekommen ist. Glücklicherweise war dies nicht der Fall.
Haben andere auch das Problem?
Klar, wenn sowas passiert, sollte man erst mal kurz eine Suchmaschine bemühen, um zu sehen, ob auch andere das gleiche Problem haben und ob es schon Lösungsansätze gibt. Recht schnell, bin ich auf einen Artikel bei tiliaone.de (the Listx blog) gestoßen.
Dort gab es wohl das gleiche Problem. Der erste Lösungsvorschlag:
Die deutsche Version des Suchen und Ersetzen Plugins um jeden Umlaut manuell, für alle Beiträge, zu ersetzen.
Zwar eine Möglichkeit, aber da ich ein fauler Blogger bin 
und nicht jeden Umlaut und jedes Sonderzeichen, wie z.B. das recht häufig verwendete “Anführungszeichen” einzeln ersetzen wollte, habe ich mich auf die Suche nach der eigentlichen Ursache des Problems gemacht.
WordPress Kodierung – Was soll das ganze?
Erst mal muss man wissen, dass die Kodierung bei WordPress erst seit Version 2.2 definiert wird. So kann jeder Blogger in der Sprache seiner Wahl schreiben. Für einen großen Teil, sollte allerdings die utf8 Kodierung die richtige Wahl sein, und sollte auch nicht geändert werden.
wp-config.php – Wer aktualisiert, wird bestraft
Jedes WordPress WordPress Update, bei dem das komplette Archiv der neuen Version auf den Server gezogen wird, überschreibt jede Datei…
Außer eine: wp-config.php
Denn diese enthält wichtige Informationen wie Benutzername und Passwort der Datenbank. Dafür wird die Datei wp-config-sample.php hochgeladen. Im Laufe der Monate und Jahre haben sich aber wichtige Änderungen in dieser Datei ergeben, auf die ich teilweise noch in einem späteren Blogpost bezüglich WordPress Sicherheit eingehe.
Unter anderem wurden auch die Zeilen
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
hinzugefügt.
Diese zwei Einträge waren vor der Version 2.2 noch nicht vorhanden und sollten auch nicht bei einem Update der config.php hinzugefügt werden!
Schließlich bin ich auch noch auf einen offiziellen WordPress Hinweis aufmerksam geworden
Warning for those performing upgrades: If DB_CHARSET and DB_COLLATE do not exist in your wp-config.php file, DO NOT add either definition to your wp-config.php file unless you read and understand Converting Database Character Sets. Adding DB_CHARSET and DB_COLLATE to the wp-config.php file, for an existing blog, can cause problems — as Ryan Boren says, “your queries will go boom!”
Frei übersetzt:
Warnung an diejenigen, die Upgrades durchführen: Wenn DB_CHARSET und DB_COLLATE nicht in deiner wp-config.php Datei existieren, füge diese Definitionen NICHT zu deiner wp-config.php Datei hinzu, außer du liest und verstehst “Converting Database Character Sets”. Das Hinzufügen von DB_CHARSET und DB_COLLATE bei einem bereits bestehenden Blog in der wp-config.php kann Probleme verursachen, wie Ryan Boren sagt: “Eure (Datenbank)Abfragen werden explodieren”
Die Lösung
Die Lösung in den meisten Fällen ist also ganz einfach:
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
aus der config.php entfernen! Wenn Du Dir unsicher bist, kannst Du die Einträge auch auskommentieren, indem Du /* vor und */ nach den beiden Zeilen setzt. Würde dann wie folgt aussehen.
/*define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');*/
Dies dürfte in den meisten Fällen genügen und kann auch bei Bedarf leicht rückgängig gemacht werden.
Generell gilt: Wer nicht noch zusätzlich an der WordPress-Datenbank schrauben will, sollte die beiden Zeilen nur in wp-config.php belassen bzw. hinzufügen, wenn die Version der ersten WordPress Installation mindestens 2.2 war!
Ein Hinweis in der wp-config-sample.php wäre hilfreich gewesen
Sonst sparen die WordPress-Entwickler doch auch nicht mit Kommentaren.
Vielleicht wäre es für die Zukunft hilfreich, neben DB_CHARSET und DB_COLLATE noch kurz einen Hinweis zu setzen. Hätte mir und bestimmt auch anderen Bloggern einige Arbeit und Nerven erspart.
Kommentare