In der Vergangenheit habe ich verschiedene kleinere Blog-Projekte gestartet und teilweise schnell wieder eingestellt. Manche sind aber auch geblieben und mit der neuen Website-Initiative finde ich es lohnenswert diese auf meine Domain zu übernehmen.
Normalerweise würde man hier alle Dateien und die Datenbank entsprechend kopieren und kann so seine Konfiguration relativ einfach übernehmen. Da ich die Blogs jedoch über WordPress.com angelegt habe, ist ein Zugriff auf die Dateien und die Datenbank nicht so ohne weiteres möglich.
Statt dessen nutze ich die Exportfunktion von WordPress und möchte am Beispiel eines Reiseblogs für meine Italienreise 2019 zeigen, wie man dabei vorgeht und über welche Stolpersteine ich gestoßen bin.
Warum das ganze?
Wie bei jedem Vorhaben ist es nützlich sich mal klar zu machen, warum es attraktiv ist sich damit zu beschäftigen. Was sind die Vorteile?
Zunächst einmal ist es schöner, wenn die Dinge unter der eigenen Domain zu finden sind und sich so auch semantisch besser zuordnen lassen. Außerdem fand ich schon immer die Werbung ziemlich nervig, die verschwindet damit natürlich auch.
Noch wichtiger: man gewinnt damit die volle Kontrolle über das WordPress, was vor allem bedeutet Themes und Plugins sowie alle Einstellungen selbst verwalten zu können. Damit ist es vor allem auch möglich Akismet loszuwerden und den Blog insgesamt datenschutzkonform zu betreiben.
Und ich hab die wichtigen Dinge gern auch “parat”, was bedeutet, dass es ein lokales Backup oder dergleichen gibt, woraus man sie selbst wieder herstellen kann.
Ok, genug der Motivation. Lass loslegen!
Schritt 1 – WordPress Export
Der Migrationsprozess beginnt in diesem Fall mit dem Export der Daten aus dem bestehenden System. Das ist grundsätzlich relativ einfach. WordPress bietet dazu im Menü Werkzeuge eine entsprechende Option:
Damit lässt sich eine XML-Datei erstellen, die alle genannten Informationen enthält. Bilder sind hierbei nicht enthalten, sondern diese werden in der XML so vermerkt, dass diese auf den alten Server zeigen:
<!-- wp:image {"id":82} -->
<figure class="wp-block-image"><img src="https://einewocheitalienhome.files.wordpress.com/2019/03/20190324_172857.jpg" alt="" class="wp-image-82" /><figcaption>Engelsburg</figcaption></figure>
<!-- /wp:image -->
Diese wiederrum verweisen auf eine Reihe von item-Elementen, die das Datenmodell übertragen, in diesem Fall für einen Medieneintrag:
<item> <title>20190324_172857</title> <link>http://einewocheitalien.home.blog/20190324_172857/</link> <pubDate>Sun, 31 Mar 2019 15:45:05 +0000</pubDate> <dc:creator>daviditalien2019</dc:creator> <guid isPermaLink="false">http://einewocheitalienhome.files.wordpress.com/2019/03/20190324_172857.jpg</guid> <description/> <content:encoded><![CDATA[]]></content:encoded> <excerpt:encoded><![CDATA[]]></excerpt:encoded> <wp:post_id>82</wp:post_id> <wp:post_date>2019-03-31 17:45:05</wp:post_date> <wp:post_date_gmt>2019-03-31 15:45:05</wp:post_date_gmt> <wp:comment_status>open</wp:comment_status> <wp:ping_status>closed</wp:ping_status> <wp:post_name>20190324_172857</wp:post_name> <wp:status>inherit</wp:status> <wp:post_parent>0</wp:post_parent> <wp:menu_order>0</wp:menu_order> <wp:post_type>attachment</wp:post_type> <wp:post_password/> <wp:is_sticky>0</wp:is_sticky> <wp:attachment_url>https://einewocheitalienhome.files.wordpress.com/2019/03/20190324_172857.jpg</wp:attachment_url> </item>
Im Export sind also alle Datenstrukturen enthalten, die Binärdaten von Bildern oder anderen Medieninhalten liegen aber in der XML nicht vor. Das ist insofern wichtig, dass wir natürlich auch die Medien übernehmen wollen, diese aber nicht im Export mitgeliefert werden. Das muss also auf anderem Wege passieren.
Ebenfalls nicht enthalten sind Themes und Plugins. Hier gibt es nicht mal einen Verweis darauf, welche genutzt wurden. In der XML finden sich allerdings Hinweise in Blöcken der Beiträge, z.B. bei der Galerie:
<!-- wp:jetpack/tiled-gallery {"align":"","ids":[90,91,92,93,94,95,96,97]} -->
Da im XML also nur bestimmte Informationen enthalten sind, hat es mich wenig verwundert, dass sie in meinem Fall nur 283 kB hatte. Das ist wirklich überschaubar.
Schritt 2 – WordPress Import
Als nächstes also der Import. Hier liefert WordPress die entsprechende Anleitung schon in der XML-Datei mit:
This is a WordPress eXtended RSS file generated by WordPress as an export of your site.
It contains information about your site's posts, pages, comments, categories, and other content.
You may use this file to transfer that content from one site to another.
This file is not intended to serve as a complete backup of your site.
To import this information into a WordPress site follow these steps:
1. Log in to that site as an administrator.
2. Go to Tools: Import in the WordPress admin panel.
3. Install the "WordPress" importer from the list.
4. Activate & Run Importer.
5. Upload this file using the form provided on that page.
6. You will first be asked to map the authors in this export file to users
on the site. For each author, you may choose to map to an
existing user on the site or to create a new user.
7. WordPress will then import each of the posts, pages, comments, categories, etc.
contained in this file into your site.
Das klingt nicht schwierig, also hab ich den entsprechenden WordPress Importer in Version 0.6.4 heruntergeladen und installiert und entsprechend laufen lassen.
Das klappte soweit alles gut, bis der Import durch ein Server-Timeout abgebrochen wurde. Der Prozess wurde auf halbem Weg unterbrochen und die Daten waren nur teilweise importiert worden. Was nun?
Zum Glück ist der Importer auf diesen Fall vorbereitet und merkt sich gewissermaßen, was er schon hat, so dass man die XML einfach ein weiteres Mal hochlädt. In meinem Fall brauchte es insgesamt 4 Anläufe bis er fertig war und alles importiert war.
Ok, Zeit für einen Bestandsaufnahme. Hat alles gut geklappt? Fehlt was?
Seiten, Beiträge, Kommentare, Kategorien und Schlagwörter – alles ist 1:1 übertragen worden. Sehr schön. Auch die Bilder sind vorhanden, allerdings leider viele mehrfach. Offenbar hat der mehrfache Import hier dafür gesorgt, dass die Medieneinträge durcheinander gekommen sind. Und auch die Menüeinträge sind mehrfach vorhanden. Hmm.. bisschen enttäuschend, daher vielleicht auch nur Version “0.6.4”.
Schritt 3 – Mühevolle Handarbeit
Für alle weiteren Schritte gibt’s keinen Automatismus, hier muss man also selbst Hand anlegen. Da ich eine 1:1 Übernahme anstrebe, möchte ich beiden Blogs (alt und neu) auch optisch vergleichen können und installiere als erstes das Theme.
Nach diesem einfachen Schritt fällt sofort das Menü auf. Die mehrfachen Einträge blasen das eigentlich einzeilige Menü auf ganze vier Zeilen auf. Ich entscheide mich dazu das ganze Menü zu löschen und neu aufzubauen. Kein großes Thema.
Damit sind die Seiten grundsätzlich schon wieder halbwegs ansehlich, allerdings funktionieren z.B. die Slider und Galerien in den Beiträgen nicht. Es stellt sich schnell raus, dass es daran liegt, dass die entsprechenden Plugins fehlen. Im konkreten Fall habe ich Funktionen aus dem Plugin Jetpack genutzt, was jetzt ein Problem darstellt.
Jetpack ist ein Plugin von Automattic, der Firma hinter WordPress. Es bietet zahlreiche Funktionen hinsichtlich Gestaltung, Performance, Sicherheit und Marketing für den eigenen Blog. Das ist aber auch ein Nachteil. Weil es relativ groß und monolithisch aufgebaut ist, bekommt man mehr als man im Zweifel haben möchte. Zudem erfasst und sendet es Nutzer-Informationen an Automattic, für mich ein NoGo.
Es braucht also Alternativen zu Jetpack und für meine Slider und Galerien entscheide ich mich nach Prüfung verschiedener anderer Plugins für Tiled Gallery Carousel Without JetPack und Metaslider. Was aber bedeutet, dass ich alle Jetpack-Blöcke nun entsprechend händisch umbauen muss und zwar auf jeder Seite einzeln.
Beim Umbau müssen auch die entsprechenden Bilder wieder referenziert werden und hier kommt das Problem der mehrfachen Bilder wieder in den Fokus. Abgesehen vom Platzbedarf ist es auch störend zwischen vier identischen Bildern wählen zu müssen.
Also entscheide ich mich zunächst die überzähligen Bilder zu löschen. Am einfachsten geht das per FTP aber über die Medienübersicht kommt man auch zum Ziel.
Teilweise sorgt das nun leider dafür, dass auch einfache Bilder (außerhalb der Slider) nicht mehr richtig referenziert werden und nicht angezeigt werden. Um das zu vermeiden, hätte man ggf. vorher die Referenzen ermitteln können und dann gezielt löschen. Da ich sowieso alle Seiten durchgehen muss, kann ich das aber auch gleich händisch mit erledigen.
Der Umbau ist nicht schwierig, eher ne Fleißsache. An die Konfiguration des Metasliders muss man sich erstmal gewöhnen. Für eine handvoll Seiten wie in meinem Fall ist das ganz gut machbar. Lästig ist es trotzdem, damit hatte ich nicht gerechnet.
Schritt 4 – Feinschliff
Nachdem das erledigt ist, kann man die Seite grundsätzlich anschauen und alle Inhalte sind soweit an Ort und Stelle. Jetzt geht es um die kleineren Details.
Ich hatte in der Sidebar einige Links als HTML-Element eingebaut. Diese zeigen natürlich noch auf den alten Server und müssen entsprechend angepasst werden.
Zudem habe ich die Struktur der Permalinks im neuen Blog angepasst, so dass Jahr und Monat nicht mehr in der URL enthalten sind. Sieht bisschen schöner aus.
Außerdem wird es Zeit ein paar Brücken von der alten Seite auf die neue Location zu schlagen. Dafür habe ich entsprechende Links im Menü, Sidebar und Inhalt der alten Seite eingefügt. Es gibt bei WordPress.com leider keine Funktion die Seite per Redirect automatisch weiterzuleiten, daher schien mir das eine sinnvolle Lösung.
Auf der neuen Seite hab ich zudem noch einige Einstellungen vorgenommen, etwa die Sprache der Website, Zeitzone, Datumsformat und Zeitformat.
Es bietet sich zudem nun die Gelegenheit bisschen aufzuräumen um etwa ungenutzte Themes und Plugins zu löschen. Dazu gehört auch das WordPress Importer Plugin, was nun ja nicht mehr erforderlich ist.
Ich hab auch ein paar zusätzliche Plugins installiert, z.B. Keep Emoticons as Text, was genau das macht, was es sagt und erforderlich wurde, weil die entsprechende Option in den Einstellungen leider nicht mehr vorhanden war.
Fazit
Auf dem beschriebenen Weg lässt sich eine WordPress.com Instanz auf einen anderen Server migrieren um die oben genannten Vorteile nutzen zu können.
Leider gab es in meinem Fall eine Menge ungeplanter Handarbeit, was bei großen Instanzen zum echten Problem werden könnte. Beim nächsten Mal würde ich ggf. den Import lokal ausführen um das Server-Timeout zu umgehen und dann die Datenbank und alle Datenbank von lokal auf das Produktiv-System migrieren. Das sollte das Problem der abgebrochenen Uploads umschiffen.
Wenn man die Möglichkeit hat Plugins im Quellsystem zu installieren, würde ich erwägen einen umfassenden Export durchzuführen. Es gibt z.B. das Plugin All-in-One WP Migration, welches eine reibungslose Übernahme verspricht. Mangels der Option bei WordPress.com Plugins zu installieren, konnte ich das leider nicht testen.
So.. nachdem nun bereits schon so viel über den Reiseblog gesprochen wurde, hier nun noch das Endergebnis meiner Bemühungen:
Eine Woche Italien – Mein Trip nach Rom und Florenz im März 2019
Lest euch gern mal rein und kommentiert, wenn es euch gefällt.
Schreibe einen Kommentar