Netz - Rettung - Recht

• Zunächst war quasi eine Reklamation zu beheben. In Serendipity 2.3.3 war eine Änderung enthalten, die verhindert, dass beliebig viele “leere”, weil noch gar nicht existente Seiten im Archiv älterer Beiträge aufgerufen werden können. Das führte aber dazu, dass das Seitenleisten-Plugin serendipity_plugin_history auf jeder Seite außer der Blog-Startseite mit einer Fehlermeldung abbrach und daher die gesamte Seitenleiste nicht angezeigt wurde. Hintergrund war m.E. ein älterer Denkfehler im Code, der nicht unterscheidet, ob wir Einträge zur Erzeugung einer Übersichtsseite (auf der Titelseite, im Archiv, bei Suchergebnissen, …) abrufen, so dass die Einträge auf mehrere Seiten verteilt werden müssen, oder ob der Abruf zu anderen Zwecken erfolgt - bspw. in dem genannten Plugin, um nach Einträgen zu suchen, die vor (bspw.) einem Jahr veröffentlicht wurden. Bei solchen Aufrufen ist es völlig sinnlos, sie zu “paginieren” zu versuchen. In serendipity_plugin_history habe ich das Problem dann behoben.

• Im Backend war mir schon ab und an aufgefallen, dass Einträge mit Sonderzeichen im Titel in den Übersichten seltsam angezeigt wurden, nämlich mit sichtbaren HTML-Entities; ich habe mir dabei aber nie etwas gedacht, warum auch immer. Glücklicherweise galt das nicht für alle, so dass ein Mitentwickler das Problem behoben hat.

• Im Bugtracker lag bereits seit längerem eine Fehlermeldung aus der Mediendatenbank ein: wenn man Bilder oder andere Medien mit einer Dateiendung von mehr als fünf Zeichen Länge hochlädt, gab es eine Datenbank-Fehlermeldung - was daran lag, dass das Datenbankfeld für die Dateiendung (richtigerweise) nicht mehr als fünf Zeichen aufnehmen kann. Das passierte allerdings zum einen nur mit PostgreSQL als Backend (mySQL verwirft einfach den Rest der Endung, schneidet sie also nach fünf Zeichen ab), und zum anderen nur mit sehr komischen Dateinamen. Wer nennt seine Mediendateien denn auch bild.jpg123 oder so ähnlich? Das würde ohnehin später schiefgehen, weil Browser sich beim Ausliefern von Medien regelmäßig auf die Endung verlassen und daher ein .jpg123 ohnehin nicht richtig angezeigt wurde. Sei das, wie es sei - ein Datenbankfehler ist trotzdem blöd. Und nachdem ich für die Versionen 2.3.3 und 2.3.4 ohnehin mehrfach im mir bis dahin völlig unvertrauten Code der Mediendatenbank unterwegs war, haben wir das behoben und erzwingen jetzt beim Upload eine Maximallänge von fünf Zeichen bei der Dateiendung. Meinen wenig professionellen Erstversuch für einen passenden regulären Ausdruck (“das Problem andenken, eine regexp probieren und dann so lange rumfummeln, bis ein paar Testnamen zu richtigen Ergebnissen führen”) hat Mitch dankenswerterweise systematisch getestet und aufpoliert.

• Bei der Arbeit an - und dem Testen der - Funktion zur Benachrichtung über verfügbare Plugin-Upgrades für Serendipity 2.4 fiel mir auf, dass verfügbare Upgrades manchmal nicht angeboten werden. Nach einer sehr, sehr langwierigen Debugging-Session glaube ich (!), einen weiteren sehr, sehr alten Denkfehler im Code gefunden zu haben, den ich nunmehr ersteinmal minimalinvasiv zu beheben trachte. Wertvolle Erkenntnis dabei: Man kann ein Neueinlesen der (ansonsten gecacheten) Plugindaten von Spartacus auslösen, indem man die Konfiguration des Spartacus-Plugins aufruft und einfach - ohne Änderungen - noch einmal speichert.

