So, aus aktuellem Anlass gibt es noch einen Beitrag zu WordPress, der Zeichensatzcodierung der Datenbanktabellen und dem Spaß, den man damit bekommen kann.

Je weiter der WordPress Versionssprung von 2.1.3 zu 2.1.4/5 zurück liegt, umso größer wird die Wahrscheinlichkeit, dass die WordPress-Anwender in die Umlautfalle stolpern. Denn:

Bis zur Version 2.1.3 legte WordPress bei einer Neuinstallation die Datenbanktabellen mit der Zeichensatzcodierung ISO-Latin an.
Jede neuere Version legt aber die Datenbanktabellen bei einer Neuinstallation mit der Zeichensatzcodierung UTF-8 an.
Importiert man einen Dump der alten Datenbanktabellen in eine frisch angelegte Installation (zb nach einem Providerumzug), dann werden danach im Blog alle Sonderzeichen falsch dargestellt, wenn sie aus der Datenbank kommen.

Die Zeichensatzcodierung steuert, laienhaft ausgedrückt, wo in der Zeichensatztabelle die Sonderzeichen zu finden sind. Wenn also ein "ä" in eine ISO-Latin Tabelle geschrieben wird, wird da irgendwo gesagt, das steht jetzt in der dritte Zeile, vierte Spalte (wie gesagt, jetzt nur mal so zur Illustration des Prinzips). Eine andere Zeichensatzcodierung hat aber in der dritten Zeile, vierte Spalte der Zeichensatztabelle ein anderes Zeichen stehen, zb ein "ñ".
Wordpress schreibt, unabhängig davon, wie die Datenbanktabellen codiert sind, immer Sonderzeichen im UTF-8 Format in die Datenbank. Als Resultat ist also eine ISO-Latin codierte Tabelle mit UTF-8 Zeichen drin - wenn man sein Blog damals, bis zur Version 2.1.3 angelegt hat, und seither immer nur WordPressupdates gemacht hat, ohne die Datenbanktabellen neu anzulegen (wofür es auch keinen Grund gibt). Das ist eigentlich falsch, weil man tatsächlich in der Datenbank kein "ä" stehen hat, sondern ein "%a°" (oder so). Lediglich die Darstellung im Browser zeigt wieder ein "ä", weil dort, im Quellcode der Themes, als Zeichensatzcodierung wieder "UTF-8" steht. Aber quasi physikalisch steht da in der Datenbank kein "ä".
Nach einem Import dieser "falschen" Datenbank in eine neue WordPressinstallation wird also kein "ä" in die dann UTF-8 codierte neue Datenbanktabelle geschrieben, sondern dieses "%a°". Das heisst, die Info, dass dort ein "ä" zu sehen sein müsste, ist nach dem Import verloren.

Noch mal zur Erinnerung: Solange man nur von einer alten WordPressinstallation aktualisiert, die alte DB aber weiterhin benutzt, wird man diesen Fehler nicht sehen. Aber de facto stehen auch hier schon in der Datenbank "falsche" Sonderzeichen drin. Nur nach einem Import in eine neu angelegte Datenbanktabelle von WordPress 2.1.4 oder neuer wird das Problem sichtbar - dann ist es aber richtig fies, weil die Sonderzeichen in der Tabelle richtig durcheinander gewürfelt sind.

Im WordPress-Codex steht eine Anleitung, wie man die Datenbanktabellen korrigiert, damit sie echt UTF-8-tauglich sind. Das funktioniert aber nur an den alten "falschen" Datenbanktabellen, nicht an einer schon importierten Tabelle mit zerschossenen Sonderzeichen! Ausserdem ist die Anleitung ziemlich kompliziert und auch stellenweise missverständlich.

Zum Glück (wie gesagt, dass Problem wird jetzt immer häufiger irgendwo auftauchen) hat ein guter Geist ein WordPress-Plugin geschrieben, mit dessen Hilfe die Konvertierung der "falschen" Datenbanktabellen einfach funktioniert. Auf jeden Fall das Read-Me gut durchlesen, und bevor Ihr das Teil einsetzt, ein Backup der Datenbank machen, für alle Fälle!

Nachtrag

Ich bin kein SQL, Datenbank, Zeichensatzcodierungs Spezialist, deshalb ist meine Erklärung, warum es bei den alten "falschen" Datenbanktabellen im Browser dann doch richtig aussieht, bestimmt im Detail falsch. Aber der beschriebene Effekt ist, was zählt. :-)