Es war ja ursprünglich mein Plan, sämtliche(!) Artikel aus der Dampfdruck-Presse zu WordPress-Zeiten in Hubzillas Artikel-App zu integrieren.

Da es aber deutlich über 1.000 Artikel sind, ist das vertretbar nur automatisiert zu erledigen...

Es war ja ursprünglich mein Plan, sämtliche(!) Artikel aus der Dampfdruck-Presse zu WordPress-Zeiten in Hubzillas Artikel-App zu integrieren.

Da es aber deutlich über 1.000 Artikel sind, ist das vertretbar nur automatisiert zu erledigen. Das habe ich ja bereits im Artikel "Basis ist der WordPress Export" erwähnt. Und ich habe inzwischen zwei Skripte für diesen Zweck. Eines, das die Artikel aus einer WXR-Datei in einzelne BBcode-Dateien umwandelt und eines, welches das auch noch mit den Kommentaren zum Artikel macht.

Dann hätte ich die Artikel im korrekten Format. Funktioniert auch prima.

Die Artikel dann aber in die Artikel-App von Hubzilla zu bringen, ist nicht wirklich trivial. Sicher könnte ich die Artikel einzeln über die App erstellen (Copy & Paste), müsste dann aber das Erstellungsdatum noch in der Datenbank korrigieren, damit die Reihenfolge passt. Und die Kommentare hätte ich mit dieser Methode auch noch nicht drin. Das wäre nochmal extra Handarbeit und weitere DB-Manipulation.

Neee... nicht praktikabel.

Dann habe ich überlegt, ob sich die Artikel nicht direkt, ebenfalls mit einem Skript, in die Datenbank einfügen lassen könnten.

Ich bin mir sicher, das geht. Nur... es gibt in der DB-Tabelle "items" ne menge Felder, bei denen ich nicht genau weiß, wie wichtig sie sind und ich müsste mich erst noch drum kümmern, dass die ganzen Id's ordentlich eingetragen würden. Dafür ist die Dokumentation aber einfach zu dünn. Und der Aufwand für solch ein Skript auch sehr groß... und es würde einen weiteren eigenen Entwicklungs-Hub erfordern, damit ich mir nicht meinen Produktiv-Hub durch Zerhackstücken der Datenbank abschieße, wenn ich das Skript teste.

Machbar wäre es, aber der Aufwand (vor allem der Zeitaufwand) ist so groß, dass ich das eher vorerst nicht hinbekomme (ich werde aber... falls ich irgendwann mal Zeit dafür erübrigen kann, an einem solchen Skript arbeiten... könnte ja anderen Nutzern helfen).

Die WordPress-Version der DDP ist ja komplett auf dem "Trockendock". Auf sie hat kein Nutzer mehr Zugriff. Um aber alle Artikel weiterhin erreichbar zu halten (ich lösche nämlich nicht einfach einen Teil der Dampfer-Geschichte), habe ich mit dem Plugin "Simply Static" eine statische Version der DDP erstellt und dieses Archiv konnte ich dann als ZIP-Datei herunterladen. Ich habe es so erstellt, dass die "alte" DDP unter dampfdruck-presse.de erreichbar sein soll.

Also habe ich die Datei lokal entpackt und mit ftp zum Server hochgeladen.

Schnell fiel mir jedoch auf, dass anscheinend nur ca. 1/3. der Artikel auf dem Server landeten. Und so dachte ich, dass ich dann halt aus der ohnehin vorhandenen WXR-Dateien per Importfunktion von Publii eine statische Publii-Version erstelle.

Das klappte auch... aber nur fast! Denn das Skript lädt normalerweise die zu jedem Artikel dazugehörigen Mediendateien (also in der DDP ausschließlich Bilder) herunter und baut sie in die Artikel ein.

