Auch wenn meine Seite noch nicht mit Kirby 5 läuft, weil das POSSE plugin noch nicht aktualisiert wurde, hab ich bereits auf anderen Seiten das Update auf Version 5 durchgeführt und ein paar mögliche Probleme bei der Aktualisierung gefunden.

Mit Kirby 5 kann man zum ersten Mal Änderungen vor dem Speichern als Vorschau anzeigen lassen. Das ging vorher nur, wenn man Seiten duplizierte. Jetzt gibt es sogar einen Split-View, um die aktuelle Version und die geänderte Version nebeneinander anzuzeigen bevor man Änderungen speichert. Als ich das zum ersten Mal auf einer Seite mit Kirby 5 ausprobiert hatte, ging die Vorschau allerdings nicht. Das lag an zwei Dingen.

Erstens hatte ich relativ strikte Header in dem Caddy-Server konfiguriert, die das Einbetten der Seite als iframe verhindern. Kirby’s Vorschaufunktion nutzt aber iframes, um Änderungen anzuzeigen. Die Lösung war die Caddy-Konfiguration anzupassen und den Header X-Frame-Options von deny auf same-origin zu stellen. Das erlaubt die Seite unter der gleichen Domain als iframe einzubetten, also genau das was Kirby macht. Nach der Änderung in der Konfiguration muss der Caddy-Service neu gestartet werden: systemctl restart caddy. Danach hat die Vorschau über die iframes funktioniert.

Dann bin ich allerdings auf ein zweites Problem gestoßen: Die Änderungen wurden in der Vorschau nicht angezeigt oder manchmal nur beim ersten Mal. Hier lag es an dem Caching, das ich in Cloudflare konfiguriert hatte. Wie ich Kirby-Seiten in Cloudflare cache, will ich demnächst noch in einem Blog Post teilen. Für die Vorschau in Kirby 5 war die Lösung eine neue Cache Regel anzulegen, die das Caching für alle URLs mit dem Query Parameter _token abschaltet. Dieser Parameter wird von Kirby an alle URLs der Vorschau-iframes übergeben.

Also hab ich eine neue Cache Rule erstellt, unter Custom Filter Expression bei Field die Einstellung Query String Parameter ausgewählt, bei Operator wildcard und bei Value den Wert _token=*.

Darunter noch Cache eligibility und Browser TTL auf Bypass Cache stellen und alle URLs mit dem Query Parameter _token werden von Cloudflare nicht mehr gecachet.

Mit diesen Änderungen bei Caddy und Cloudflare, funktioniert das Vorschau-Feature von Kirby 5 jetzt ohne Probleme. Ich freue mich schon Version 5 bald auch auf meiner Seite zu nutzen.

Das Kirby POSSE plugin von Philipp Defner läuft bei mir jetzt als composer package und mit der neusten Version. Dadurch kann ich einen Token direkt über die Einstellungen des Plugins konfigurieren. Vor der aktuellen Version hatte ich den Code des Plugins eingecheckt und angepasst, damit API Aufrufe auch über einen Token authentifiziert werden können. Das bietet die neue Version des Plugins jetzt selbst ans.

Philipp arbeitet gerade auf einer Branch schon an der nächsten Version, in der Templates für Posts über das Plugin als Snippets konfiguriert werden können. Bisher war meine Erfahrung mit Kirby-Plugins eher mittelmäßig, aber das Plugin funktioniert sehr zuverlässig. Ich empfehle selbst einmal durch dessen Code zu lesen. Er ist sehr gut strukturiert und hat eine hohe Qualität.

PS: GitHub scheint gerade aus irgendeinem Grund nicht die neuste Version der README auf der Seite des Repositorys anzuzeigen. Wenn ihr die REAME.md direkt öffnet, wird aber die neuste Version der Dokumentation inklusive Token korrekt dargestellt.

PPS: Meine Notizen haben jetzt auch ein neues Metabild, das näher am leicht veränderten Design meiner Webseite ist.

Der PHP-Prozess auf meinem Server ist in unregelmäßigen Abständen abgestürzt, wodurch dann alle Kirby-Seiten nicht mehr erreichbar waren. Ein manueller Neustart des FPM-Prozesses hat das Problem immer behoben, aber das ist natürlich keine langfristige Lösung. Also hab ich mich auf die Suche begeben, wodurch der Fehler entsteht.

Der erste Schritt war im PHP Log nachzuschauen, ob es eine Fehlermeldung gab:

cat /var/log/php8.3-fpm.log

Und tatsächlich wurde dort auch eine Warnung festgehalten, kurz bevor die Seiten nicht mehr erreichbar waren:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

Über eine schnelle Suche im Internet bin ich auf diesen sehr guten Post von Chris Moore gestoßen, der erklärt was pm.max_children und die weiteren Einstellungen bedeuten. Anscheinend hab ich das Problem, dass zu viele Menschen oder Bots gleichzeitg auf meine Seite kommen, sodass der FPM-Prozess die Anfragen mit den aktuellen Einstellungen nicht beantworten kann.

Chris Moore hat einen PHP-FPM Process Calculator entwickelt, mit dem man ausrechen kann, welche PHP-Konfiguration für die Leistung des eigenen Servers sinnvoll sein könnte.

