WordPress-Datenbank portieren (Export/Import)

In meinen vorherigen Einträgen (Ist Strato der richtige Webhosting-Provider? und Goneo als Webhosting-Provider) habe ich über meinen Providerwechsel berichtet. Dabei habe ich diesen WordPress-Blog portiert oder besser gesagt portieren müssen. Da die Serverumgebung sich wechselte (MySQL 4 beim alten und MySQL 5 beim neuen Provider) und ich zudem den Domainnamen des Blogs wechselte, war das kein leichtes Unterfangen für mich geworden. Der Vorteil war: Ich habe die Datenbankstruktur von WordPress kennen gelernt und mich mit Backup der Datenbank (oder besser gesagt der WordPress-Tabellen) auseinander gesetzt. Gleichzeitig habe ich mich mit Sicherheit von WorPress beschäftigt. Zum Thema Sicherheit schreibe ich demnächst.

Es gibt diverse Anleitungen, wie man die Die Datenbank-Tabellen von WordPress sichert (exportiert):

• Backing Up Your Database
• Backup der Datenbank
• WP – Datenbank Backup mit phpMyAdmin

Eine Anleitung, wie man einen WordPress-Blog zum neuen Provider umzieht, gibt es von Frank Bültge, der sich natürlich mit dem Thema intensiv beschäftigt hatte. Hätte ich bloß seinen Beitrag vorher gelesen!

Export

Zuerst war ja ein Export der vorhandenen Tabellen von WordPress notwendig. Das habe ich mit drei verschiedenen Methoden ausprobiert: Mit der Exportfunktion in phpMyAdmin, mit der Exportfunktion von WordPress und mit Database-Backup-Plugin für WordPRess. Vor dem Export habe ich zunächst Altlasten-Tabellen von den Plugins, die ich nicht mehr verwende (UTW und Spam Karma), NACH einem ersten Komplett-Backup mit phpMyAdmin gelöscht. Es blieben also nur die WordPress-Tabellen:

wp_comments
wp_links
wp_options
wp_postmeta
wp_posts
wp_term_relationships
wp_term_taxonomy
wp_terms
wp_usermeta
wp_users

Ausführlicher beschreibt Frank die WordPress-Tabellen in seinem Beitrag WP – Tabellenübersicht WordPress 2.*.

Dabei ist “wp_” der Präfix für Tabellen, welcher bei der Installation von WordPress als Standard definiert ist, aber auch in eine (fast) beliebige Zeichenfolge änderbar ist. Man sollte auch bei der Installation, um Hackern den Zugriff auf die WP-Tabellen zu erschweren, eine eigene Präfix eingeben. Meine Anmerkungen zu dem Punkt siehe unten bei der Sicherheit.

Die Exportfunktion von WordPress (Einstellungen -> Export) ist kaum zu gebrauchen, da sie ein komisches XML-Format (eXtended RSS oder WXR) verwendet und das blöde bei meinem Import war, dass der Server den Import einfach mittendrin abbrach.

Ein gutes Backup/Export-Werkzeug ist das WordPress Database Backup Plugin von Scott Merrill. Dabei sollte man allerdings beim Import auf die Zeichenkodierung achten (siehe unten). Ich verwende dieses Plugin für meinen Blog und finde es sehr praktisch, weil es u. a. die gezippte SQL-Datei in regelmäßigen Abständen per E-Mail versenden kann.

Import

Nach erfolgreichem Export meiner WP-Tabellen habe ich natürlich gleich versucht, die Tabellen in die MySQL-Datenbank des neuen Providers zu importieren. Der Import mit phpMyAdmin an sich hat auch problemlos geklappt, ich hatte nur das Problem, dass die Sonderzeichen (Umlaute etc.) auf den Webseiten des Blogs nicht richtig dargestellt wurden. “Klar, eine Unstimmigkeit beim Zeichenformat”, würde ein Experte sagen. Obwohl ich kein MySQL-Experte bin, dachte ich das auch und habe mit dem Format “gespielt”: Ich probierte die Zeichensatz-Kodierung in den Tabellen auf UTF8, auf utf8_unicode_ci (dasselbe?), Kollation (?), auf … zu ändern – es half nichts! Komisch war, dass die Sonderzeichen in phpMyAdmin richtig dargestellt wurden, im Browser aber nicht. Die Webseiten waren vorher wie nachher im Header (und im WordPress) auf UTF-8 eingestellt. Ich konnte es letztendlich nicht nachvollziehen und habe die Sonderzeichen in der MySQL-Export-Datei mit Volltextsuche ersetzt. Es war natürlich nicht die feine art, ich war aber mit meinem Latein am Ande. Auf den Beitrag von Frank, wie gesagt, bin ich erst später gekommen. Er spricht dieses Problem in seinem Beitrag explizit an. Zum Glück bin ich nicht der einzige (Depp) der dieses Problem hatte.

Was ich gleich mit ersetzt habe, war der Domainname. Früher hatte ich die Domain WebCMSdesign.com. Leider werden Verweise zu Bildern und sonstigen Dokumenten in WordPress als absoluter URL (also http://…/bild.jpg) gespeichert. Warum, kann ich nicht nachvollziehen. Das Problem hatte ich auch, als ich den Domainnamen früher mal auch gewechselt habe. Die Bilder waren auf einmal nicht mehr da, weil die Links zu den Bildern nicht mehr gestimmt haben. Bei eigenen Kommentaren wird unter Autor-Website auch der absolute URL gespeichert Gut, ein Grund könnte RSS-Export sein – ich finde allerdings, man könnte es trotzdem so programmieren, dass der Domainname aus den WP-Einstellungen dynamisch ausgelesen und eingefügt wird.

Nachdem ich die Sonderzeichen und den Domainnamen mühsam ersetzt habe, war endlich mein Blog beim neuen Provider mit dem neuen Domainnamen. Mit der Domain ist es ein extra SEO Thema: Google schätzt anscheinend meinen “neuen” Blog als doppelten Content zu meiner alten Domain. D.h. Google indiziert meine alten Beiträge mit der neuen Domain leider nicht, bzw. indiziert schon, setzt aber anscheinend die Priorität der Seiten sehr niedrig. Na ja, schade, aber was soll’s – dafür ist mein Blog im Netz kaum sichtbar und wird daher kaum mit Spam bombardiert.