Doch der Download klappte nicht, sodass alle Artikel zunächst "bilderlos" erschienen. Ich habe zwar auch diese Mediendateien (wp-content/uploads) lokal auf meinem Rechner, aber ich hätte nun bei jedem einzelnen Artikel die Bilder manuell von dort aus einfügen müssen. Bei über 1.000 Artikeln und ca. 7.700(!) Grafikdateien eine Wahnsinns-Aufgabe.

Weil ich damit also auch nicht weiter kam, dachte ich mir gestern Nachmittag einfach mal: "Frag doch einfach mal Onkel Grok! Vielleicht weiß der einen Rat."

Und tatsächlich gab es auch einen sinnvoll erscheinenden Rat. Ich sollte mir doch einfach die Import-Funktion von Publii sparen und die Artikel mit einem Skript, das er mir lieferte, konvertieren und diese, sowie die Mediendateien in das "input"-Verzeichnis des Publii-Projekts kopieren. Das funktioniert wohl meistens... manchmal... vielleicht auch bei mir.

Nach einige Nachbesserungen am Skript wurde also ein Durchlauf gemacht und es wurden auch die Markdown-Dateien für Publii erzeugt. Nur... Publii hat es nicht in seine Datenbank eingebaut. Weder die Artikel, noch die Mediendateien. Grok hat mit mir dann etliche Versuche durchgeführt, die Artikel doch noch in die Publii-Seite zu bringen, aber nichts hat geklappt. Schließlich "einigten" wir uns darauf, es doch mit dem WordPress-Import von Publii selbst zu machen.

Aber es wurden, wie gesagt, die Mediendateien nicht importiert. Es gab die Fehlermeldung, dass sie nicht heruntergeladen werden können. Und tatsächlich ging das nicht. Jeder Zugriff auf eine Mediendatei (also ein Bild) wurde von Apache mit einem "[url=https://de.wikipedia.org/wiki/HTTP-Statuscode#4xx%E2%80%93Client-Fehler]404[/url]" quittiert. Die Rechte für die Dateien und Verzeichnisse waren ok. Daran konnte es also nicht liegen.

Der eigentliche Grund schien folgender zu sein: Ich hatte die alte WordPress-DDP ja "aufs Trockendock" geschickt... und zwar, indem ich eine .htaccess Datei mit einer Rewrite-Regel für eine permanente Umleitung der Domain auf die Artikel der Hubzilla-DDP erstellt habe. Und die würde ja auch dafür sorgen, dass der Zugriff auf die Mediendateien nach hub.hubzilla.hu umgeleitet würde, wo diese so nicht vorhanden sind.

Also temporär die Rewrite-Regel nach Groks Vorschlag geändert. Aber es gab trotzdem keinen Zugriff.

Ok... dann halt "auf die harte Tour"... .htaccess gelöscht!

Aber trotzdem kein Zugriff. Ich verzweifle noch. Grok serviert mir einige Tests, die ich durchlaufen ließ und die klar zeigten, dass der Zugriff auf Ressourcen schlicht blockiert war. Und ich sollte nun die Apache-Konfiguration modifizieren... auch da bekam ich einige Vorschläge. Doch zu dem Zeitpunkt war meine Geduld echt aufgebraucht und ich habe abgewunken. Vor allem auch, weil ich mir meinen Apache nicht zerkloppen wollte. Die Euroleague-Spiele waren auch schon mit miesen Ergebnissen zu ende (ich habs nebenbei im Augenwinkel verfolgt)... neee... reicht. Dann halt erstmal nicht. Also doch, aber die miese Methode mit dem händischen Einfügen der Grafiken in alle Artikel. Ne Sache für ein paar Monate.

Es war dann schon wirklich spät, nämlich nicht mehr gestern, sondern schon heute.

Aber irgendwie ließ es mir keine Ruhe, dass die Archiv-Datei von Simply Static unvollständig sein sollte. Ich hatte mit dem Tool ja schon Archive der inzwischen eingestellten Projekte "Nebelkrähe" und "ExRaucher-IG" erstellt und die waren vollständig. Da fehlte nix.

