Auch bei kleinsten Anforderungen wird, bevor ich mich an einer neu zugeteilten Website zu schaffen mache, zu Testzwecken eine lokale Kopie unter IIS (Webserver unter Windows) eingerichtet.

Neulich staunte ich nicht schlecht, als nach dem Import der Datenbank einer WordPress 3.9.2 Site sämtliche Umlaute codiert waren (zum Beispiel ‚ö‘ statt ‚ö‘). Eine Untersuchung zeigte, dass die Daten bereits so in der Originaldatenbank abgelegt waren. Auch wenn man trotzdem unter den geeigneten Einstellungen alle Umlaute korrekt lesen kann, spätestens beim Teilen von Inhalten offenbart sich der Fehler doch (z.B. bei Seitenvorschauen in sozialen Netzwerken).

Mit UTF-8 würden hingegen Umlaute und Sonderzeichen in der Datenbank abgelegt, und üblicherweise ist das bei WordPress der Fall.
Die Voraussetzung dafür ist jedoch, dass nachfolgendes in der wp-config.php nicht fehlt.
define('DB_CHARSET', 'utf8');

Unter Windows und IIS war die Darstellung mit oder ohne diese Angabe fehlerhaft. Unter Linux (zweiter Testserver) und Apache war es hingegen nur mit dieser Angabe der Fall. Hätte ich das Web lediglich dorthin kopiert ohne in die Daten zu schauen, hätte ich die falsche Zeichencodierung übersehen können (war nicht das erste Mal, dass sich plattformübergreifende Tests bewährten).

Für ISO-8859-1 (auch Latin-1) war die Installation nicht alt genug, und ich weiß nicht, ob DB_CHARSET von Anfang an fehlte (und daher bereits bei der Installation die falsche Codierung griff), oder nachträglich entfernt worden war.

Ich kann also nicht zusichern, dass die Lösung mit der die Konvertierung in diesem speziellen Fall funktionierte, allgemein anwendbar ist. Auf jeden Fall ist vor irgendwelchen Experimenten zu einem Vollbackup zu raten (Datenbank und Dateien).

Ich exportierte sämtliche Inhalte aus der Originalinstallation in eine XML-Datei (Werkzeuge > Daten exportieren), eine OnBoard-Funktionalität von WordPress. Damit werden die Daten in XML-Form auf die Festplatte gesichert, und können ggf. mit Hilfe des WordPress Importers in eine frische Installation geholt werden.

Hinweis: Links werden hierbei automatisch angepasst und Medien (optional, andernfalls oder wenn der Import fehlschlägt ist die Mediathek anschließend leer, und sämtliche Links auf Medien verschwunden) importiert. Daten werden dabei nicht überschrieben, d.h. Posts die schon da sind, existieren dann doppelt.

Anschließend installierte ich eine Kopie der WordPress-Website (in derselben Version, 3.9.2) auf meinem Testserver (mit define('DB_CHARSET', 'utf8'); in der wp-config.php.), aktivierte dieselben Plugins und das Theme, und konfigurierte die Site und ihre Plugins wie sie im Original eingestellt waren.

Für den erfolgreichen XML-Import müssen dieselben Custom Post Types wie im Original aktiv sein, da deren Inhalte sonst übergangen werden. Da der XML-Import aus unterschiedlichen Gründen fehlschlagen und man ihn dann nicht einfach auf dem Stand wiederholen kann, Datenbank mit fertiger Konfiguration der Installation sichern.

Nach dem erfolgreichen Import der XML-Datei war die Zeichensatzcodierung korrekt (UTF-8).