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!