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.
Bitte warte einen Augenblick.