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. 🙂

Nachdem ich heute meine Lösung geteilt hab, den <title> im lokalen Kirby-Panel anzupassen, sodass er sich vom Live-CMS unterscheidet, hat mir Thomas Günther auf Mastodon geantwortet.

Kirby bietet die Möglichkeit über die config auch das Favicon zu ändern. Das ist noch sauberer und für mich deshalb die bessere Lösung. Der einzige Nachteil ist, dass man ein gutes Bild fürs Favicon braucht. 🖼️

Da ich jetzt schon mehrfach den Fehler gemacht hab Inhalte im lokal laufenden Kirby statt auf der Live-Seite zu erstellen, wollte ich den Unterschied zwischen lokalem CMS und Live-CMS im Tab sichtbar machen.

Um eigenes JavaScript im Kirby-Panel auszuführen, reichen ein paar Zeilen in der config Datei für die lokale Instanz, die auf die zu ladende JavaScript-Datei verweist:

'panel' => [
  'js' => 'assets/js/panel.js',
],

Innerhalb von panel.js hab ich eine Funktion geschrieben, die ein Emoji vor den Titel der Seite hängt. Alle Tabs mit lokalem Kirby sind dadurch leicht erkennbar. Das Hinzufügen des Emoji wird durch einen MutationObserver ausgelöst, der auf Änderungen reagiert:

function updateTitle() {
  if (!document.title.startsWith("⚙️")) {
    document.title = "⚙️ " + document.title;
  }
}

new MutationObserver(updateTitle).observe(document.querySelector("title"), {
  childList: true,
});
document.addEventListener("DOMContentLoaded", updateTitle);

Wahrscheinlich gibt es noch eine "sauberere" Variate, die auf Vue.js und Kirbys Panel reagiert. Der Vorteil dieser Variante ist, dass der Code auch weiterhin funktioniert, wenn Vue.js oder Kirby neue APIs nutzen oder Kirby zu einem ganz anderen Framework wechseln sollte.

Mein Kirby Panel begrüßt mich jetzt freundlich und fragt mich, was ich tun möchte:

Es gibt leider kein type: button in Kirby, deshalb hab ich ein Info Feld mit Link verwendet. Der entsprechende Teil im Blueprint für das Design oben sieht so aus:

fields:
  headline:
    label: Hey Max 👋
    type: headline
    help: Was möchtest du tun?
  notizenLink:
    label: ""
    type: info
    theme: warning
    text: |
      **(link: /panel/pages/notizen text: Notiz erstellen)**
    width: 1/5
  notesLink:
    label: ""
    type: info
    theme: warning
    text: |
      **(link: /panel/pages/notes text: Add note)**
    width: 1/5
  blogLink:
    label: ""
    type: info
    theme: passive
    text: |
      **(link: /panel/pages/blog text: Blog schreiben)**
    width: 1/5
  line:
    type: line

Durch Kirby läuft meine Webseite zum ersten Mal mit einem richtigen CMS. Die Möglichkeit Seiten zu bearbeiten, möchte ich deshalb so einfach und bequem wie möglich machen. Wenn mir z.B. ein Tippfehler auffällt, will ich ihn schnell korrigieren können.

Ich wollte aber keinen Button zu meiner Seite hinzufügen oder irgendwo verstecken und auch keine Logik schreiben, um ihn nur anzuzeigen, wenn ich im CMS angemeldet bin. Wie kann ich trotzdem schnell ins CMS zum Bearbeiten der aktuellen Seite wechseln?

Mit einem Keyboard-Shortcut!

Ein paar Zeilen JavaScript reichen aus, um Browser auf die entsprechende Panel-URL von Kirby weiterzuleiten. Die Entscheidung welches Tastenkürzel es sein soll, war gar nicht so einfach zu treffen. Ich hab mich letztendlich für Cmd+Opt+. entschieden. Die Kombination ist eher unüblich, gleichzeitig noch bequem genug, aber trotzdem relativ unwahrscheinlich, dass man sie versehentlich nutzt.

Wenn ihr auch einen Keyboard-Shortcut auf eurer Webseite haben wollt, um direkt ins Panel zum Bearbeiten der aktuellen Seite zu springen, könnt ihr euch folgenden JS-Code kopieren (und mit der Tastenkombination eurer Wahl anpassen):

window.addEventListener("keydown", (event) => {
  if (event.metaKey && event.altKey && event.code === "Period") {
    const url = new URL(window.location.href);
    window.location.href = `${url.origin}/panel/${
      url.pathname === "/"
        ? "site"
        : "pages/" + url.pathname.slice(1).replace("/", "+")
    }`;
  }
});

Update: Der JS-Code leitet jetzt auf der Homepage zur Startseite des Panels weiter, statt auf eine falsche Panel-URL. Falls ihr lieber beim Bearbeiten der Homepage landen wollt, ersetzt "site" mit "pages/home".

Ich bin mir nicht sicher, welche HTML Tags RSS Reader unterstützen. Deshalb teste ich mit dieser Notiz einmal verschiedene Tags:

• Eine Liste
• mit mehreren Punkten

Eine Zwischenüberschrift

Das ist ein Zitat.

<web-component>Code-Test</web-component>

Funktioniert eine Linke mit <hr>?

Die Linie sollte über diesem Text angezeigt werden.

Wie sieht es mit <details> aus? Kann man Klapptexte in RSS Readern haben?

So das waren erstmal alle Tests. Die Tags, die nicht funktionieren, werde ich in Kirby für meine Notizen deaktivieren.

Seit wenigen Minuten läuft meine Seite über Kirby statt Astro. Bisher sollte alles größtenteils beim alten sein. Nur ein paar URLs haben sich geändert und werden jetzt auf neue weitergeleitet.

Außerdem haben sich die URLs von meinen RSS-Feeds geändert. Laut der RSS-Spezifikation sollten RSS-Reader einen 301 Redirect erkennen und automatisch auf die neue Feed-URL wechseln. Ob das wirklich funktioniert, wird diese Notiz zeigen. Wenn es klappt, sollte sie gleich in meinem Reader erscheinen. 🤞