Um die passenden Werte berechnen zu können, müsst ihr wissen, wie viel RAM euer Server hat und was die durchschnittliche Prozessgröße der aktuellen FPM-Prozesse ist. Um diese zu ermitteln, kann man folgenden Befehl ausführen:

ps -C php-fpm8.3 -o rss=
// mögliche Rückgabe auf eurem Server:
    31252
    44488
    43116
    39544

Die erste Zahl ist der Hauptprozess, der für die Berechnung laut Chris nicht relevant ist. Die anderen Zahlen sind die Subprozesse in Kilobyte. In dem Beispiel nutzen die Prozesse also ca. 39 bis 45 Megabyte.

Ich würde mich sicherheitshalber an der höheren Zahl orientieren (45 MB) und sie als Wert in den Calculator von Chris Moore als Process size (Mb) eintragen. Außerdem stellt ihr noch den RAM eures Servers ein, wie viel RAM ihr für andere Prozesse frei halten wollt und einen zusätzlichen prozentualen Puffer.

Die errechneten Werte aus dem Calculator passt ihr dann in der PHP Konfiguration an:

nano /etc/php/8.3/fpm/pool.d/www.conf

Nachdem ihr die Werte in der Datei geändert habt, muss der PHP-FPM Prozess neugestartet werden:

systemctl reload php8.3-fpm.service

Danach werden beim Ausführen von ps -C php-fpm8.3 -o rss= wahrscheinlich mehr oder weniger Prozesse anzeigt als vorher, je nachdem welche Werte ihr in der Config eingetragen habt.

Hinweis: Wenn ihr eine andere PHP-Version verwendet müsst ihr 8.3 bei allen Befehlen in eure PHP Version ändern.

Ich habe zusätzlich noch das Caching für meine PHP-Seiten angepasst, damit trotz mehr Ressourcen für die PHP-Prozesse weniger Traffic beim Server ankommt. Durch die beiden Änderungen hoffe ich, dass das Problem gelöst ist und PHP nicht mehr abstürzt. 🤞

Falls das nicht ausgereicht hat, werde ich mich erneut auf die Suche nach einer Lösung begeben und hier berichten.

Ich teste gerade das POSSE plugin von Philipp Defner. Wenn der cronjob funktioniert, sollte diese Notiz mit etwas Verzögerung automatisch bei Mastodon landen. Die direkte Veröffentlichung meiner Notiz über das Panel UI des Plugins hat schon direkt funktioniert. 🙂

Ich habe gerade die Jung & Naiv Suche aktualisiert. Sie nutzt jetzt Version 0.8 von flexsearch, die den Fehler aus 0.7 behebt, dass beim Exportieren vom Suchindex selbst hinzugefügte Felder fehlen.

Durch den Bug der vorherigen Version musste der Index deshalb im Browser erstellt werden. Wer bisher auf die Seite kam, hat gesehen, dass im ersten Schritt alle Untertiteldateien aller Videos geladen wurden. In einem zweiten Schritt wurde dann noch lokal ein neuer Suchindex erstellt, indem alle geladenen Dateien durchlaufen und zum Index hinzugefügt wurden.

Durch den Bugfix der neuen Version können Indizes korrekt exportiert und importiert werden. Deshalb kann der Index jetzt heruntergeladen und importiert werden. Der zweite prozessorlastige Schritt fällt also weg und der erste Schritt lädt jetzt den fertigen Suchindex herunter, statt die rohen Untertiteldateien.

Der neue Nachteil ist, dass der gesamte Index für alle "Jung & Naiv" Videos mit 500 MB ziemlich groß geworden ist. Vor der Suche muss also ein halber Gigabyte heruntergeladen werden. Das ist nicht besonders datenschonend.

flexsearch hat mit der Version 0.8 die Möglichkeit erhalten Indizes auf verschiedene Arten persistent zu speichern. Statt in mehreren Dateien kann ein Suchindex auch im Browser mit IndexedDB, aber auch auf dem Server mit SQLite, Redis oder Postgres importiert und durchsucht werden.

Ich werde deshalb dem Projekt demnächst eine Datenbank hinzuzufügen, sodass der halbe Gigabyte große Index auf dem Server liegt und nur noch Suchbegriff und Ergebnisse zwischen Server und Browser ausgetauscht werden. Weil das Projekt aber noch bei Vercel liegt, statt auf meinem Server, braucht es auch ein neues Server-Setup, um das kostengünstig zu ermöglichen. Wenn ich das Projekt auf einen neuen Server umziehe, sollte der gleich mit Coolify oder Dokploy gemanagt sein. Außerdem läuft das Projekt noch mit Svelte 4, was nicht mehr aktuell ist. Und dann wärs natürlich noch schön, wenn neue Videos automatisch zum Suchindex hinzugefügt werden würden, statt dass ich ab und zu manuell Skripte dafür ausführen muss.

Es gibt also noch einiges zu tun, um das Projekt wirklich automatisiert und zugänglich für alle zu machen. Ich bleibe weiter dran, weil das ganze Self-Hosting-Thema mich sowieso sehr interessiert und ich darin noch deutlich mehr Erfahrung sammeln möchte.