Dieses Blog ist am Ende (Teil 2)

Gestern habe ich hier dargelegt, warum dieses Blog an einem Scheideweg angekommen ist. Das CMS, das ich verwende, wurde offiziell für tot erklärt. Es kann zwar noch ein bisschen weitergehen – aber nicht mehr allzu lange. Ich muss mir Gedanken machen, ob ich auch mein Blog hier einfach sterben lasse – oder welche Alternativen es gäbe.

Das mache ich, wie es sich für einen richtigen Blogger gehört, öffentlich. Und ihr dürft gerne mitdiskutieren. Ich bin sehr gespannt auf eure Meinungen und Anregungen. Ich weiss, dass viele von euch sich besser mit Content-Management-Systemen, Webdesign und diesen Dingen auskennen, als ich das tue – und ich darum einiges lernen kann, was meine Optionen angeht. Darum lasst es mich via Kommentare wissen, wenn euch etwas einfällt, woran ich nicht gedacht habe.

Also, ich werde an dieser Stelle die Möglichkeiten einer Migration erörtern. Denn damit wären alle Probleme gelöst: Alle Inhalte wandern von Flatpress in ein neues CMS und fertig. Ich mache weiter wie gehabt – bis ich an Altersschwäche von meinem Blogger-Hocker falle.

Content-Management-Systeme sind oft Silos

Doch geht das wirklich so einfach? Zweifel sind angebracht, weil Content-Management-Systeme sehr oft Silos sind: Man bekommt Inhalte, wenn sie einmal drinstecken, kaum mehr heraus – jedenfalls nicht so, dass man sie andernorts einfach weiterverwenden könnte. Und 2100 Beiträge von Hand transferieren – das kommt nicht in Frage.

Wenn man sich die Situation für Flatpress ansieht, dann springt sogleich ein Fünkchen Hoffnung: Es gibt einen Exporter für Flatpress, der hier beschrieben wird und hier zu finden ist. Doch wenn man die Notes on Migrating Flatpress to WordPress eines Bloggers namens Pappp liest, verfliegt der Optimismus sogleich wieder: «It is seriously aggravating», schreibt er: «Ernsthaft verdriesslich.»

The script does extract a nice sql file with the text of all old posts, including the title, date and time, author (as numeric ID), and comments. It also generates part of the SQL needed to import the categories, but not all of it, and none of the old category information comes with the post. The biggest thing it DOESN’T do is have any mechanism for fixing internal links or images.

Man erhält eine SQL-Datei mit den alten Beiträgen, inklusive Titel, Datum und Zeit und den Kommentaren. Doch die Links in den Beiträgen werden nicht angepasst. Das führt dazu, dass die Beitragsbilder nicht mehr gefunden werden. Ich nehme an, das könnte man nachher in WordPress beheben, zum Beispiel mit einem Werkzeug, das über alle Beiträge sucht und ersetzt. Hier werden entsprechende Tools aufgeführt.

Umstieg nach WordPress: Die Kategorien bleiben auf der Strecke

Es bleiben aber auch einige Dinge auf der Strecke, zum Beispiel die Kategorien:

There is also a problem in that some things don’t move at all with the script: the worst example is that because FP tags each post with a list of category ID numbers, and WP uses a table to associate posts with tags, indirected with another table to mark some tags as categories, it is essentially impossible to programmatically move the category information.

Die Kategorien sind bei 2100 Beiträgen wirklich wichtig und sollten nicht verloren gehen. Das grösste Problem ist allerdings, dass das Script bei mir nicht durchläuft. Es wirft Tonnen von Fehlermeldungen aus und bleibt dann mittendrin mit folgender Meldung hängen:

Fatal error: Maximum execution time of 30 seconds exceeded in /home/clickomania.ch/html/fp/fp-plugins/bbcode/inc/stringparser_bbcode.class.php on line 999

Das Script scheitert an der Zahl der Posts; der Export bleibt ungefähr auf der Hälfte stecken. Da ich die PHP-Einstellungen nicht kontrollieren kann, müsste ich die Site lokal aufsetzen, um sie dort zu exportieren. Doch ich bin kein PHP-Experte und müsste daher sehr viel Zeit in frustrierende Versuche investieren, die Fehler zu beseitigen und den Export durchzubekommen.

Das Problem habe ich gelöst, indem ich die Site lokal aufgesetzt habe, und zwar mittels Z-WAMP, einer wunderbar kompakten Serverumgebung mit Apache und PHP. Wenn ich die allerälteste Variante nehme (zwamp-i386-1.1.2), dann kommt da auch eine ausreichend angejahrte Version von PHP mit, die noch zu Flatpress kompatibel ist. Denn, ein anderes Problem von Flatpress ist, dass dieses CMS nicht mehr mit den aktuellen PHP-Versionen läuft. Damit kann ich die Variable max_execution_time beliebig hochsetzen und den Export ausführen. Das Resultat ist eine gut 14 MB grosse Datei. Die sollte alle Blogposts und die Kommentare enthalten – mit der Grösse kommt das etwa hin.

Wie gelangt die WordPress-Datei ins WordPress hinein?

Erste Versuche mit dem Import bei WordPress.com führen zu folgender Fehlermeldung:

Dies scheint keine WXR-Datei zu sein, WXR-Versionsnummer fehlt/ist ungültig.

Aber gut, ich wusste ja, dass es nicht einfach werden würde. Das Problem ist natürlich, dass das Exportscript schon etwa sieben Jahre alt ist und sich WordPress inzwischen weiterentwickelt hat. Aber ich werde mein Glück mit der Anleitung unter How to fix the WXR version error when importing a very old WordPress export file probieren. Das Problem liegt darin, dass es sich nicht um eine WordPress-Exportdatei handelt – die Methode gab es damals wahrscheinlich noch gar nicht.

