Überzeugt davon, dass WordPress total unsicher und kein wirklich gutes CMS ist, habe ich Anfang des Jahres hingeschmissen und verschiedene Blogsysteme ausprobiert. Am längsten habe ich mit Grav und Bludit beschäftigt. Auch Pelikan, Jekyll, Contao und Kirby habe ich probiert. Hier zeige ich euch, warum ich letztlich doch wieder zu WordPress zurückgewechselt bin.
Vorweg: ich habe relativ hohe Ansprüche an den Funktionsumfang einer Blogsoftware. Da ich bereits beruflich programmiere, will ich nicht auch noch zu Hause für mein Blog programmieren müssen. Daher will ich bestimmte Funktionen wie das Positionieren von Bildern im Browser erledigen können.
Flat-File-CMS-Systeme
Die Flat File Systeme haben grundsätzlich einen limitierten Funktionsumfang, arbeiten dafür aber ohne Datenbank und dadurch ist das Backup sehr einfach. Sie beherrschen meistens (Ausnahme Kirby) keine Content-Blöcke, sondern die gesamte Seite ist eine einzige Markdown-Datei. Das ist für Text ganz prima. Kommen allerdings Bilder ins Spiel, stößt das System schnell an die Grenzen, denn mit Markdown kann man nicht festlegen, ob ein Bild rechtsbündig oder zentriert dargestellt wird. Auch ein Umlauf ist nicht vorgesehen. Dafür ist Markdown auch überhaupt nicht ausgelegt.
Die Flat-File-CMS Systeme nutzen da haarsträubende Konzepte wie das Anhängen von CSS-Klassen an Bild-URLs: picture.jpg?resize=400,600&classes=right oder modulare Seiten aus zwei Markdown-Dateien. Doch diese Dinge gehen eben nicht in der GUI, sondern man muss dazu die Doku lesen, verstehen und dann entsprechend Dateien anlegen. Das ist mir zu viel Arbeit.
Bei Grav habe ich sehr viele Themes ausprobiert, aber keines gefunden, das wirklich gut aussieht. Oft waren z.B. die Tags komplett unlesbar (hellblau auf noch hellerem blau). oder die Tag Cloud wollte einfach nicht funktionieren. Das ist halt so, wenn die Themes ungeprüft von der Community kommen.
Kirby baut als einziges nicht auf Markdown und beherrscht auch Blöcke, d.h. man kann Text und Bild nebeneinander anordnen. Die Software macht einen ausgereiften Eindruck, kostet aber 99 €, was mir für ein privates Blog dann doch zu viel ist, zumal ich auch hier viel in den Dokus hätte lesen müssen. Für eine gewerbliche Webseite ist Kirby aber sicherlich eine gute Wahl.
HTML-Generatoren
Grav, Kirby und Bludit hatten wenigstens eine Web-GUI. Es geht aber noch einfacher und rudimentärer: HTML-Generatoren wie Pelikan (Python) oder Jekyll (Ruby) generieren aus Markdown HTML-Seiten. Dafür ruft man einfach einen Terminalbefehl auf. Das Problem ist hier aber das gleiche. Markdown ist für Text ausreichend, Bilder oder gar Galerien kann man damit nicht ohne Gefrickel umsetzen. Und das Gefrickel artet hier noch mehr aus, weil es eben gar keine GUI gibt. Ich habe mich auch dagegen entschieden, weil diese Systeme aus der Linux-Welt stammen und ich auf dem Desktop Windows nutze. Der eingebaute Webbrowser zur Seitenvorschau lässt sich mit WSL leider nicht nutzen. Damit könnte man unter Linux eigentlich recht angenehm bloggen: Links ein Texteditor, rechts eine Browser-Vorschau.
Ausgewachsene CMS-Systeme
Nachdem ich merkte, dass der Funktionsumfang bei den einfachen Flat-File-Systemen einfach nicht ausreichte, schwenkte ich wieder um zu ausgewachsenen CMS-Systemen, die eine Datenbank brauchen. Also probiere ich Contao. Das System macht einen sehr umfangreichen und gut konfigurierbaren Eindruck. Contao ist jedoch ausgelegt auf große Unternehmenswebseiten, die mehrsprachig, mit Dutzenden Benutzern und mehreren Domains arbeiten. Völliger Overhead für ein Blog.
Das an sich wäre ja kein Problem, aber Contao bringt keinerlei fertige, schöne Themes mit. Das muss man dann alles erst bauen. Dafür will ich nicht meine Freizeit opfern. Fertige Themes kosten nicht wenig, 50-200 € muss man dafür hinblättern. Contao ist perfekt für Agenturen, die pixelgenaue Layouts umsetzen müssen. Denn eine frische Installation von Contao gibt Webseiten komplett ohne CSS und mit sehr wenig Markup aus. Gleichzeitig ist das CMS aber extrem mächtig und kann auch sehr komplexe Anwendungsfälle komplett mit der GUI abdecken.
Nun doch wieder WordPress
Die meisten CMS-Systeme sind also für einen Freizeit-Blogger entweder zu komplex oder zu simpel gestrickt. Im Vergleich zu WordPress haben diese Systeme vergleichsweise geringe Nutzerzahlen, sodass Lücken wahrscheinlich sehr lange ungepatcht bleiben.
Zum Schluss war ich dann so genervt, dass ich doch wieder komplett auf WordPress setze. Denn das System ist ausgereift, wird millionenfach eingesetzt und hat alle wichtigen Funktionen an Bord. Übrigens braucht man inzwischen weitaus weniger Plugins als vor 10 Jahren, da viele Funktionen in WordPress integriert worden sind. Plugins sind nämlich ein großes Sicherheitsrisiko, insbesondere, wenn irgendwann die Weiterentwicklung gestoppt wird.
WordPress hat auch ein sehr ausgereiftes Filehandling, man kann Bilder im Browser bearbeiten, was für mich als Reiseblogger einfach praktisch ist.
Die Sicherheit hoffe ich im Griff zu behalten, indem ich so wenig Plugins wie irgendmöglich einsetze und darauf achte, dass diese auch gepflegt werden. Außerdem härte ich meine Installation und nutze WebAuthn als Authentifizierung, sodass niemand Passwörter durchprobieren kann.
Zwar ist WordPress das am meisten angegriffene CMS, aber durch die Verbreitung werden Lücken auch schnell geschlossen. Bei Systemen wie Bludig oder Grav habe ich dagegen sehr große Zweifel, ob da wirklich jemand Sicherheitsaudits durchführt. Gerade bei Bludits habe ich in den Plugins bereits hanebüchene Sicherheitslücken (Cross Site Scripting) gesehen. Deswegen gehe ioch davon aus, dass man mit etwas Vorsicht und regelmäßigen Updates auch ein WordPress sicher betreiben kann.