Viele aktuelle Vereinsseiten werden/wurden mit Joomla gebaut. Nun vergehen die Jahre und die Updates werden schleifen gelassen: Ein Update des Templates auf die neue Version steht an, ein Plugin ist plötzlich inkompatibel, die PHP-Version läuft aus - und aus “mal eben aktualisieren” wird ein ganzer Nachmittag voller Fehlermeldungen. Kommt euch bekannt vor? Genau dieses Muster hat mich dazu gebracht, für unseren OV E13 einen anderen Weg zu suchen.

Die Idee dahinter ist eigentlich simpel: Statt eine Datenbank und ein PHP-Programm im Netz laufen zu lassen, das ständig gepflegt und abgesichert werden muss, wird unsere Seite bei jeder Änderung einmal neu “gebacken” und danach nur noch als fertiges HTML ausgeliefert. Es gibt schlicht nichts mehr, was gehackt werden könnte - anders als bei Joomla oder WordPress, wo gehackte Vereinsseiten leider zum Alltag gehören.

Damit das kein Techniker-Spielzeug bleibt, sondern auch der Rest vom Vorstand ohne Vorkenntnisse Beiträge schreiben kann, kommen drei Bausteine zusammen:

Die Inhalte liegen als einfache Textdateien in einem Git-Repository bei GitLab. Wer mit Joomla groß geworden ist, kennt Git vielleicht noch nicht - stellt es euch am besten wie ein Logbuch vor. Genau wie wir jedes QSO mit Datum, Uhrzeit und Rapport festhalten, hält Git jede Änderung an unseren Dateien fest: wer hat wann was geändert. Nichts geht verloren, man kann jederzeit zurückblättern, und ein aus Versehen gelöschter Artikel ist nie wirklich weg. GitLab ist dabei der Ort im Netz, wo dieses Logbuch liegt - ungefähr wie eine Dropbox mit eingebautem Logbuch, dazu für ein öffentliches Projekt wie unseres komplett kostenlos.

Aus den Textdateien backt dann Hugo die fertige Webseite. Das läuft vollautomatisch bei GitLab, sobald jemand etwas ändert - niemand muss Hugo von Hand bedienen.

Und damit auch niemand die Textdateien von Hand anfassen muss, habe ich mir Sveltia CMS angeschaut und testweise auf genau dieser Seite hier unter /admin/ eingerichtet - als Machbarkeits-Test, nicht als fertige Lösung. Das ist der Teil, den eine Redaktion tatsächlich zu sehen bekäme: ein Formular wie in Joomla - Titel eintippen, Text schreiben, Bild hochladen, “Speichern” klicken. Von Frontmatter, YAML oder Git sieht dabei niemand etwas. Sveltia ist kompatibel zum verbreiteten Decap/Netlify-CMS-Format, aber komplett neu geschrieben: läuft nur im Browser, braucht keinen eigenen Server und spricht direkt mit der GitLab-API.

Damit klarer wird, wo bei diesem Aufbau eigentlich was passiert, hier einmal als Bild:


flowchart TB
  subgraph browser["Browser (Redaktion)"]
    F["Formular in Sveltia CMS
(/admin/)"]
  end

  subgraph gitlab["GitLab - komplett gemanagt"]
    G["Git-Repository
nur Textdateien (Markdown + YAML)"]
    O["OAuth-Login (PKCE)"]
    C["CI/CD-Pipeline"]
    P["GitLab Pages Hosting"]
  end

  F -- "Login" --> O
  F -- "Speichern = Commit per API" --> G
  G -- "Push löst Build aus" --> C
  C -- "Hugo baut HTML" --> P
  P -- "liefert aus" --> V["Besucher:in"]

Der Punkt an diesem Bild: Alles, was eine Redaktion wirklich anfasst, ist das Formular ganz links - und was dabei am Ende herauskommt, ist immer nur eine Textdatei im Repository. Login, Speichern, Bauen der Seite und Hosting laufen komplett innerhalb von GitLab; es gibt keinen eigenen Server, kein Datenbank-Backup und kein Update-Fenster, um das sich jemand kümmern müsste.

Technisch steckt hinter dem Formular eine einzige config.yml, die festlegt, welche Formulare es gibt: eines für Blog-Beiträge, eines für feste Seiten wie “Über uns” und eines für die Startseite mit den Ankündigungen. Jedes Feld - Titel, Datum, Tags, Entwurfs-Häkchen, Bilder - ist einzeln typisiert, damit im Formular kein Fachbegriff und kein rohes YAML auftaucht. Die Anmeldung läuft über eine GitLab-OAuth-App im PKCE-Verfahren, also ganz ohne geheimes Passwort, das irgendwo hinterlegt werden müsste. Beim Speichern passiert im Hintergrund: Commit ins Logbuch -> Hugo backt neu -> nach ein bis zwei Minuten ist die Änderung online. Wer offline testen will, kann Sveltia sogar gegen einen lokal laufenden Hugo-Server statt gegen GitLab arbeiten lassen.

Ganz ohne Kompromisse ist der Ansatz nicht. Ehrlich gesagt: Alles im Repository ist öffentlich einsehbar - auch Entwürfe und jede einzelne Änderung, inklusive GitLab-Benutzername und Zeitstempel. Würden wir das für den OV übernehmen, hieße das: keine Mitgliederlisten, Adressen oder internen Protokolle im Repository, das müsste über ein getrenntes System erfolgen z.b. eine gemanagete Nextcloud. Dafür bekämen wir im Gegenzug eine Transparenz, die zum Amateurfunk-Gedanken passt - jeder kann nachschauen, wie die Seite gebaut ist, und jeder andere OV kann sich den Aufbau kopieren. Und weil die Inhalte simple Textdateien sind, würden wir uns bei keinem Anbieter festlegen: Sollte GitLab irgendwann dichtmachen, zieht man mit allen Inhalten einfach um.

Wichtig zum Stand der Dinge: Für den OV E13 ist damit noch nichts entschieden. Unsere Vereinsseite läuft weiterhin unverändert, und welche Lösung am Ende zum Einsatz kommt, wird im Vorstand noch diskutiert. Was ich hier auf meiner eigenen Seite zusammengebaut habe, ist einer von mehreren Kandidaten, die auf dem Tisch liegen - keine beschlossene Sache und schon gar kein fertiger Umzugsplan.

Wer sich das trotzdem mal live anschauen möchte: Ich zeige das Setup gerne am nächsten Dienstag, inklusive “Beitrag anlegen und zwei Minuten später online sehen”, und freue mich über jede Meinung dazu. Unter /admin/ reinschauen kann dabei allerdings nur, wer Zugriff auf das Repository hat - wer es selbst ausprobieren möchte, kann sich das Repository klonen, wie in der README beschrieben eine eigene GitLab-OAuth-App dafür einrichten und sich das Admin-Interface dann auf den eigenen GitLab Pages anschauen.