15 Jahre Serendipity als Entwickler - ein Rückblick und ein Ausblick

Es ist jetzt ziemlich genau 15 Jahre her, dass ich das erste mal als Entwickler an der Blogsoftware Serendipity gewerkelt habe. Zumindest sagt so mein Archiv. Und mir ist in dieser Winterzeit melancholisch, sodass ich zurückblicken will, gleichzeitig suche ich einen Ort um Zukunftspläne für Serendipity aufzuschreiben. Mach ich beides doch hier.

Rückblick

Ich hatte nie vor, an Serendipity zu arbeiten. Es war kein geplantes Projekt. Es war vielmehr so, dass ich meinen Blog von einer Blogplattform (twoday.net) umzog, Dirk mir Zuflucht aus seinem Server anbot und dabei Serendipity als Blogsoftware vorschlug. Als ich die Software einmal am Laufen hatte, wollte ich auch meinen Blog anpassen. Das tat ich. Und als ich dann merkte, dass auch im Projekt selbst Platz dafür wäre, rutschte ich da langsam rein.

Beginn mit Plugins, Dokumentation und kleinen Anpassungen

Es war ein Plugin zur Livevorschau der Kommentare, das ich damals zuerst in den Blog stellte. Erinnere ich mich richtig war das meine erste Begegnung mit PHP und jQuery. 2008 dürfte ich im Informatikstudium gewesen sein, bekam dadurch also etwas Programmierübung, brauchte aber dringend mehr. Serendipity bot sich dafür damals sicher an.

Generell hatte mich der Kommentarbereich ziemlich gepackt. Den wollt ich in meinem Blog so gut wie möglich haben. Daher wohl auch das Plugin. Ich ergänzte das dann durch Änderungen am Design des Bereichs selbst. Noch heute sind mir Kommentare wichtig – und für mich ist es auch amüsant, das solche Nutzbarkeitsüberlegungen später mal mein Beruf wurden. Bei manchen Dingen war ich die letzten Jahre ziemlich konstant.

Es folgt ein Plugin für Markupbuttons im Kommentarformular, das existiert vom Konzept heute noch so und ist immer noch praktisch. nl2p danach war eine Fortführung meiner Auseinandersetzung mit dem Webteam von UbuntuUsers, das sich geweigert hatte Nutzer neue Zeilen ohne nötige Leerzeile setzen zu lassen – mir war es wichtig zu beweisen, dass die technische Argumentation dagegen vorgeschoben war. Der Code dafür lebt heute im nl2br-Plugin, von Stephan gründlich überarbeitet. Autotitel danach war eine gute Idee, es setzte den Titel der verlinkten Seite als Titel des Links. Es krankte aber an den Limitierungen der PHP-Plattform; das müsste im Hintergrund geschehen, was aber nicht ging (nicht geht sogar!), daher setze ich es heute nicht mehr ein.

Das wichtigste Plugin war aber sicher das Bayes-Plugin, eine Kooperation mit dem Forumnutzer kleinerChemiker. Wir nahmen einen Bayes-Filter und ließen den zur Spamerkennung über Blogkommentare laufen und stellten fest: Das funktioniert super. Gleiches gilt heute noch, auch wenn der Code deutlich überarbeitet wurde und die neueste Version des verschlankten Plugins den Bayes-Filter als Library nutzt. Das Bayes-Plugin läuft heute noch hier und in einigen anderen Serendipity-Blogs.

Als ein guter Schlusspunkt für diese Zeit taugt die Anleitung zum Pluginschreiben, traute ich mir also inzwischen zu sowas zu verfassen. Und dann wurde es etwas ruhiger. Es gab noch den Template-Editor, woraus man heute wahrscheinlich was nutzbareres formen könnte. Aber im Grunde war ich mit den Pluginideen durch und genug damit beschäftigt, die meinen am Leben zu halten.

Wenn ich mir die Artikel von damals ansehe kommen neben den Plugins nun langsam andere Überlegungen dazu. Zum Beispiel die, dass man die Suche verbessern könnte. Auch, dass Archiv-URLs stabil sein sollten, was inzwischen wirklich fest im Kern ist und absolut richtig war. Oder ich erwähnte früh, dass dem Adminbereich eine Überarbeitung gut tun würde. Und genau das sollte später folgen.

Die 2.0-Überarbeitung