Weshalb also denn aber bei der DDP?

Letztlich war mir meine Bequemlichkeit und die Gewohnheit auf die Füße gefallen... in Verbindung mit Software-Unzulänglichkeiten.

Eigentlich bin ich ja sehr gerne mit der Kommandozeile, also im Terminal mit der Shell unterwegs. Aber die ZIP-Datei des statischen Archivs habe ich (ich nutze Plasma/KDE) mit dem KDE-Tool "Ark" geöffnet. Und damit auch lokal entpackt. Was dabei auffiel war, dass zwar alle Verzeichnisse aus dem ZIP-Archiv in Ark angezeigt wurden, aber nicht alle entpackt wurden.

Also habe ich das Archiv auf der Kommandozeile untersucht und festgestellt, dass es intakt ist.

Aber weshalb entpackt Ark es nicht vollständig? Und entpackt es "unzip" im Terminal vielleicht vollständig?

Also ausprobiert. Und tatsächlich waren nun in dem Verzeichnis sämtliche Unterverzeichnisse samt Inhalt vorhanden (laut ls). In Dolphin (dem GUI-Dateimanager) auch... aber wenn ich die Verzeichnisse, die beim Entpacken mittels Ark fehlten, anklickte, bekam ich die Meldung, das Verzeichnis würde nicht existieren. Im Terminal konnte ich aber mit cd in diese Verzeichnisse wechseln... und mir auch die Inhalte z.B. mit cat ausgeben lassen. Nanu? Was soll der Scheiß denn?

Ich hab dann im Terminal mal den MidnightCommander angeschmissen... und da wurde diese Verzeichnisse mit einem führenden Punkt (also quasi als versteckte Verzeichnisse) angezeigt, ich konnte sie aber öffnen und die Inhalte auch anzeigen lassen.

Ein Punkt vornedran? Wieso werden sie mir denn dann in Dolphin angezeigt (ich habe ihn als Default so eingestellt, dass verborgene Dateien und Verzeichnisse nicht im Fenster angezeigt werden)?

Ark hat sie also nicht entpackt, unzip aber schon. Und in Dolphin werden sie dann auch angezeigt, sie lassen sich aber nicht öffnen. Sehr seltsam.

Nun, dann habe ich mal Thunar angeworfen (der Dateimanager von XFCE)... und der verhielt sich genauso wie Dolphin. Und der Dateimanager "Cosmic Dateien" ebenfalls. Ach... ich hab ja auch noch PCManFM, den Dateimanager von lxqt auf Tasche. Also auch mal ausprobieren! Und siehe da... da wurden die "seltsamen" Verzeichnisse nicht nur angezeigt, sondern ich konnte sie auch öffnen und auf die Inhalte zugreifen.

Noch mehr Fragezeichen über meinem Kopf!

Ok... wenn die Verzeichnisse und deren Inhalt vorhanden sind, dann könnte ich es ja ausprobieren, das mit unzip entpackte Archiv per ftp hochzuladen. Nur... in FileZilla wurden die Dateien wieder nicht angezeigt. Aaaargh!

Ob Grok schon schläft? Nein, schläft nicht. Ich habe dann nach möglichen Ursachen für dieses Verhalten, das ich mir nicht erklären konnte, gefragt und mir wurden dann wieder etliche Tests vorgeschlagen, die ich durchgeführt habe. Z.B. ein Test darauf, ob die Verzeichnisnamen führende unsichtbare Leerzeichen haben oder ob die Verzeichnisnamen ungewöhnliche Sonderzeichen (die nicht angezeigt werden) enthalten. Alles negativ. Schließlich bekam ich die Info, dass es womöglich daran liegen könnte, dass die Verzeichnisnamen sehr lang sind und viele Bindestriche enthalten, womit Dolphin und etliche andere Dateimanager anscheinend nicht klarkämen. Ob dem so ist? Keine Ahnung. Es sieht aber zumindest danach aus. Klingt zumindest plausibel.

