Viele aktuelle Vereinsseiten werden/wurden mit Joomla oder WordPress 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 oder die Seite wird irgendwann gehackt. Kommt euch bekannt vor? Genau dieses Muster hat mich dazu gebracht, für unseren OV E13 einen anderen Weg zu suchen.

Die Grundidee: einmal backen, dann nur noch ausliefern

Die Idee ist im Kern simpel: Statt eine Datenbank und ein PHP-Programm im Netz laufen zu lassen, die ständig gepflegt und abgesichert werden müssen, wird unsere Seite bei jeder Änderung einmal neu “gebacken” und danach nur noch als fertiges HTML ausgeliefert. Damit fallen genau der Server und die Datenbank weg, über die Vereinsseiten üblicherweise gehackt werden – und gehackte Joomla- und WordPress-Seiten gehören leider zum Alltag.

Damit das kein Techniker-Spielzeug bleibt, sondern auch Vorstandsmitglieder ohne Vorkenntnisse Beiträge schreiben können, kommen drei Bausteine zusammen:

  • Hugo – backt aus einfachen Textdateien eine fertige HTML-Seite
  • Sveltia CMS – die Eingabemaske im Browser: Titel, Text, Bild, „Speichern"
  • GitLab Pages – verwahrt die Textdateien, baut die Seite automatisch und liefert sie aus

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 wann was geändert hat. 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.

So sieht es für die Redaktion aus

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. 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, Git oder anderen technischen Details muss dabei niemand etwas sehen. Sveltia läuft nur statisch im Browser, braucht keinen eigenen Server und spricht direkt mit GitLab.

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


