{"type":"rich","html":"
\"PepeCyBs<\/a>PepeCyBs Welt<\/a> wrote the following post <\/a>Fri, 13 Mar 2026 22:46:11 +0100<\/span><\/span><\/div>
Was ein K(r)ampf mit dem DDP-Archiv<\/strong>
\"ddp-archiv.webp\"<\/a>

Es war ja urspr\u00fcnglich mein Plan, s\u00e4mtliche(!) Artikel aus der Dampfdruck-Presse zu WordPress-Zeiten in Hubzillas Artikel-App zu integrieren.

Da es aber deutlich \u00fcber 1.000 Artikel sind, ist das vertretbar nur automatisiert zu erledigen. Das habe ich ja bereits im Artikel "Basis ist der WordPress Export<\/a>" erw\u00e4hnt. Und ich habe inzwischen zwei Skripte f\u00fcr 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\u00e4tte 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\u00f6nnte ich die Artikel einzeln \u00fcber die App erstellen (Copy & Paste), m\u00fcsste dann aber das Erstellungsdatum noch in der Datenbank korrigieren, damit die Reihenfolge passt. Und die Kommentare h\u00e4tte ich mit dieser Methode auch noch nicht drin. Das w\u00e4re nochmal extra Handarbeit und weitere DB-Manipulation.

Neee... nicht praktikabel.

Dann habe ich \u00fcberlegt, ob sich die Artikel nicht direkt, ebenfalls mit einem Skript, in die Datenbank einf\u00fcgen lassen k\u00f6nnten.

Ich bin mir sicher, das geht. Nur... es gibt in der DB-Tabelle "items" ne menge Felder, bei denen ich nicht genau wei\u00df, wie wichtig sie sind und ich m\u00fcsste mich erst noch drum k\u00fcmmern, dass die ganzen Id's ordentlich eingetragen w\u00fcrden. Daf\u00fcr ist die Dokumentation aber einfach zu d\u00fcnn. Und der Aufwand f\u00fcr solch ein Skript auch sehr gro\u00df... und es w\u00fcrde einen weiteren eigenen Entwicklungs-Hub erfordern, damit ich mir nicht meinen Produktiv-Hub durch Zerhackst\u00fccken der Datenbank abschie\u00dfe, wenn ich das Skript teste.

Machbar w\u00e4re es, aber der Aufwand (vor allem der Zeitaufwand) ist so gro\u00df, dass ich das eher vorerst nicht hinbekomme (ich werde aber... falls ich irgendwann mal Zeit daf\u00fcr er\u00fcbrigen kann, an einem solchen Skript arbeiten... k\u00f6nnte 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\u00f6sche n\u00e4mlich 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<\/code> 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\u00e4dt normalerweise die zu jedem Artikel dazugeh\u00f6rigen Mediendateien (also in der DDP ausschlie\u00dflich Bilder) herunter und baut sie in die Artikel ein.

Doch der Download klappte nicht, sodass alle Artikel zun\u00e4chst "bilderlos" erschienen. Ich habe zwar auch diese Mediendateien (wp-content\/uploads<\/code>) lokal auf meinem Rechner, aber ich h\u00e4tte nun bei jedem einzelnen Artikel die Bilder manuell von dort aus einf\u00fcgen m\u00fcssen. Bei \u00fcber 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\u00df der einen Rat."

Und tats\u00e4chlich 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\u00fcr 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\u00fchrt, die Artikel doch noch in die Publii-Seite zu bringen, aber nichts hat geklappt. Schlie\u00dflich "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\u00f6nnen. Und tats\u00e4chlich 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%93<\/em>Client-Fehler]404[\/url]" quittiert. Die Rechte f\u00fcr 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<\/code> Datei mit einer Rewrite-Regel f\u00fcr eine permanente Umleitung der Domain auf die Artikel der Hubzilla-DDP erstellt habe. Und die w\u00fcrde ja auch daf\u00fcr sorgen, dass der Zugriff auf die Mediendateien nach hub.hubzilla.hu<\/code> umgeleitet w\u00fcrde, wo diese so nicht vorhanden sind.

Also tempor\u00e4r die Rewrite-Regel nach Groks Vorschlag ge\u00e4ndert. Aber es gab trotzdem keinen Zugriff.

Ok... dann halt "auf die harte Tour"... .htaccess<\/code> gel\u00f6scht!

Aber trotzdem kein Zugriff. Ich verzweifle noch. Grok serviert mir einige Tests, die ich durchlaufen lie\u00df 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\u00e4ge. 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\u00e4ndischen Einf\u00fcgen der Grafiken in alle Artikel. Ne Sache f\u00fcr ein paar Monate.

Es war dann schon wirklich sp\u00e4t, n\u00e4mlich nicht mehr gestern, sondern schon heute.

Aber irgendwie lie\u00df es mir keine Ruhe, dass die Archiv-Datei von Simply Static unvollst\u00e4ndig sein sollte. Ich hatte mit dem Tool ja schon Archive der inzwischen eingestellten Projekte "Nebelkr\u00e4he<\/a>" und "ExRaucher-IG<\/a>" erstellt und die waren vollst\u00e4ndig. Da fehlte nix.<\/strong>

Weshalb also denn aber bei der DDP?<\/strong>

Letztlich war mir meine Bequemlichkeit und die Gewohnheit auf die F\u00fc\u00dfe gefallen... in Verbindung mit Software-Unzul\u00e4nglichkeiten.

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\u00f6ffnet. 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\u00e4ndig? Und entpackt es "unzip" im Terminal vielleicht vollst\u00e4ndig?

Also ausprobiert. Und tats\u00e4chlich waren nun in dem Verzeichnis s\u00e4mtliche 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\u00fcrde 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\u00df denn?

Ich hab dann im Terminal mal den MidnightCommander angeschmissen... und da wurde diese Verzeichnisse mit einem f\u00fchrenden Punkt (also quasi als versteckte Verzeichnisse) angezeigt, ich konnte sie aber \u00f6ffnen 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 \u00f6ffnen. 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 \u00f6ffnen und auf die Inhalte zugreifen.

Noch mehr Fragezeichen \u00fcber meinem Kopf!

Ok... wenn die Verzeichnisse und deren Inhalt vorhanden sind, dann k\u00f6nnte 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\u00e4ft? Nein, schl\u00e4ft nicht. Ich habe dann nach m\u00f6glichen Ursachen f\u00fcr dieses Verhalten, das ich mir nicht erkl\u00e4ren konnte, gefragt und mir wurden dann wieder etliche Tests vorgeschlagen, die ich durchgef\u00fchrt habe. Z.B. ein Test darauf, ob die Verzeichnisnamen f\u00fchrende unsichtbare Leerzeichen haben oder ob die Verzeichnisnamen ungew\u00f6hnliche Sonderzeichen (die nicht angezeigt werden) enthalten. Alles negativ. Schlie\u00dflich bekam ich die Info, dass es wom\u00f6glich daran liegen k\u00f6nnte, dass die Verzeichnisnamen sehr lang sind und viele Bindestriche enthalten, womit Dolphin und etliche andere Dateimanager anscheinend nicht klark\u00e4men. 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\u00fcr 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<\/a> jetzt wirklich vollst\u00e4ndig.<\/strong>

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 \u00fcber ein Webformular durchsuchbar ist. In der Seitenleiste der DDP (Hubzilla) gibt es nun einen Link "DDP-Archiv durchsuchen"

\"archivsuche01.png\"<\/a>

der zu einem Suchformular f\u00fchrt, mit welchem man das Archiv bis zu den Anf\u00e4ngen im Jahr 2013 durchsuchen kann.

\"archivsuche02.png\"<\/a>

Also... auch \u00e4ltere Artikel sind und bleiben verf\u00fcgbar. 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!<\/strong><\/div><\/div>
<\/div>","width":640,"height":426}