Mit Serendipity 2.0 war ich dann wirklich als Serendipity-Entwickler aktiv. Vorher hatte ich ein paar kleinere Patches eingebracht und wie oben gezeigt an meinen eigenen Plugins gearbeitet. Aber 2.0 war eine andere Dimension.

Wir – 2.0 war eine große Teamarbeit – hatten damals erkannt, dass Serendipity ein Problem hatte: Der Adminbereich war damals eine ziemlich wüste Implementierung. Er bestand komplett aus PHP-Dateien, die den Großteil der Logik sowie das gesamte HTML beinhalteten. Meine vorherigen Ideen zur Verbesserung des Bereichs waren so überhaupt nicht umsetzbar, das HTML war nicht editierbar. Und das war ein Tabellenlayout, natürlich, wohl geschrieben von vor-CSS geprägten Entwicklern. Was nicht abfällig klingen soll, so hatte ich es ja auch zuerst gelernt.

Das Großprojekt in 2.0 war also die Smartifizierung des Blog-Backends. Smarty, weil das die Template-Sprache war, die auch in den existierenden Blog-Themes genutzt worden war. Wir machten das so: Wir rissen das HTML aus den PHP-Dateien, packten sie in Smarty-Templates, und wo immer vorher in den PHP-Dateien Logik die HTML-Ausgabe steuerte wurde stattdessen eine Variable gesetzt, die dann an die Smarty-Templates übergeben wurde. Wir, das waren meiner Erinnerung nach in dem Fall ophian und ich. Gleichzeitig war YellowLed dran, das so entstehende HTML zu verbessern und mit einem CSS-Design zu versehen. Wobei ich auf Backendseite half. Dafür trafen er und ich uns sogar in Mumble und besprachen die Änderungen. Das Ergebnis ist der heute noch genutzte Adminbereich.

Den stellte YellowLed sogar in einem Video vor:

Serendipity 2.0 war mir so wichtig, dass ich andere Probleme von Serendipity mit angehen wollte. So hieß es eine Weile, ein Problem für die Adaption von Serendipity sei ein fehlendes Theme für Bilderblogs. Also baute ich eines. Und weil ich schon dabei war gleich noch ein zweites, gedacht als Alternative für textlastige Blogs. Es freute den inneren Kern ersichtlich, aber hatte ansonsten nicht den gewünschten Effekt.

Wie auch Serendipity 2.0, wenn man ehrlich ist. Die große Anstrengung bewahrte vielleicht die Nützlichkeit der Software für moderne Browser (und Telefone!). Aber sie bewirkte nicht den großen Popularitätssprung, den zumindest ich mir für Serendipity erhofft hatte. Vielleicht war es zu wenig zu spät (wir brauchten viel länger als gedacht), vielleicht waren die Alternativen zu gut, vielleicht hatten wir Pech oder es war einfach nie in den Karten. Aber ich glaube wirklich, man kann den negativen Effekt davon am nächsten Abschnitt sehen.

PHP 7, 8 und das Team

Nach 2.0 wurde es bei mir im Blog etwas ruhiger um Serendipity.

Im Idealfall hätten wir 2.0 neue große Releases nachgeliefert. Aber das schafften wir nicht, die Luft war raus. Nachfolgende Releases hatten durchaus noch Neuerungen: Responsive Bilder und die Bildergalerien per Mediendatenbank, echtes UTF-8 für MySQL-Datenbanken, ein neuer Cache, Komfortverbesserungen wie das Aktualisieren aller Plugins auf einmal. Das fällt zumindest mir direkt ein. Aber das ist wenig im Vergleich zu einem neuen Backend, von der Sichtbarkeit und vom Aufwand her. Während also neue Entwickler die Lücke hätten füllen müssen, blieben die bis auf ein paar Ausnahmen aus – oder rannten gegen die gewünschte Back­wards-Kom­pa­ti­bi­li­tät und gaben auf, das beobachtete ich gleich dreimal.

Auch neue Plugins von mir wurden seltener. Das VGWort-Plugin als nächstes größeres Plugin z.B. brauchte ein paar Jahre. Es ist kein Zufall, dass ich mich später zu einer Serendipity-Entwicklerwoche erst aufraffen musste (gute Idee übrigens, da kamen nette Sachen bei raus).

