Von Wordpress zu Classicpress zu Bludit

Bisher nutzte diese Website den Wordpress-Fork Classicpress – ein performantes datenbankbasiertes CMS, das viele Features und noch mehr Plugins bietet, die ich nie benötigen werde. Zudem hat sich Classicpress vom »business-focused CMS« (also ein langfristig verlässlich nutzbares CMS) zu »The CMS for Creators« umpositioniert, wo ich mich mit meiner kleinen privaten Seite nun überhaupt nicht mehr sehe.

Die Website sollte außerdem noch performanter und noch schlanker werden sowie auf all die Gimmicks verzichten, die man vor knapp 20 Jahren unbedingt haben musste (Kommentare, Trackback, Pingback, XMLRPC, Webmention ...). Ein weiterer Punkt war, dass meine Seite ein beliebtes Ziel für Hacker und Spammer war, da Wordpress-Systeme anscheinend beliebt bei dieser Klientel sind. Auch sollten keine Cookies mehr gesetzt werden, um das unsägliche Cookie-Banner endlich loszuwerden. Das hieß also, auf ein Desktop-CMS, auf ein Jamstack-System (Javascript, API, Markup) oder auf ein Flatfile-CMS zu setzen.

Destkop-CMS

Vorteil: Generiert statische HTML-Seiten und ist daher unschlagbar schnell. Auch werden keine Cookies gesetzt.

Nachteil: Im Laufe der letzten Jahre habe ich viele ausprobiert (darunter Qixite – damit wurde das »Marketing Wordbook of Horrors« erstellt –, Publii und sogar Frontier), konnte mich aber nie richtig mit einem davon anfreunden.

Jamstack

Vorteil: Generiert ebenfalls statische HTML-Seiten.

Nachteil: Für meine kleine private Seite wäre der Aufwand für die Einarbeitung in keinem Verhältnis zum Nutzen gestanden.

Flatfile-CMS

Daher blieb nur ein Flatfile-CMS. Die Seiten laden zwar nicht ganz so schnell wie statische Seiten, aber doch schneller als mit Features überladene Datenbank-CMSe. Auch hier hatte ich früher einige getestet. In die engere Auswahl kamen Flatpress und Bludit.

Schlussendlich wurde es Bludit, da hier schlicht und einfach die Übernahme der bestehenden Artikel am einfachsten über ein Plugin zu realisieren war. Und es bietet die Möglichkeit, Texte zeitversetzt zu veröffentlichen, was ich auch gern nutze. Zudem gibt es kein Kommentarsystem und das CMS setzt standardmäßig keine Cookies (außer, man ist eingeloggt), Plugins muss man allerdings wegen der Cookies einer Prüfung unterziehen.

Erster CMS-Wechsel: Von Wordpress zu Classicpress/17.03.2019

Umstieg auf ClassicPress

Das CMS Wordpress kenne ich jetzt seit Verison 0.72, also seit knapp 16 Jahren. Es war damals das (aus meiner Sicht) einzige CMS, das auch ein PHP-Laie wie ich ohne allzugroßen Lernaufwand anpassen konnte. Trotz zunehmend komplexerer Templates und unzähligen Plugins war Einfachheit immer ein herausragendes Merkmal des CMS.

Und dann kam Gutenberg. Ein neuer Editor ist bestimmt kein Fehler, dem »klassischen« Editor Tiny MCE sieht man sein Alter schlicht und einfach an. Da mangelnde »User Experience« heute schon als Killerkritierium gilt, ist der Wunsch nach einem neuen Editor nachvollziehbar. Leider konnte ich mich mit Gutenberg nicht anfreunden. Es gab ein paar nette Features (Farbpalette, moderne Anmutung, bessere Seitengestaltung), in Summe ist der Editor jedoch nicht ausgereift (z.B. sporadisches Hinzudichten eines 2. Leerzeichens beim Einfüngen kopierten Textes, Hänger) und ist nach meinem Ermessen in der Bedienung viel umständlicher (z.B. fehlende Zeichentabelle oder weniger Möglichkeiten beim Setzen interner Links).

Also entweder das Plugin »Classic Editor« nutzen, bis es nicht mehr unterstützt wird, oder auf den Fork Classicpress (CP) umsteigen, deren Gründern bei WP auch so einiges gegen den Strich ging. Alle Plugins, die bis WP 4.9.x laufen, laufen auch unter CP 1.x. Die Programmierer versprechen ein weniger aufgeblähtes und damit performanteres System. Sympathisch ist, dass die Weiterentwicklung demokratisch sein soll. Die Gründer positionieren CP als »business-focused CMS«, was hoffen lässt, dass neue Komponenten erst nach Erreichen eines gewissen Reifegrades implementiert werden.