Technik und Architektur des Vereinspakets

Architektur

Drei Schichten, keine Frameworks

Schicht 1

Statische Website

HTML, CSS und JavaScript als einzelne Dateien. Kein serverseitiges Rendering, keine Template-Engine, kein Build-Schritt. Jeder Webserver kann diese Seiten ausliefern.

Schicht 2

Daten als JSON

Veranstaltungen, Chronik und Konfiguration liegen als JSON-Dateien im Dateisystem. Für die Website selbst gibt es kein MySQL und keine andere Datenbank. Das JavaScript im Browser lädt die Dateien und stellt die Inhalte dar.

Schicht 3

Admin-Panel in PHP

Eine eigenständige Anwendung unter /admin, die die JSON-Dateien über eine interne Schnittstelle liest und schreibt. Session-basierte Anmeldung. Kein Composer, kein npm, kein Framework.

Wo dann doch eine Datenbank läuft

Die drei Schichten oben kommen ohne Datenbank aus. Für die übrigen Bausteine gilt das nicht, und zwar in zwei verschiedenen Abstufungen:

Der Newsletter nutzt eine einzelne MySQL-Tabelle zur Dokumentation der Einwilligungen. Sie wird ausschließlich von eigenen PHP-Skripten gelesen und geschrieben — es gibt keine Fremdsoftware, also auch keine Updates
Community-Plattform und Cloud bringen jeweils eine eigene Datenbank und eine vollständige Anwendung mit. Hier fallen regelmäßige Sicherheitsupdates an

Die Unterscheidung ist wichtig: Eine Datenbank zu verwenden erzeugt für sich genommen keinen Pflegeaufwand. Den erzeugt Software von Dritten, die aktualisiert werden muss.

Der praktische Unterschied liegt in der Entkopplung. Bei einem datenbankgestützten CMS hängt die öffentliche Seite an der Datenbank — ein Ausfall oder eine beschädigte Tabelle legt den gesamten Auftritt still. Hier laufen die Zusatzanwendungen auf eigenen Subdomains mit eigenen Datenbanken. Fällt eine davon aus, bleibt die Website erreichbar, weil zwischen beiden keine Abhängigkeit besteht.

Was daraus folgt

Ein vollständiges Backup ist eine Kopie des Verzeichnisses
Es gibt keine Fremdbibliotheken, die veralten oder eingestellt werden könnten
Ein Umzug auf einen anderen Hoster bedeutet: Dateien kopieren, fertig
Die Inhalte bleiben in einem offenen, lesbaren Format — auch ohne dieses System

Kernpunkt

Warum das System ohne Updates sicher bleibt

WordPress ist eine aktive Anwendung. Bei jedem Seitenaufruf führt der Server PHP-Code aus, fragt eine Datenbank ab, verarbeitet Plugins und erzeugt daraus die HTML-Seite. Jede dieser Komponenten — Core, Plugins, Themes, PHP, MySQL — kann Sicherheitslücken enthalten und muss deshalb laufend aktualisiert werden. Die Angriffsfläche ist groß, weil bei jedem Aufruf viel Code läuft.

Dieses System hat eine deutlich kleinere Angriffsfläche. Die öffentliche Website besteht aus statischen Dateien, die der Server unverändert ausliefert — dabei wird kein Code ausgeführt, also kann dort auch keine Lücke entstehen. Die einzige aktive Komponente ist das Admin-Panel. Es liegt hinter einem Login, wird nur vom Vereinsteam genutzt und hat keinerlei Abhängigkeiten von Drittanbietern, die veralten könnten.

Damit beschränkt sich die zu pflegende Fläche auf eine überschaubare, selbst geschriebene PHP-Anwendung statt auf ein Ökosystem aus Hunderten von Plugins. Solange die PHP-Version auf dem Server aktuell ist — und dafür sorgt der Hoster — läuft das System stabil, ohne dass jemand etwas tun muss.