Mir wurde dann vorgeschlagen, die ftp-Funktion von PCManFM für den Upload zu nutzen, wenn dieser Dateimanager alles richtig anzeigt und den Zugriff erlaubt. Es war mittlerweile drei Uhr morgens und ich habe mich artig bedankt und den Versuch auf "nach dem Aufstehen" verschoben.

Und heute Vormittag hab ich das dann gemacht. Hat lange gedauert (die Mediendateien haben echt viel Zeit verbraucht... kein Wunder bei der Menge an Grafikdateien), aber irgendwann war es erledigt. Und vor allem ist das Archiv unter dampfdruck-presse.de jetzt wirklich vollständig.

Einen Nachteil hat das statische Archiv von Simply Static aber noch! Die Suchfunktion funktioniert nicht! Zumindest nicht bei der kostenlosen Variante, die ich verwendet habe. Es gibt zwar ein Suchfeld, aber das bringt keine Ergebnisse.

Allerdings habe ich ein Skript, das einen Index des DDP-Archivs erzeugt, der dann über ein Webformular durchsuchbar ist. In der Seitenleiste der DDP (Hubzilla) gibt es nun einen Link "DDP-Archiv durchsuchen"



der zu einem Suchformular führt, mit welchem man das Archiv bis zu den Anfängen im Jahr 2013 durchsuchen kann.



Also... auch ältere Artikel sind und bleiben verfügbar. Eine Sache, die mir sehr wichtig ist und die auch jetzt, nach der Umstellung der DDP auf Hubzilla als CMS erhalten bleibt.

Was ne nervenaufreibende Nacht... was ein K(r)ampf... aber es ist geschafft!

Bei allen Überlegungen, wie ich es denn letztlich realisieren möchte, läuft es in fast allen Fällen darauf hinaus, dass ich die Inhalte des WordPress Blogs exportieren muss...

Bei allen Überlegungen, wie ich es denn letztlich realisieren möchte, läuft es in fast allen Fällen darauf hinaus, dass ich die Inhalte des WordPress Blogs exportieren muss. Auf welche Weise ich diese dann verarbeite, hängt vom gewählten Weg ab.

Die Export-Funktion von WordPress ist ganz einfach zu benutzen. Man findet sie in der Seitenleiste unter dem Menüpunkt "Werkzeuge".



Man kann dort alle möglichen Inhalte exportieren, ja sogar alle auf ein Mal. Nun, alle brauche ich nicht. Ich brauche tatsächlich nur die Beiträge (inklusive der Kommentare). Und weil in der DDP so viele Beiträge existieren und die Sicherungsdatei extrem groß werden würde, habe ich mich entschieden, je einen Export für jeweils ein Jahr zu erzeugen.





Und dann habe ich eine Export-Datei (die Sicherungsdateien werden von WordPress als WXR-Dateien – für WordPress eXtended RSS - bezeichnet) im XML-Format.



Diese Dateien sind für Publii und dessen Import-Funktion direkt nutzbar. Allerdings werden nur die Artikel selbst importiert. Die Kommentare bleiben unberücksichtigt.

Ansonsten sind die WXR-Dateien aber nicht wirklich für die direkte Nutzung geeignet. Um sie z.B. für die Artikel-App von Hubzilla zu verwenden, muss man die eigentlichen Artikel extrahieren und ins BBcode-Format umwandeln. Und die Kommentare müssen auch (am besten separat) extrahiert werden.

Per Hand ein riesiger Aufwand. Dafür müssen Helfer-Skripte her... aber dazu später mehr (sind schon in Arbeit).

Lediglich für die Variante mit einem externen statischen Archiv werden die Exportdateien nicht benötigt (schadet aber auch nicht, welche als Backup zu haben). Ich würde dafür Simply Static nutzen, mit dem ich schon gute Erfahrungen gemacht habe.

