Die Rettung meines alten Blogs ist plötzlich möglich
Vorgestern vor einem Monat musste ich mein altes Blog löschen und habe angefangen, auf diesem neuen Blog zu schreiben. 963 Texte und 1700 Kommentare aus 18 Jahren Arbeit schienen unrettbar verloren. Doch vor fünf Tagen stellte ich fest, dass das nicht stimmt, und jetzt stehe ich vor der Frage: Mache ich dieses Blog weiter oder kehre ich zu meinem alten mit Wordpress zurück, auch wenn sich die Adresse etwas ändern würde. Dies ist die Geschichte einer Rettungsaktion, mit der nicht nur ich mich bestimmt 40 Stunden beschäftigt habe. Und dass sie funktionieren würde, damit habe ich nicht gerechnet.
Als das Wa(h)renhaus von Viren verseucht wurde, blieb mir nur, radikal das gesamte Wordpress zu löschen, ohne lange darüber nachzudenken. Gott sei Dank löschte ich nicht auch gleich die Datenbank, sonst hätte ich heute nichts zu schreiben. Geistesgegenwärtig lud ich mir eine vollständige SQL-Datei der Datenbank auf meinen Rechner. Ich stellte mir vor, die Texte aus der Datei herauszusuchen und separat zu speichern, merkte aber schnell, dass das unmöglich war. Die Umlaute der Texte sahen furchtbar aus, die Überschrift der Texte stand nicht am Anfang, sondern am Ende, und es standen viele Sonderzeichen darin, die mir das Lesen sauer machten. Durch meine liebe Freundin @andijah@brotkru.me wurde ich auf das Internet Archive hingewiesen, bei dem meine Seite noch vorhanden sei. Ich schaute nach und stellte fest, dass sie recht hatte. Doch die Seite war nicht in einem Stück vorhanden. 93 mal war der Crawler des Archives über meine Seite gekrabbelt und hatte sich jeweils nur geholt, was neu war. Ich hätte mir alle Stücke nacheinander holen müssen, und ob ich sie dann hätte zusammenbauen können, weiß ich bis heute nicht. Ich sag es ja immer wieder: Auf Mastodon findet man sehr nette Leute. Diesmal war es @petros@literatur.social – Er bot sich an, den Download zu automatisieren und dafür ein Script zu schreiben, dann könnte er die Stücke meiner Seite zusammenfügen. Ich war wirklich sehr erfreut, denn der Verlust der Texte schmerzte mich doch sehr.
Zeit verging.
Am vergangenen Freitag, 11.08.2023, wollte ich die verseuchten Artikel und Einträge aus der Datenbank entfernen, als ersten Schritt zur Wiedergewinnung der Texte sozusagen. Dabei stellte ich etwas erstaunliches fest: Es waren nur 6 Einträge vorhanden, die unentzifferbaren Code enthielten, und sie waren eindeutig zu erkennen. Ich tat etwas, was ich sehr ungern tue: Ich loggte mich mit dem Tool #PHPMyAdmin in die #Datenbank ein, rief die Tabelle mit den Beiträgen auf und löschte die sechs betroffenen Einträge. Das ist eigentlich nicht besonders schwer, doch leider ist PHPMyAdmin für mich etwas verwirrend aufgebaut, und ich kenne längst nicht alle funktionen. Trotzdem gelang es mir. Da ich nicht wusste, ob ich das Datenbankpasswort noch hatte, das Login im PHPMyAdmin geht ohne, kopierte ich mir die jetzt saubere Datenbank auf meinen Rechner und versuchte, mit einem Offline-Tool Wordpress auf meinem Privatrechner ans Laufen zu bringen. Das misslang aus verschiedenen Gründen, vor allem, weil die Links in den Tabellen von Wordpress nicht funktionierten, und weil die Wordpress-Version, die ich verwendete, zu alt war. Also richtete ich auf meinem Webspace von Hand eine neue Datenbank ein und füllte sie mit dem gesäuberten Inhalt der alten. Dann lud ich das veraltete #Wordpress hoch und verband es mit der Datenbank. Nach einigem hin und her schaffte ich es, das Programm ans Laufen zu bringen, konnte mich einloggen und Wordpress sowie ein paar wenige Plugins, die ich dringend brauchte, auf den neuesten Stand bringen. Nichts ist so tödlich für ein Wordpress-System wie Nachlässigkeit beim #Update. Wenn man sich nicht um das System kümmert, kommen die Viren haufenweis. Um das Wordpress übrigens startklar zu machen, musste ich in der Datenbank verschiedene Einstellungen ändern, weil ich ja nicht mehr auf meiner alten Blogadresse war. Das war eine ziemliche Rödelei, bis es endlich ging.
Das nächste Problem tauchte sofort auf: Die Umlaute wurden nicht korrekt dargestellt. Auf meinem alten Blog hatte das funktioniert, aber dort hatte ich ein Plugin verwendet, das alle Umlaute korrekt darstellte, egal mit welchem Zeichensatz sie ursprünglich geschrieben waren. Man muss dazu wissen, dass alte Wordpressversionen mit dem Zeichensatz Iso8859-1 arbeiteten, seit Jahren aber nur noch #UTF-8 benutzt wird. Jetzt stellte ich fest, dass die Einträge in der Datenbank nicht verändert worden waren, nur die Ausgabe hatte das Plugin korrigiert. Was sollte ich nun tun? Die Seite sah fürchterlich aus. Ich schaute mich etwas im Internet um und fand diesen Beitrag, in dem sogar gleich die SQL-Befehle mitgeliefert wurden. Da ich selbst keinerlei Programmier- oder Scriptsprachen beherrsche, seit die Batch-Datei aus der Mode gekommen ist, war ich sehr dankbar und probierte es aus. Und es hat funktioniert.
Mein Ziel war ja, das #Blog so wieder aufzusetzen, dass ich es dann in eine statische #HTML-Seite verwandeln und nur noch als Archiv nutzen konnte. Also lud ich mir ein Plugin für Wordpress herunter, mit dem ich eine statische Seite erzeugte. Die hat den Vorteil, dass sie keinen aktiven Code enthält und von Viren und Schadsoftware nicht angegriffen werden kann. Ich wandelte die Seite testweise um und erhielt 266 404-Fehleraufrufe. 266 Seiten auf meiner Website konnten nicht angesteuert werden. Wie war das möglich?
Ich war selbst schuld. Irgendwann im Jahr 2015, nachdem ich das Blog schon 10 Jahre betrieben hatte, wechselte ich die Seitenstruktur, um mein Ranking bei den Suchmaschinen zu verbessern, was übrigens überhaupt nichts half. Meine Struktur war bis dahin /Jahr/Monat/Tag/Post-ID/. Die Post-ID ist bei Wordpress einfach die laufende Nummer des Beitrages.
So gab es früher einen Beitrag, der in meinem Blog unter dem Pfad /2005/06/07/19/ zu finden war. 2015 änderte ich die Struktur zu /Jahr/Monat/Postname/, und von diesem Zeitpunkt an war der entsprechende Beitrag unter /2005/06/nach-dem-mord-an-theo-van-gogh/ zu finden. Wenn jemand von außen auf den alten Pfad verlinkt hatte, konnte man den Beitrag jetzt nicht mehr finden, die Adresse stimmte nicht mehr. In der Navigation innerhalb meines Blogs war das egal, Wordpress änderte die internen Links, die es selbst erzeugt hatte. Allerdings galt das nicht für Links, die ich selbst in einem anderen Beitrag geschrieben hatte. Wenn ich also später irgendwo in einem Posting auf den Beitrag verlinkt hatte, blieb der falsche Link bestehen. Gott sei Dank gab es sogenannte #Weiterleitungsplugins, die alle Anfragen auf die alten Adressen auf die neuen umleiteten. So etwas benutzte ich. Ich weiß heute nicht mehr, ob auch die von mir in anderen Beiträgen gesetzten Links von dem Plugin mit berücksichtigt wurden, das ist aber auch egal, denn das Plugin ist veraltet und kann von mir nicht mehr genutzt werden. Bei der schnellen Löschaktion vor einem Monat habe ich es ebenfalls gelöscht. Die Plugins von heute können zwar nach bestimmten Schemata weiterleiten, doch nicht allgemein von Post-ID auf Postname. Keines dieser Plugins schafft es, in der Datenbank die Post-ID abzurufen und dann alle notwendigen Weiterleitungen einzurichten. Den Samstag Abend und den Sonntag morgen über habe ich einige dieser Plugins getestet.
Schließlich entschied ich mich für ein extrem einfaches, das sogar ich verstand. Es heißt Simple 301 redirects und war einfach zu bedienen. Ich musste nur für jede Weiterleitung in ein Feld den alten Pfad eintragen, und in ein zweites Feld den neuen Pfad. Doch wie sollte ich wissen, welche Post-ID zu welchem Postname gehörte? Mir half die Datenbank weiter. Mein Vorgehen zwischen Sonntagmittag und Dienstagmittag habe ich einem Freund gegenüber in einer Mail so beschrieben:
“Wenn ich jetzt auf einen Link in der alten Struktur stoße, muss ich in meiner Offline-Kopie der Datenbank nach der Post-ID suchen, dann kommt der Text, von dem ich eine Portion Online in die Suchmaschine der Seite eingebe, die findet dann den Link mit der heutigen Struktur, und ich schreibe in ein Umleitungsplugin eine Tabelle mit altem und neuem Link. Das sieht dann beispielsweise so aus:
request,destination
/2005/09/18/96/,/2005/09/warum-die-f-d-p/”
Für die 266 Weiterleitungen habe ich fast 2 Tage gebraucht, eben weil ich erst mühsam und über die Suchmaschine den neuen Pfad herausfinden musste. Und als ich fertig war, begriff ich, dass mir das überhaupt #nicht nützt, wenn ich die Seiten in HTML umgewandelt habe. Die Weiterleitungen funktionieren nur in Wordpress selbst.
Zur Lösung dieses Problems habe ich drei Möglichkeiten: Entweder ich kopiere auf der HTML-Seite in jeden Pfad, wo eine Seite nicht gefunden wird, von Hand die HTML-Datei mit dem richtigen Beitrag hinein. Ich müsste die Arbeit der letzten Tage also noch einmal wiederholen. Oder ich schreibe meine Tabelle noch mal um, damit ich sie in die .ht-access-Datei schreiben kann. Das ist eine Konfigurationsdatei für den Webserver, der es ermöglicht, dass die Weiterleitungen dann auch für die HTML-Seiten gelten. Auch das ist ein Haufen Arbeit. – Oder ich bleibe einfach bei Wordpress und nutze mein altes Blog weiter. Eigentlich hatte ich das wegen der Anfälligkeit für böse Angriffe nicht vor, aber es gibt noch einen weiteren Grund für eine Rückkehr zu WP. Das Write.as-Blog hat keine Suchfunktion und nur wenig Navigation. Es ist schön klein und leicht zu bedienen, aber wenn ich mal 30 Artikel geschrieben habe, oder 100, oder 200, dann ist es nicht mehr so leicht, den zu finden, den man lesen will. Das ist mit Wordpress deutlich einfacher. Mein Freund Eckart hat inzwischen auch die Bilder und Audios, wieder eingebunden, die zu meinem Blog gehörten, im Grunde kann ich es jetzt wieder benutzen. – Ich weiß ehrlich nicht, was ich machen soll. Nur die Adresse des Blogs würde sich ändern, weil jetzt alle internen Links auf die Adresse zeigen, wo eigentlich die HTML-Seite hin sollte. Ich bin echt unschlüssig.
Gott sei Dank ist mir die Rettung dieser vielen Texte gelungen. Ich schreibe bald, was ich damit anfange.