Es kamen mehrere Dinge zusammen. Tatsächlich war es nicht (nur) die Enttäuschung über dem fehlenden Nachhall von 2.0. So wechselte ich mein Studium bzw meinen Job und hatte mit jedem Wechsel weniger Zeit – Zeit, die sich Serendipity mit meinen anderen und inzwischen mir auch sehr wichtigen Projekten teilen musste, insbesondere PC-Kombo und Pipes. Und das zwischenzeitliche Auswandern nach Frankreich war auch ein Lebensumbruch, wo s9y erst später wieder reinpasste.

Aber so ähnlich ging es scheinbar auch den anderen, die an 2.0 beteiligt gewesen waren. Jeder wird seine Gründe gehabt haben. Aber Fakt ist: Nach 2.0 war der Code teils verbessert, das Projekt aber nicht gesünder, sondern es fehlten Entwickler. Und ich war im Konflikt: Sinnvoller, das Projekt sich heilen zu lassen und sich rauszuhalten? Oder im Gegenteil Arbeit reinzustecken, um Entwicklungen zu beschleunigen?

Gleichzeitig wurde wiederholte Anstrengung nötig, ob wir wollten oder nicht, was dann für mich entschied. Und zwar aufgrund der PHP-Updates. Sowohl bei PHP 7 (da war z.B. Serendipity 2.3 für die Versionen nach 7.1), als auch bei PHP 8, jede Punktversion dieser Versionen brach alten PHP-Code auf neue Art und Weise. Und Serendipity ist vollständig alter PHP-Code. Zwei Glücksfälle kamen bei PHP 8.0 zusammen und ermöglichten Serendipity 2.4: Ich hatte durch einen Jobwechsel wieder mehr Zeit und neue (bzw neue alte) Entwickler tauchten wie für PHP 7 eben doch auf, wie surrim, sodass das Projekt die Codemigration stemmen konnte. Trotzdem war PHP 8.0 für Serendipity ein Monster, das sich zum Glück seitdem nicht wiederholt hat.

Es gab also die großen Entwicklungsbemühungen durchaus noch. Auch von mir. Aber anstatt in schön sichtbares und präsentierbares zu fließen ging viel der Energie für die schnöde Kompatibilität mit neuen PHP-Versionen drauf. Dafür kann das Projekt nichts, aber es schadete ihm. Oder vll stimmt das nichtmal, vll ist Serendipity einfach erwachsen genug, dass weitere Änderungen abseits von Wartungsarbeit kaum nötig waren?

Ein möglicher Ausblick

Und damit kommen wir zum Ausblick. Serendipity ist eine ziemlich großartige Blogsoftware und ein Projekt, das sich jetzt viele Jahre gehalten hat, sich also viele weitere Jahre halten wird. Aber es ist auch ein Projekt geworden, das sich langsamer entwickelt und bei Releases hinterherhinkt. Für etablierte Software ist das in Teilen gut, es ist sogar Projektphilosophie, so stabil wie möglich zu sein. Aber klar, die Gefahr ist, dass irgendwann zu wenig Bewegung im Projekt ist, um neue Entwicklungen mitzugehen und die Software deswegen irgendwann sogar stirbt. Und nebenbei: Wenn ich mir die untere Liste anschaue beantworte ich meine Frage von oben mit nein, s9y hätte durchaus mehr aktive Entwicklungsarbeit gut vertragen können, das Innehalten war nicht nur Zeichen der fertigen Entwicklung.

Es ist jetzt leider ganz konkret davon auszugehen, dass ich in Zukunft wieder weniger oder sogar eine Weile gar keine Zeit haben werde – ich rechnete stattdessen mit mehr Zeit, aber es kam etwas dazwischen. Andere werden das abfangen. Aber was wird das Projekt überhaupt in Zukunft machen? Was würde ich angehen, wenn ich mehr statt weniger Zeit hätte, wenn gar jemand Entwicklungsarbeit an Serendipity sponsern würde? Das sind meine Überlegungen dazu:

Kompatibilität mit neuen PHP-Versionen

Weil das PHP-Projekt auf Rückwärtskompatibilität scheißt wird es ein gewichtiger Teil der zukünftigen Arbeit werden, Serendipity einfach am Laufen zu halten. PHP 8.3, gerade veröffentlicht, hat wieder Breaking Changes, es wird bei 8.4 nicht anders sein. Bestimmt treffen die uns. Und weh dem, der Serendipity an PHP 9.0 anpassen muss.