Ich bin mir inzwischen sicher, bzw. ich bin fest entschlossen, mein Blog "Die Dampfdruck-Presse" (aktuell noch mit WordPress) in Zukunft nur noch mit Hubzilla als CMS anzubieten...

Ich bin mir inzwischen sicher, bzw. ich bin fest entschlossen, mein Blog "Die Dampfdruck-Presse" (aktuell noch mit WordPress) in Zukunft nur noch mit Hubzilla als CMS anzubieten.

Die Gründe dafür sind die irrsinnigen KI-Ideen der WordPress-Entwickler und auch ein Stück weit Glaubwürdigkeit (immerhin predige ich ja schon lange, dass Hubzilla auch als vollwertiges CMS gut nutzbar ist).

Die Basis existiert ja auch schon eine ganze Weile: Dampfdruck-Presse bei Hubzilla. Ich pflege dieses Parallel-Blog seit dem Start mit den neuen Artikeln, die ich in der WordPress-Version veröffentliche. Und ein paar ältere Artikel habe ich auch schon konvertiert... zu Fuß.

Und genau da liegen die Probleme! Das wirklich per Hand einzeln zu machen, ist ein enormer Aufwand. Immerhin gibt es ja (aktueller Stand) 1.075 Artikel. Wenn ich die alle einzeln konvertieren möchte und vielleicht am Tag durchschnittlich drei bis vier Artikel hinbekäme, dann wäre ich locker bis zu einem Jahr damit beschäftigt.

Schöne Scheiße!

Nun gibt es mehrere Möglichkeiten.

Die einfachste wäre, das WordPress Blog als Archiv bestehen zu lassen und künftig nur noch im Hubzilla-Blog zu veröffentlichen. Allerdings müsste ich dann die Updates dafür abschalten oder es in ein statisches Blog umwandeln (das funktioniert ganz manierlich).

Der Vorteil: Die Kommentare blieben sauber bestehen. Es würde nichts verloren gehen.

Der Nachteil: Die DDP wäre in zwei Teile aufgeteilt, also quasi zerrissen.

Hier überwiegt der Nachteil! Ich könnte die statische Version (denn so würde ich es machen, um WordPress auch wirklich loszuwerden) unter dampfdruck-presse.de laufen lassen und das aktuelle Blog (also das mit Hubzilla) unter dampfdruck-presse.hu laufen lassen. Es gefällt mir so aber nicht!

Eine weitere Möglichkeit wäre, das WordPress Blog per Import als Publii-Blog zu konvertieren. Das funktioniert auch sehr gut. Dieses statische Blog könnte ich dann auch mit Hubzilla anbieten. Das wäre dann das "Archiv". Das aktuelle Blog würde mit Hubzilla und der App "Artikel" fortgeführt. Es gäbe dann halt einen Link zum Archiv, der zum Publii-Archiv in der Hubzilla-Cloud führen würde.

Der Vorteil: Alles wäre an einem Ort und unter einer Domain zu erreichen.

Der Nachteil: Die Kommentare müsste ich per Hand einpflegen, denn die werden von der Import-Funktion nicht erfasst.

Und schließlich könnte ich tatsächlich das ganze Blog komplett als Hubzilla-Artikel konvertieren.

Der Vorteil: Alles wäre aus einem Guss.

Der Nachteil: Wie schon erwähnt, wäre das eine Mords-Arbeit bei so vielen Artikeln. Da müsste ich mir Helfer-Skripte basteln.

Nun, ich werde jetzt nach und nach an allen Varianten herumtüfteln, schauen, was sich automatisieren und vereinfachen lässt und es sicher irgendwann irgendwie schaffe, die DDP komplett zu Hubzilla umzuziehen.

Und ich nehme Euch gerne mit auf diese Reise, indem ich die einzelnen Schritte und Experimente hier dokumentiere und erläutere. Es kommen also jetzt nach und nach etliche weitere Artikel zu dem Thema "Von WordPress zu Hubzilla".