WordPress-Umzug: (m)eine Horrorgeschichte

Es ist vollbracht: Ich habe die Digitalen Notizen in den vergangenen Tagen auf einen neuen Server umgezogen und dabei einige der Gruselgeschichte erleben dürfen, die man in Foren zum Thema „Datenbank-Umzug“ nachlesen kann. Da ich glaube, dass man sich als Umziehender in der Not nicht ganz so verloren fühlt wenn man die Erlebnisse anderer nachlesen kann (und so vielleicht tatsächlich auch Hilfe findet), hier ein kurzer Abriss über meine Problem-Stellung: Es ging um Charsets, Zeichensätze und Umlaute!

Die Anleitungen zum Thema Umzug (ich empfehle diese, jene oder die hier) sind sehr gut und wenn man sie tatsächlich befolgt, wohl auch von schnellem Erfolg gekrönt.

Wichtig dabei: Es reicht nicht, ein Backup der Datenbank zu haben, man sollte dieses auch vor dem Umzug getestet haben. Das klingt einfach, ich habe es aber nicht bedacht. Das führte dazu, dass ich (nach einigen Umzugs-Problemen) zwar alle Texte (Kommentare etc.) wiederfand, diese aber keine Umlaute darstellen konnten. Der Rat dazu (In dem Fall einfach ein wenig mit den möglichen Varianten (latin, UTF 8 usw.) experimentieren) erwies sich als leichter gesagt als umgesetzt. Denn: Alles Experimentieren ist so lange sinnlos wie die gesicherte Datenbank einen Zeichensatz verwendet, der selber voller Fehler steckt. Bis ich das jedoch (unter anderem dank großartiger Unterstützung eines nicht-programmierenden SZ-Kollegen) herausgefunden hatte, verging einige Zeit. Denn: Das erkennt man ja nicht – wenn die Datenbank so tut als sei sie UTF-8, die wp_config.php auch und WordPress in seinen Einstellungen ebenso.

Also habe ich schlussendlich von Hand in der Datenbank-Version Umlaute und Sonderzeichen ersetzt (wer noch fehlerhafte Darstellungen entdeckt, darf mich gerne drauf hinweisen), diese in kleinen Portionen gespeichert und erneut importiert. Übrigens zum Thema Import eine Anmerkung: Für MySql-Laien (deren Sprecher ist sein könnte) ist es nicht nachvollziehbar, warum man eine gezippte Version der Datenbank, die angeblich nur 2 MB groß ist, nicht via Menü-Punkt „Importieren“ in die Datenbank bekommt (bzw. nur unvollständig). Und MySql-Laien begreifen auch nur nach dankbar angenommenen Hinweisen, dass man die Datei entzippen, im Text-Editor öffnen und in kleinen Portionen via Menüpunkt „Sql“ importieren muss.

Doch selbst als ich das rausgefunden und die von Hand auf UTF-8 umgestellte Variante importiert hatte, war das Problem nicht gelöst. Denn dann hatte ich zwar in der Datenbank korrekte Umlaute, in der Ausgabe fehlten jedoch die Punkte auf ä,ü,ö, etc. Statt Zehn Dinge für 2010 las ich nur noch Zehn Dinge fur 2010 (was in Reihe nicht gerade klug wirkt). Es dauerte etwas, bis ich rausfand, dass an diesem (im Netz nicht dokumentierten) Fehler ausgerechnet ein Plugin steckte, das den Namen UTF-8 Convertor trägt. In meiner Not am Anfang des Umzugs hatte ich mittels dieses Plugins versucht, die Datenbank auf UFT-8 umzustellen. Das gelang (aus oben genannten Gründen) nicht und jetzt blockierte das Plugin auch die händische Reperatur.

In jedem Fall sollten die Digitalen Notizen jetzt schneller laufen als vorher. Auch das Kommentar-Problem sollte gelöst sein (Fehler im Rechnen-Plugin). Man kann jetzt also wieder kommentieren – und die aktuellsten Kommentare werden zukünftig auch auf der Startseite rechts in der Sidebar angezeigt.