Wichtig zur Einordnung: Das gilt für Website, Kalender und Verteiler. Die optionalen Bausteine Community-Plattform und selbst betriebene Cloud sind vollwertige Anwendungen mit Datenbank und brauchen sehr wohl regelmäßige Updates. Nachzulesen im Abschnitt Was Pflege braucht.

Im Detail

Sicherheit, Hosting, Wiederverwendbarkeit

Sicherheitsmaßnahmen im Admin-Panel

Passwörter: bcrypt-Hash, zeitkonstanter Vergleich
Anmeldeversuche: IP-basierte Begrenzung mit eskalierenden Sperren, nicht durch einen Session-Wechsel umgehbar
CSRF: Token-Prüfung bei allen schreibenden Vorgängen
Uploads: MIME-Prüfung, Whitelist erlaubter Ziele, Zufalls-Suffix im Dateinamen, PHP-Ausführung in Upload-Verzeichnissen serverseitig gesperrt
XSS: serverseitiges Filtern und zusätzlich clientseitiges Maskieren — zwei unabhängige Ebenen
Schreibvorgänge: atomar über temporäre Datei und Umbenennen, sodass kein halb geschriebener Zustand entstehen kann
Sitzungen: Zeitablauf bei Inaktivität, Schutz gegen Session-Fixation, eigener Cookie-Name
Interne Verzeichnisse: gegen Zugriff über den Browser gesperrt

Versionierung und Wiederherstellung

Bei jeder Änderung im Admin-Panel wird automatisch eine Sicherungskopie der vorherigen Fassung angelegt; die letzten zehn Versionen bleiben erhalten. Ein versehentlich gelöschter Termin oder ein überschriebener Text lässt sich damit wiederherstellen, ohne dass jemand ein Backup einspielen muss.

Hosting-Anforderungen

Bewusst minimal gehalten — kein Root-Server, kein Docker, kein Node.js, kein Build-Prozess.

Minimalanforderung: PHP 8.x, Webspace mit FTP
Empfehlung: Shared Hosting, ca. 8 € / Monat
Newsletter: Mailinglisten beim Hoster
Community-Plattform: Subdomain, MySQL, Cronjob
Cloud: Nextcloud auf dem Webspace oder eigener Server

Das System läuft auf dem günstigsten Shared-Hosting, das am Markt zu haben ist. Das ist kein Kompromiss, sondern Absicht: Was auf einfachster Infrastruktur läuft, fällt auch seltener aus.

Das gilt für Website, Kalender und Verteiler. Nextcloud dagegen ist eine vollwertige PHP-Anwendung mit Datenbank und stößt auf Shared Hosting an Grenzen: Die Hintergrundaufgaben brauchen einen Cronjob, die PHP-Speichergrenze muss angehoben werden, und diese Anpassungen werden bei Updates überschrieben. Echtzeitfunktionen wie Videotelefonie oder gemeinsames Bearbeiten von Dokumenten setze ich auf Shared Hosting nicht ein — dafür ist die Umgebung nicht gebaut. Wer das braucht, bekommt einen eigenen Server.

Wiederverwendbarkeit für weitere Organisationen

Alles Organisationsspezifische — Name, Farben, Veranstaltungsarten, Upload-Pfade, Verteiler — liegt in zwei Konfigurationsdateien. Für einen neuen Verein wird konfiguriert und angepasst, nicht neu programmiert. Deshalb sind die Paketpreise kalkulierbar und deshalb kann ein Verein die gleiche Qualität bekommen wie das Referenzprojekt.

Newsletter: zwei getrennte Systeme

Der Verteiler besteht bewusst aus zwei Teilen, die unterschiedliche Aufgaben haben und synchron gehalten werden.

Eine Datenbanktabelle für die Einwilligung. Sie hält fest, wann sich jemand eingetragen hat, über welches Formular, welchem Einwilligungstext genau zugestimmt wurde und wann bestätigt oder abgemeldet wurde. Eine E-Mail-Adresse kann dabei gleichzeitig auf der öffentlichen und der internen Liste stehen, ohne dass sich die Einträge in die Quere kommen.