Es handelt sich um einen MySQL-Dump. Um den in WordPress hineinzubekommen, muss man WordPress lokal aufsetzen, den Dump (mit phpMyAdmin, auch so ein Wunderding!) importieren, dabei möglichst alle Fehler ignorieren, die zwangsläufig auftreten können und am Schluss schauen, was herauskommt. Bei mir hat das inzwischen teilweise geklappt.

Es sieht gruselig aus

Es kommen Beiträge in WordPress an, aber das ganze sah erst gruselig aus: Zu viele Zeilenumbrüche, fehlende Bilder (die ich allerdings auch noch nicht hochgeladen hatte) und die nicht richtig verknüpften Kategorien. Und irgendwie entstanden beim Export doppelte Primary-Schüssel, was der Datenbank natürlich nicht gefiel. Ich muss sehen, ob ich die irgendwie automatisch neu durchnummerieren kann.

Auch diese Probleme haben sich inzwischen lösen lassen: In MySQL kann man, wiederum dank phpMyAdmin bequem suchen und ersetzen und so auch die Pfade der Bilder entsprechend umbiegen. Nach etwa einem Tag Arbeit sieht die Site schon vielversprechend aus. Die Kategorien gehen aber definitiv verloren. Und das schmerzt.

Fazit an dieser Stelle: Ein Import ist möglich, aber ich werde noch einige Arbeit reinstecken müssen, damit die alten Inhalte in WordPress präsentabel daherkommen. Und es bleibt ein Problem mit wpexport: Dieser Weg zwingt mich, zu WordPress zu wechseln. Das ist naheliegend, aber ich würde lieber trotzdem nicht vor vollendete Tatsachen gestellt werden, sondern selbst entscheiden, ob es nicht eine bessere Lösung für mich gibt. Gut, wahrscheinlich könnte man die WordPress-Datenbank irgendwie weiterverwursteln. Aber das stelle ich mir einigermassen haarsträubend vor.

Das Blog scrapen?

Bleiben zwei weitere Möglichkeiten: Erstens Blog-Scraping: Das wird typischerweise betrieben, um fremde Inhalte zu klauen. Aber vielleicht kann man eine solche Lösung auch dazu verwenden, die eigenen Inhalte in eine Form zu überführen, in der man sie in ein anderes CMS importieren kann? Falls jemand sich damit auskennt, bin ich froh um Tipps!

Zweitens eine Software wie HTTrack: Die spiegelt eine Site aus dem Web in ein Verzeichnis. Der Clou ist, dass eine dynamische Site quasi statisch eingefroren wird: Man hat eine Ordnerstruktur mit HTML-Seiten und Bildern, die ohne das ursprüngliche CMS benutzt werden kann. Die meisten Dinge sollten weiterhin funktionieren wie gehabt. Was nicht mehr funktioniert, ist die Suchfunktion. Man kann keine Kommentare mehr hinzufügen. Und natürlich kann man keine Konfigurationsänderungen mehr an seiner Site vornehmen – denn die Seiten, die vorher dynamisch generiert worden sind, die sind jetzt in Stein, bzw. in HTML gemeisselt.

Mit HTTrack ist keine echte Migration möglich. Man kann aber die Website aber in einem Zustand archivieren, in dem sie online bleiben und theoretisch bis in alle Ewigkeit weiter benutzt werden kann. Ich habe die Software mal probehalber auf meine Website angesetzt, um zu sehen, ob etwas Brauchbares herauskommt.

Das Fazit dazu: Das «Tracken» dauert lange. Man kann es beschleunigen, indem man bei Site-Kopie > Optionen ändern im Reiter Grenzwerte die standardmässig auf 25’000 Bit pro Sekunde eingestellte maximale Übertragungsrate entfernt. Die ist dazu da, Server und Internetverbindung zu schonen – doch die Voreinstellung stammt aus dem ISDN-Zeitalter und ergibt in der Glasfaser-Ära absolut keinen Sinn. Auch die Anzahl Verbindungen kann man im Reiter Flusskontrolle stark erhöhen, zum Beispiel auf 20.

Per HTTrack eine Offline-Kopie ziehen

Per HTTrack entsteht eine Datenstruktur, die viel grösser ist als die Original-Site. Das liegt daran, dass die diversen Übersichtsseiten (nach Kategorien, Monaten) ebenfalls statisch gespeichert werden müssen. Daraus ergeben sich einige Tipps fürs Archivieren eigener Seiten:

• Es lohnt sich, auf ein minimalistisches Theme umzuschalten, bei dem man zur Not auch per HTML-/CSS-Editor eingreifen kann.
• Alle unnötigen Elemente wie zum Beispiel Share-Buttons, Widgets und ähnliche Dinge sollte man löschen.
• Und auch Kategorien müsste man vorab bereinigen – hinterher ist es quasi unmöglich bzw. extrem aufwändig, an der Struktur noch etwas zu ändern. Die sprachliche Kategorie Deutsch ist in meinem Blog nutzlos, weil die allermeisten Beiträge in deutsch abgefasst sind. Sie zieht den Download via HTTrack aber enorm in die Länge.
• In den Optionen von HTTrack empfehle ich, bei Grenzwerte den Wert für Maximale externe Tiefe auf 0 zu setzen: Man will nur die Inhalte auf der eigenen Site, nicht aber auf anderen Websites archivieren.

Soviel zu den Möglichkeiten der Migration. Morgen geht es um meine konkreten Pläne – so weit sie sich bis jetzt herauskristallisiert haben.