Eine Dokumentation zur Konvertierung meines 12 Jahre lang gerne genutzten DokuWiki hin zu einer Website mit rein statischen Inhalten, die kein PHP mehr benötigen und den Betrieb meines Wikis als reines Archiv ermöglichen.
Update: Jemand hat per E-Mail angemerkt, dass WordPress zwar mehr Anforderungen habe, dafür aber auch mehr Funktionalität wie Login oder Teamfähigkeit (die ich aber auch nicht benötige). Das ist richtig. :) Ich habe Anfang Februar 2022 diesen Blog hier von WordPress auf Hugo umgestellt. Ich lasse hier mal die Liste...
Im Zweiten Teil wird beschrieben, wie man die beim Export übrig gebliebenen HTML-Quelltexte, die nicht nach Markdown konvertiert werden konnten, automatisiert so verändert, dass der neue Blog ansehnlich wird. Somit kann man den Blog schon öffentlich machen, noch bevor man alle Beiträge und Seiten manuell überprüft und konvertiert hat.
Eine Dokumentation, wie ich von WordPress auf Hugo umgezogen bin. Ich beschriebe, weshalb ich überhaupt gewechselt bin, wie ich das technisch umgesetzt habe und wie man es schafft, dass man am Ende dieses ersten Teils lokal auf den eigenen neuen Blog mit den exportierten Inhalten per Browser zugreifen kann.
Manche Plugins für WordPress legen eigene Tabellen in der Datenbank an. Hat man, wie hier im Blog, verschiedenste Plugins genutzt, dann sammeln sich über die Jahre viele unnütze Tabellen an. Diese kann man entweder manuell löschen oder mit einem WordPress-Plugin, wie z. B. diesem hier. Von einst 134 Dateien im...
Ein Vorteil des dateibasierten DokuWiki gegenüber datenbankbasierten Wikis ist z. B., dass man es komplett offline ohne Webserver bearbeiten und auch eingeschränkt nutzen kann, vorausgesetzt man ist mit der recht einfachen Syntax vertraut.
Ich habe ein lokales Wiki, für das ich meist nur dann den lokalen Webserver anwerfe, wenn ich eine Seite z. B. als PDF exportieren möchte oder die Informationen etwas „schöner“ angezeigt bekommen möchte.
WordPress speichert beim Kommentieren neben den selbst eingegebenen Daten wie Name, E-Mail-Adresse, URL und natürlich dem Kommentar selbst auch noch automatisch die IP-Adresse des Kommentators, den User-Agent des Browsers und noch einige andere Dinge in der Datenbank.
Die bisherige Methode (mit pyetherpad) zur Auflistung aller Pads funktionert seit einiger Zeit nicht mehr; wenn man allerdings als Datenbank MySQL oder SQLite verwendet, statt der voreingestellten Test-Datenbank, dann kann man sehr einfach eine Liste aller Pads erstellen. Die Beschreibung findet sich im Wiki von...