Majordomo für den Versand. Die Listensoftware des Hosters verteilt die Mails. Sie speichert nur die nackte Adresse — keine Historie, kein Zeitstempel, keine Dokumentation.

Der Ablauf beim Eintragen: Das Formular legt einen Eintrag mit Status „ausstehend" und einem Zufallsschlüssel an und verschickt eine Bestätigungsmail. Erst wenn der Link darin angeklickt wird, wechselt der Status auf „aktiv" — und erst dann wird die Adresse an Majordomo übergeben. Wer nicht bestätigt, landet nie auf der Versandliste. Beim Abmelden läuft dasselbe rückwärts. Der Eintrag über das Admin-Panel macht denselben Doppelschritt, hinterlegt aber, dass es keine Selbstanmeldung war.

Verschickt wird anschließend über eine ganz normale E-Mail an die Listenadresse. Die Datenbank wird dabei nicht angefasst; ihre Arbeit ist getan, sobald die Einwilligung dokumentiert und die Adresse eingetragen ist.

Der Grund für die Trennung: Die Nachweispflicht nach Art. 7 Abs. 1 DSGVO verlangt, belegen zu können, dass und wie eingewilligt wurde. Majordomo allein kann das nicht. Ein Abo-Dienst kann es, lässt es sich aber monatlich bezahlen — und die Adressen liegen dann dort statt beim Verein.

Mehrsprachigkeit und Rechts-nach-links-Schriften

Jede Sprache erhält eigene Adressen in einem eigenen Verzeichnis, etwa /de/, /en/, /ar/. Das ist wichtig, damit geteilte Links und Suchmaschinen in der richtigen Fassung landen — eine reine Umschaltung per JavaScript ohne eigene Adresse leistet das nicht. Die Fassungen verweisen über hreflang gegenseitig aufeinander, das lang-Attribut sorgt für die korrekte Aussprache im Screenreader.

Die Inhalte liegen weiterhin als JSON vor, je Sprache eine Datei. Das Admin-Panel zeigt die Sprachen nebeneinander, sodass ein Termin nicht dreimal an drei Stellen angelegt werden muss.

Für Arabisch und Farsi wird das Layout nicht gespiegelt, sondern von Beginn an richtungsneutral gebaut: Das Stylesheet verwendet durchgehend logische Eigenschaften wie padding-inline-start statt padding-left. Bei dir="rtl" wechselt das Layout dadurch vollständig die Seite, ohne dass eine zweite Stylesheet-Fassung nötig wäre. Die Ausnahmen werden einzeln behandelt: Telefonnummern, Zahlenkolonnen und Pfadangaben bleiben von links nach rechts, Pfeile drehen sich, Häkchen und Symbole nicht.

Dazu kommt die Typografie. Arabische Schrift braucht bei gleicher Punktgröße mehr Zeilenabstand, und negatives Tracking zerstört die Ligaturen — beides wird per :lang(ar) gesondert gesetzt. Als Schrift kommt eine vollständige arabische Familie zum Einsatz, keine Ersatzdarstellung durch den Browser.

Diese Website ist selbst nach diesem Prinzip gebaut. Wer im Stylesheet nachsehen möchte: Abschnitt 11 enthält die vollständige RTL-Behandlung.

Barrierefreiheit

Grundsätzlich enthalten: sinnvolle Dokumentstruktur, ausreichende Kontraste, vollständige Bedienbarkeit per Tastatur, Beschriftungen für Screenreader, Rücksicht auf reduzierte Bewegung. Als Zusatzleistung möglich: eine Fassung in Leichter Sprache und mehrsprachige Versionen — für inklusive Organisationen und in Förderanträgen oft ein eigener Pluspunkt.

Technische Rückfragen stellen Zurück zum Paket