Dazu ist es ja nicht nur der Kern von Serendipity, der hier Arbeit erfordert. Sondern auch die vielen Plugins, von denen der Großteil keinen aktiven Maintainer hat. Warum auch, sie funktionierten Jahrzehnte vor sich hin. Die Themes genauso, sie können viel Arbeit erfordern, wenn wieder wie bei PHP 8.0 Smarty versagt und die Codeänderungen nicht auf der Ebene der Template-Engine abfedert.

Gleichzeitig ist diese Kompatibilität auch die Arbeit, die auf jeden Fall gemacht werden wird. Zu viele Entwickler nutzen Serendipity für ihre eigenen Blogs. Wenn nicht die derzeitigen Entwickler handelten, würden andere zugunsten ihrer eigenen Blogs die nötigen Codeänderungen schreiben und bestimmt auch teilen. Es ist die auf den ersten Blick besorgniserregendste Herausforderung, aber auf den zweiten die ungefährlichste.

Automatisierte Tests

Die Arbeit an den PHP-Versionen ist auch deswegen schwer, weil das Projekt hier nicht gut aufgestellt ist. Es fehlen automatisierte Tests für Serendipity selbst. Sie fehlen auch besonders für die Spartacus-Plugins. Es bräuchte einmal ein System, das interne Codestellen durch Unit-Tests absichert – das wäre mit Github auch gut umsetzbar und wir haben mit ersten Tests den Ansatz dafür. Aber es braucht vor allem zweitens ein Testsystem, das alle Plugins installiert und prüft, dass zumindest die Kernfunktionen des Blogs weiterhin funktionieren. Und das jeweils mit allen PHP-Versionen, den neuen wie den alten.

Das wäre einmalige Arbeit, vll eine Heidenarbeit sogar, die letzten Endes aber Arbeit sparen würde.

Webmentions

Von mir initial geschmäht, gab es in den letzten Jahren eine Bewegung namens IndieWeb. Grundsätzlich kompatibel mit der Idee von Blogs, scheinen die Akteure nicht in der alten Blogosphäre verhaftet gewesen zu sein. Ergo bauten sie Webmentions und erfanden Trackbacks neu, gerade so abgewandelt, dass sie inkompatibel sind.

Trotz meiner negativen Bewertung denke ich mittlerweile, dass Serendipity den Standard trotzdem unterstützen sollte. Neben Trackbacks und Pingbacks ist die Aufnahme von Webmentions kein technisches Problem. Es wäre fürs Projekt wichtig, solche neuen Impulse aufzunehmen und ggf. so neue Entwickler anzusprechen. Ich denke dabei ganz konkret beispielsweise an Beko Pharm – sein ist ein Blog, wie er früher mit Serendipity gebaut worden wäre, wofür sich Serendipity aber wahrscheinlich mehr in sein Dienstenetzwerk eingliedern müsste.

ActivityPub

Gleiche Denkrichtung: ActivityPub. Wir reden schon ewig davon, dass Kommentare zu Blogartikel in sozialen Netzwerken auch im Blog gespiegelt werden sollten. Denn der Blog sei das Zentrum der Netzpräsenz, die Heimat. Genau das wäre mit ActivityPub möglich, wenn auch nicht mit Facebook, so doch mit Mastodon und anderen föderalisierten Diensten. Genau so wäre es möglich, Blogs ohne den Umweg RSS direkt in Mastodon etc zu abonnieren, wenn Serendipity ein paar Daten aussenden und empfangen würde.

Es gibt dafür mit ActivityPhp sogar ein passend erscheinendes PHP-Projekt, mit dem das als Plugin oder Teil des Kerns relativ vernünftig umsetzbar erscheint.

Theme-Archäologie

Gleichzeitig sollte Serendipity seine Identität bewahren. Ich meine, seine Geschichte vielleicht sogar herausstellen. Ich zumindest beobachte an mir echte Freude, wenn ich einen klassischen Blog mit klassischem Design sehe. Und genau davon hat Serendipity eine Riesenauswahl im Spartacus-Repository.