• Wie bereits berichtet habe ich mich mit den <details>- und <summary>-Elementen beschäftigt. Bei den entsprechenden Blogbeiträgen und den damit verbundenen Kommentaren fiel zunächst auf, dass HTML-Elemente in den Kommentaren meines Blogs zwar angezeigt werden, aber im RSS-Feed (der Kommentare) und in der Kommentar-Übersicht in der Seitenleiste (serendipity_plugin_comments) schlicht verschwinden. Letzteres - also das Ausfiltern - ist bei Serendipity aus Sicherheitsgründen der Default; ich habe aber das Plugin serendipity_event_unstrip_tags installiert, dass stattdessen die spitzen Klammern durch HTML-Entities ersetzt und so HTML-Elemente in den Kommentaren anzeigt. Aber eben auch nur dort - weder in der Seitenleiste noch im RSS-Feed. Das verdiente eine Verbessung (die auch eine Änderung in serendipity_plugin_comments erfordert, das zusammen mit dem Serendipity-Kern verteilt wird).

• Außerdem habe ich dafür gesorgt, dass der WYSIWYG-Editor <details> und <summary> nicht mehr verschluckt. An dieser Stelle ist aber noch Arbeit nötig; der Editor frisst offensichtlich auch den Code zum Einfügen von Bildergalerien und macht Probleme beim Einfügen von Code.

• Der dickste Brocken zum Schluss: ein zumindest partiell seit ewigen Zeiten bestehender Bug sorgte dafür, dass erweiterte Eigenschaften von Artikeln - wie Funktionen aus serendipity_event_entryproperties, durch serendipity_event_metadesc erzeugte Eingaben oder das Eintragsbild aus serendipity_event_social - verlorengehen, wenn der Beitrag aus dem Dashboard heraus veröffentlicht wird, aber auch, wenn Plugins den Hook backend_save (oder backend_publish) triggern. Letzteres passierte bspw. immer dann, wenn serendipity_event_trackback installiert war und der Beitrag sein Veröffentlichungsdatum erreicht hatte, selbst dann, wenn es sich nur um einen Entwurf handelte. Den Effekt hatte ich seit Jahren beobachtet, aber nie richtig festmachen können - er fiel mir ausschließlich bei der Description aus serendipity_event_metadesc auf, und da war ich mir oft gar nicht sicher, ob ich nicht vergessen hatte, eine einzugeben. Mit der Zeit stellte sich das aber als Bug heraus, der 2018 das erste Mal berichtet wurde und sehr schwer zu debuggen war, weil das Verhalten nicht reproduzierbar wirkte. Außerdem nutzte wohl kaum jemand sonst serendipity_event_metadesc, und zudem mussten ja die anderen Randbedingungen auch noch zusammenkommen. Ich habe dann über Jahre hinweg Entwürfe entweder bis zur Veröffentlichung direkt außerhalb von Serendipity gespeichert oder vor der Veröffentlichung gegengecheckt, bis ich Mitte 2019 glaubte, den Fehler behoben zu haben. Das war er aber nicht, und er trat dann schließlich auch anderswo (und dann auch mit der neuen Funktion eines eintragsspezifischen Bildes in serendipity_event_social) auf. Witzigerweise hatten wir das eigentliche Problem bereits 2019 erkannt, aber dann wieder aus dem Blick verloren; bis gerade eben erinnerte ich mich noch nicht einmal an die damaligen Hinweise. :-/ Anyway, bei Gelegenheit schreibe ich vielleicht noch einmal die Debugging-Schritte auf, wenn ich Zeit dazu finde. Am wichtigsten: dieses sehr ärgerliche Problem ist behoben, und man kann seine Entwürfe nun (wieder?) ohne Bedenken bis zur Veröffentlichung in Serendipity speichern.

Schauen wir mal, was das nächste Patch-Release bringt (das nicht allzu lange auf sich warten lassen sollte, nachdem ein ärgerlicher Fehler leider diesmal nicht behoben wurde, und wann wir uns über ein Serendipity 2.4 freuen dürfen.

Was andere dazu sagen

• “Nur ein Blog” von Robert Lender:
  Serendipity 2.3.5 veröffentlicht