Unser Kirby Dev Setup

In den letzten Jahren haben wir diverse Webseiten und Plugins für Kirby entwickelt. Dabei hat sich ein solides Setup etabliert, das wir hier vorstellen.

Unser Tech-Stack

DDEV-Docker-Setup

Um Entwicklungsumgebungen schnell und konsistent aufzusetzen, nutzen wir DDEV:

• Ermöglicht das Hochfahren eines Docker-Containers mit der passenden PHP-Version ohne lokale Installation.
• Jedes Projekt erhält eine eigene Local-Dev-Domain.
• Konfigurationen können geteilt werden, um Einheitlichkeit sicherzustellen.

Zed als Editor

• Wir arbeiten viel mit WebStorm, aber das kann kein PHP.
• Zed unterstützt PHP und alle gängigen Frontend-Frameworks.
• AI-unterstütztes Autocomplete über Ollama verbessert den Workflow.

Kirby Plugin-Environment

• Um Plugins nicht isoliert zu entwickeln, haben wir ein Plugin-Setup erstellt, das ein lokales Kirby-System hochfährt.
• Das Plugin kann direkt im Frontend und im Panel getestet werden.
• Eine Bootstrap-Datei injiziert das Plugin.
• Build-Skripte und Composer sorgen dafür, dass beim Paketieren nur das reine Plugin enthalten ist.

Verzeichnisstruktur

• .github – Enthält GitHub-Automationen für Semantic Releases.
• plugin – Beinhaltet Plugin-Dateien wie Hooks und Page-Methods.
• site – Dient zum lokalen Testen mit Templates und Blueprints.
• lib – Enthält plugin-eigene Klassen.

Plugin-Veröffentlichung via Composer

• Wir nutzen Composer Autoloading, sodass Dateien im lib-Ordner automatisch verknüpft werden.
• Abhängigkeiten fügen wir mit composer require hinzu.
• Kirby ist als Dev-Dependency enthalten, um Tests zu ermöglichen, wird aber beim Bauen entfernt.
• Composer-Settings erlauben es, empfohlene oder ersetzende Plugins zu definieren.
• Zusätzlich setzen wir in composer.json PHP-Versionen und andere relevante Parameter.

Release-Management mit Semantic Versioning

• Die Plugin-Version wird in composer.json verwaltet und per GitHub Actions automatisch erhöht.
• Tags, Releases und Changelogs werden basierend auf Commit Messages generiert.
• Die aktualisierte Version wird in composer.json und package.json übernommen.
• Änderungen werden ins Repository gepusht.

Lizenzierung

Je nach Projekt kann ein Plugin kostenlos oder kostenpflichtig angeboten werden. Bei der Wahl der richtigen Lizenz sind verschiedene Faktoren zu beachten:

• Open-Source-Lizenzen wie MIT oder GPL.
• Kommerzielle Modelle.
• Wichtig: Dies stellt keine Rechtsberatung dar.

Tests schreiben

• PHPUnit ist unser Standard-Testing-Framework.
• Page-Mocks helfen bei umfangreichen Plugins.
• Methoden sind bewusst klein gehalten, um Tests unabhängig von Kirby-Seiten zu ermöglichen.

Optionen in Plugins einbauen

• Einhaltung eines Namespace-Konzepts.
• Default-Werte setzen.
• Optionen nicht direkt in Klassen nutzen, sondern im Konstruktor übergeben, um Tests zu erleichtern.

Arten von Kirby-Plugins

Kirby erlaubt es, nahezu alles zu erweitern, zu überschreiben oder zu kombinieren:

• Panel-Views und Panel-Felder.
• Page-Methods und eigene Klassen.
• Templates, Snippets und weitere Core-Funktionalitäten.

Dokumentation

• Jedes Plugin enthält eine README.
• Umfangreichere Plugins bekommen einen docs-Ordner mit Markdown-Dateien zu einzelnen Themen.

Contribution von Außenstehenden

• Feedback und Vorschläge über GitHub-Issues.
• Pull-Requests sind willkommen.

Typische Probleme & Herausforderungen

• Multilingual-Unterstützung.
• URLs zu Kirby-Seiten korrekt handhaben.

Unser Setup hat sich über die Jahre als sehr stabil erwiesen, wird aber natürlich kontinuierlich optimiert und an neue Kirby-Features angepasst. Wenn ihr Fragen oder Anregungen habt, lasst es uns wissen!