Diese Themes sind aber wirklich alt. Gerade mit Serendipity 2.0 (bzw 2.1?) gingen sie teils richtig kaputt: Wir hatten damals auch das Standard-Frontend auf 2k11 umgestellt und damit weg vom tabellenbasierten vorherigen default-Theme. Damit können viele der alten Themes aber immer noch nicht umgehen. Teils habe ich sie für PHP 8.0 etwas repariert, aber da sind immer noch Darstellungsfehler. Plus: Auch das HTML ist teilweise arg veraltet.

Es wäre toll, das alles wirklich zu reparieren. Die alten Themes technisch so zu modernisieren, dass sie erstens ein responsives CSS-Layout ausgeben, zweitens richtig mit dem von Serendipity ausgegebenem neuem HTML und CSS (wie im Kommentarformular) zusammenarbeiten. Damit wäre ein derzeit kaputter Teil von Serendipity für Nutzer wieder ohne den derzeit entstehenden negativen Eindruck nutzbar und Serendipity würde gleichzeitig seine Geschichte betonen.

Spartacus modernisieren

Und schließlich würde ich Spartacus modernisieren.

Bei Spartacus stören mich drei Dinge:

1. Um zu erkennen, ob ein Plugin eine neue Version verfügbar hat, muss die aktuelle Version ausgelesen und dafür die PHP-Datei (des Plugins auf dem eigenen Server) interpretiert werden. Stattdessen sollte die Versionierung über eine .INI oder .toml-Datei laufen, also per Metadatendatei. Das würde auch bei Inkompatibilitäten mit neuen PHP-Versionen helfen.
2. Gleichzeitig muss für Spartacus auf einem Server jeden Tag XML-Dateien generiert werden. Die gehen dann an die Blogs, so wissen sie welche Versionen es auf Spartacus gibt. Eine Lösung ohne diesen Generierungsschritt wäre ausfallsicherer. Vielleicht könnten wir im Git-Repository durch einen Git-Task diese Liste der aktuellen Pluginversionen automatisch erstellen, wann immer sich eine der Metdatendateien ändert?
3. Spartacus aktualisiert derzeit Themes nicht, nur Plugins. Themes werden einmalig heruntergeladen, aber Updates werden nicht erkannt. Gerade im Hinblick auf das obere Theme-Projekt wäre das aber nötig, plus auch um Updates für zukünftige Smarty-Versionen ausliefern zu können.

Spartacus ist ein Kernbestandteil der Nutzung von Serendipity, Änderungen daran wollen wohlüberlegt sein. Und die alte Infrastruktur ist für sich gesehen ziemlich beeindruckend. Trotzdem fände ich es wirklich gut, wenn Serendipity sich hier verbessern könnte.

Nutzeranforderungen und Nutzertests

Als letzter Zusatz: Serendipity war jetzt so lange Entwickler- und Feed­back-ge­steu­ert, dass man auch hier nochmal ansetzen könnte. Was machen Nutzer mit Serendipity, was sind die Stolpersteine, Anwendungsfälle.

Da könnte viel bei rauskommen, was dann weitere Entwicklungen steuern könnte. Und ich habe inzwischen wirklich die Erfahrung, solch eine Erhebung und Auswertung ordentlich durchzuführen. Aber für die dann angesagten Entwicklungen müsste das Projekt danach eben auch die Kapazitäten haben, sonst wäre der Aufwand verschwendet.

Soweit meine Überlegungen. Ich hoffe, die Retrospektive ist für den einen oder anderen Serendipity-Blogger interessant. Ob sie sich mit euren Eindrücken deckt? Es ist ja alles nur meine Perspektive, gefiltert durch ein paar verstrichene Jahre und durch das, was ich eben nicht in den Blog getan und seitdem vergessen habe. Und viel wird bewusst unterschlagen, der Artikel war eh schon zu lang.

Zu den Zukunftsplänen, ich habe natürlich keine Ahnung, ob irgendwas davon Realität werden wird. Vielleicht entwickelt sich ja sogar das PHP-Projekt in Zukunft verantwortungsbewusster und selbst die Gewissheit der Anforderungen von dort fällt flach. Ansonsten sind die Ideen vielleicht für den einen oder anderen Entwickler ansprechend und werden dadurch Wirklichkeit, selbst wenn ich nicht dazu komme. Oder meine verfügbare Zeit entwickelt sich ganz anders, als ich derzeit glaube… Vielleicht aber haben andere auch ganz andere Pläne, auch das könnte völlig okay sein.