flowchart TB
  subgraph browser["Browser (Redaktion)"]
    F["Sveltia CMS
(/admin/)"]
  end
  subgraph gitlab["GitLab - komplett gemanagt"]
    direction TB
    G["Git-Repository
nur Textdateien (Markdown + YAML)"]
    O["OAuth-Login"]
    C["CI/CD-Pipeline"]
    P["GitLab Pages Hosting"]
  end
  subgraph browserb["Browser (Besucher)"]
    V["Besucher:in"]
  end
  F -- "Login" --> O
  F -- "Speichern per GitLab" --> G
  G -- "Push löst Build aus" --> C
  C -- "Hugo baut HTML" --> P
  P -- "liefert aus" --> V

Der Punkt an diesem Bild: Alles, was eine Redaktion wirklich anfasst, ist die Sveltia-CMS-Umgebung – 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 Sicherheitsupdate, um die sich jemand kümmern müsste.

Ein Blick unter die Haube

Technisch steckt hinter Sveltia CMS 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 festgelegt, damit im Formular kein Fachbegriff und kein rohes YAML auftaucht. Die Anmeldung läuft über eine GitLab-OAuth-App, das heißt: Für den Login wird GitLab benutzt, und GitLab legt über seine eigenen Zugriffsrechte fest, wer was darf. Beim Speichern passiert im Hintergrund Folgendes: Commit ins Logbuch → Hugo backt neu → nach einer halben bis zwei Minuten (meist kürzer) ist die Änderung online.

Flexibel arbeiten – und ehrlich bleiben bei der Wartung

Das Schöne ist, dass der Weg über Git beim Arbeitsablauf sehr flexibel ist: Wer mag, kann die Seite auch erst auf dem eigenen Rechner bearbeiten, dort in Ruhe anschauen und den fertigen Stand später hochladen. Für die normale Redaktionsarbeit braucht das aber niemand.

Ganz ohne Pflege ist auch das nicht: Hugo, das Theme und die Pipeline altern natürlich weiter. Der Unterschied ist, dass ein verpasstes Update hier kein Sicherheitsloch aufreißt, sondern höchstens ein neues Feature liegen lässt. Die Seite steht auch dann noch, wenn ein Jahr lang niemand hinschaut.

Kompromisse und Vorteile im Überblick

Ganz ohne Kompromisse ist der Ansatz nicht. Ich würde das Repository öffentlich fahren, und das heißt: Alles darin ist einsehbar – auch Entwürfe und jede einzelne Änderung, inklusive GitLab-Benutzername und Zeitstempel. (Technisch ginge auch ein privates Repository, aber die Offenheit ist hier ausdrücklich gewollt.) Für den OV hieße das: keine Mitgliederlisten, Adressen oder internen Protokolle im Repository, das müsste über ein getrenntes System laufen, z. B. eine verwaltete Nextcloud. Dafür bekämen wir 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 auf keinen Anbieter festlegen: Sollte GitLab irgendwann dichtmachen, zieht man mit allen Inhalten einfach um.

Unterm Strich bleibt damit ein System, das gleich mehrere Baustellen auf einmal löst: Für den Vorstand bedienbar wie ein normales Formular, ganz ohne Technik-Vorkenntnisse – und für alle, die es genauer wissen wollen, jederzeit mit vollem Zugriff auf den kompletten Quellcode und jede einzelne Änderung im Repository. Es braucht keine laufende Wartung: kein Server, kein Datenbank-Backup, keine PHP- oder Plugin-Updates, um die sich jemand kümmern müsste. Und weil jedes Mitglied mit Zugriff aufs Repository das Formular nutzen kann, hängt die Pflege der Seite nicht mehr an einer einzelnen Person oder einem eigenen Website-Team – jeder im Verein kann Beiträge schreiben, nicht nur wer sich mit Joomla auskennt. Backup und Undo gibt es quasi geschenkt dazu: Weil jede Änderung ein Commit im Logbuch ist, lässt sich jeder frühere Stand jederzeit wiederherstellen, ganz ohne separates Backup-System.

Ein paar weitere Vorteile fallen erst auf, wenn man eine Weile damit arbeitet: Hosting und Bauen der Seite sind für ein öffentliches Projekt wie unseres komplett kostenlos. Die Angriffsfläche schrumpft praktisch auf null, weil es keine Datenbank und kein öffentliches Login-Formular gibt, das gehackt werden könnte. Und weil jede Änderung technisch ein Commit ist, ließe sich das sogar noch weitertreiben: Änderungen könnten vor der Veröffentlichung von einer zweiten Person gegengelesen werden (Merge Request) – für uns aktuell nicht nötig, aber jederzeit möglich.

Und wenn Heiko mal keine Lust mehr hat?

Das ist die wichtigste Frage bei so einem Vorschlag, und sie ist völlig berechtigt. Bei einer klassischen Vereinsseite lautet die ehrliche Antwort meistens: Dann steht der Verein vor einem Server, für den niemand mehr das Passwort hat, einem Hoster-Vertrag, den niemand kündigen mag, einer Datenbank, die niemand lesen kann, und einer Handvoll Plugins, von denen nur einer wusste, warum sie in genau dieser Version drin sind.

Hier bleibt nach meinem Ausstieg das übrig: ein GitLab-Projekt mit Textdateien. Kein Server, kein Hoster-Vertrag, kein Datenbank-Backup, nichts, was bei mir im Keller läuft. Drei Dinge machen das aus meiner Sicht deutlich robuster:

Die Inhalte überleben die Technik. Die Beiträge sind Markdown-Dateien – lesbarer Text mit ein paar Sternchen drum herum. Die kann man in jedem Texteditor öffnen und weiterverwenden, selbst wenn Hugo, Sveltia und GitLab alle drei verschwunden wären. Bei einem Datenbank-Dump ist das nicht so.

Nichts hängt an einer Person. Das Repository würde einer GitLab-Gruppe des OV gehören, nicht meinem privaten Account, und es gäbe von Anfang an mehrere Owner. Wer Zugriff braucht, muss dafür nicht erst mich erreichen.

Nichts verfällt still. Wenn ein Jahr lang niemand die Technik anfasst, passiert genau nichts: Die Seite bleibt online, bleibt sicher und bleibt über die Eingabemaske bedienbar. Und selbst wenn jemand beim Herumprobieren den Bauvorgang zerlegt, bleibt die zuletzt gebaute Seite online – kaputtmachen kann man nur den nächsten Versuch, nicht die laufende Seite.

Was ich nicht behaupten will: dass sich nie wieder jemand kümmern muss. Irgendwann will jemand ein neues Feature, und dann braucht es jemanden, der Hugo anfasst. Der Unterschied ist, dass das kein Sonderwissen ist. Hugo, Git und Markdown sind dokumentiert, weit verbreitet, und Tutorials gibt es in Mengen – ein handgepatchtes Joomla-Template mit fünf Jahren Historie ist der Sonderfall, nicht die Hugo-Seite. Und wenn sich wirklich niemand findet: Die Inhalte sind Dateien. Man zieht damit zu einem anderen Anbieter um oder gibt sie einer Agentur in die Hand, ohne jemanden um Erlaubnis fragen zu müssen.

Dazu kommt, dass der Werkzeugkasten heute ein anderer ist. Wer vor fünf Jahren tiefer in eine Vereinsseite eingreifen wollte, musste die Technik dahinter wirklich beherrschen. Heute setzt man sich mit einem KI-Assistenten davor, beschreibt in normalem Deutsch, was anders werden soll, und lässt sich den Vorschlag erklären. Dass das bei diesem Aufbau besonders gut funktioniert, ist kein Zufall: Ein Git-Repository mit Textdateien ist genau das Format, in dem diese Werkzeuge zu Hause sind – sie sind an Millionen solcher Projekte trainiert und können die ganze Seite lesen, statt sich durch ein Admin-Menü zu klicken. Eine Joomla-Installation, deren Zustand in einer Datenbank und in angeklickten Häkchen steckt, kann man so einem Assistenten gar nicht erst in die Hand geben.

Der eigentliche Punkt ist dabei nicht der Assistent, sondern das Netz darunter. Weil jede Änderung als Commit im Logbuch landet, ist sie einzeln nachvollziehbar und einzeln zurückzunehmen. Man kann einen Vorschlag erst auf einem Nebengleis bauen lassen, sich das Ergebnis in Ruhe ansehen und ihn erst dann übernehmen – die öffentliche Seite merkt davon bis zum letzten Klick nichts. Genau das ist der Unterschied: Hier ist Ausprobieren folgenlos. Im Admin-Bereich einer Datenbank-Seite ist jeder Fehlgriff sofort live.

Wie geht es jetzt weiter?

Wichtig zum Stand der Dinge: Für den OV E13 ist damit noch nichts entschieden. Das beschriebene System läuft für diese Seite produktiv und für unsere Vereinsseite habe ich ein Beispiel unter https://amateurfunk-im-alstertal.dh3iko.de erstellt (das Repository findet sich auf GitLab). Dort kann man sich anschauen, wie interaktiv eine statische Seite sein kann: aktuelle Beiträge, Tags statt komplizierter Menüs, Bilder und Termine mit Kalenderdarstellung und Kalender-Import. Das alles funktioniert ohne Datenbank genauso wie bei Joomla. 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 live anschauen möchte: Ich zeige das Setup gerne am Stationsabend am 21.07.2026, 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.