Rückblick auf das virtuelle Serendipity-Camp (und neues zu utf8mb4)

Traditionell treffen sich die Mitstreiter des Serendipity-Projekts einmal jährlich im Linuxhotel in Essen. Geplant war es dieses Jahr am gerade vergangenen Wochenende. Corona hat uns das natürlich unmöglich gemacht. Stattdessen haben wir uns online getroffen, am Samstag per Jitsi Meet, am Sonntag gab es noch etwas Aktivität im Slack-Chat.

Es ist natürlich nicht das gleiche. Und Gedanken, da strukturiert mehr zu bieten als nur da zu sein und eventuell gemeinsam zu diskutieren und entwickeln waren nach dem Schwenk auf online (bei mir zumindest) ganz schnell weg. Trotzdem ist so etwas super wertvoll: Niemals sonst kann man sich so gut abstimmen, selten nehmen sich so viele Zeit für das Projekt. Und es ist schön, die anderen zu hören, auch neue Stimmen waren dabei :)

Im Ergebnis haben wir meiner Meinung nach superwichtige Sachen umgesetzt. Spartacus war stehengeblieben und unser uberspace musste umgezogen werden (von uberspace 6 auf uberspace 7), beides wurde angegangen. Wir haben die neue Version 2.3.3 veröffentlicht, sie vorher getestet und die Änderungen angeschaut. Da steckt besonders viel Arbeit von Thomas drin. Und wir haben – endlich! – Fortschritte mit MySQLs kaputtem utf8 gemacht.

Vor Jahren ist Serendipity bei Nutzung von MySQL in die utf8-Falle gelaufen. Es betrifft wirklich nur diese Datenbank. MySQL hat einen Zeichensatz namens utf8, der aber kein volles utf8 unterstützt, sondern nur Zeichen mit drei Byte. 4-Byte-Zeichen, z.B. Emoji wie 💩, kann man damit nicht speichern (hier geht es, weil ich SQLite benutze), Serendipity schneidet Texte dann ab. Daraus herauszukommen ist schwer, denn: Wenn man auf utf8mb4 umstellt braucht ein Zeichen 4 Bytes, Indexe können aber nur 1000 Bytes lang sein. Ein Index über eine varchar(255)-Spalte würde dieses Limit schon sprengen! Wir hatten darüber schonmal auf einem Treffen geredet und Garvin hatte eine mögliche Lösung gebaut, Code, der die Indexe anpasst und dann die Datenbank umstellt. Aber diese Lösung lebt nun schon eine Weile in ihrem eigenen Branch und wurde nicht getestet (es zu testen ist schwierig! Vor allem, wenn man wie ich bisher das Problem nicht richtig verstanden hatte).

Jetzt haben wir nochmal darüber geredet und sind über einen Umweg über eine alternative Lösung gestolpert, deren Ansatz hier zu finden ist. Wenn die MySQL/MariaSQL-Datenbank neu genug ist, kann man die Storage Engine auf InnoDB setzen, wodurch Indexe 3000 Byte lang sein dürfen. Genug auch mit utf8mb4 für unser Datenbankschema!

Mittlerweile stellte sich raus, es ist nicht ganz so einfach, es müssen auch ein paar Einstellungen stimmen. Die können wir nicht im Code setzen, aber wir können sie prüfen. Dann wird das wohl sicher funktionieren, wenn es denn geht. Hoffentlich also eine praktische Lösung, die ohne die Versuche beim Treffen (wie mein Scheitern an der Idee, Dirks Blog umzustellen, weil da noch nicht durchgängig utf8 benutzt wird -> sowas muss also beachtet werden) nicht zustandegekommen wäre.

Das Ziel des verlinkten Codes ist es, Neuinstallationen mit utf8mb4 zu erstellen wenn möglich. Ich habe zweitens einen Upgrade-Task gebaut, um bestehende utf8-Installationen auf utf8mb4 umzustellen. Dann brauchen wir nur noch einen dritten Schritt, um von alten Zeichensätzen zu utf8mb4 zu kommen, und alle Blogs hätten vollen Unicode-Support.

Mir hat das Treffen Spaß gemacht. Klasse, alle wiederzusehen, toll auch, sich am Samstag nach dem Corona-Wochenendeinkauf voll auf etwas ganz anderes konzentrieren zu können, und am Sonntag nebenher am utf8-Problem zu basteln.
Auf ein nächstes mal, bald oder nächstes Jahr, online oder in Essen.

Edit: Das schrieben die anderen:

• Thomas auf Netz - Rettung - Recht: Das virtuelle #s9ycamp2020