0.48.0-beta.2

Wartungsmodus

Neu, und der eigentliche Grund für diese Beta: Die öffentliche Seite lässt sich
für Besucher schließen, während im Hintergrund Adressen umgestellt und Inhalte
nachgezogen werden.

Zwei Schalter. MAINTENANCE_MODE greift ohne Datenbank und gilt damit auch
während einer Migration — der Schalter fürs Deployment-Fenster. Der Schalter im
Dashboard unter System & Verwaltung → Wartungsmodus wirkt sofort und ohne
Redeploy, mit eigenem Text und optionaler Angabe, bis wann es voraussichtlich
dauert.

Durch kommt, wer angemeldet ist und Dashboard-Zugriff hat, oder wer
/api/maintenance/bypass?token=… aufgerufen hat — das setzt ein Cookie und
funktioniert auch ohne Konto. Anmeldung, Dashboard und Datei-Auslieferung
bleiben immer erreichbar.

Freischaltung erlaubt nur das Ansehen: Kontaktformular, Newsletter und
Kursanmeldung bleiben auch für Freigeschaltete gesperrt, damit während einer
Umstellung nichts Neues in die Datenbank läuft. Angemeldete Redaktion schreibt
normal weiter.

Auf next bitte gezielt gegenprüfen: die beiden Freischaltwege. Lokal war
nur die Verweigerung testbar (ohne Token antwortet der Link mit 404); der Weg
über die Sitzung und der über das Cookie brauchen einen echten Server. Konkret:
Wartung im Dashboard einschalten, dann / im normalen Fenster (echte Seite
erwartet) und in einem privaten Fenster (Wartungsseite erwartet) öffnen.

Fehlerseiten

Die Anwendung hatte keine einzige Fehlergrenze — ein unbehandelter Fehler beim
Rendern führte auf die nackte Standardseite von Next, ohne Navigation und ohne
Weg zurück. Jetzt steht dort eine Seite im Layout der Website, mit „Erneut
versuchen", Wegen zur Startseite und zum Kontaktformular sowie einer
Fehlerkennung, über die sich eine Meldung dem Server-Log zuordnen lässt. Eine
zweite, bewusst schlichte Seite fängt den Fall ab, dass das Grundgerüst selbst
scheitert.

Förderverein: Flyer

Der Knopf „Flyer herunterladen" zeigte seit jeher auf eine Datei, die es nicht
gab — Besucher landeten ausgerechnet dort auf einer 404-Seite, wo sie sich für
eine Mitgliedschaft interessieren. Die Datei ist jetzt da.

Die Sonderaktionen auf der Förderverein-Seite nennen weiterhin Fristen aus
2025. Das ist bekannt und wartet auf die inhaltliche Abstimmung.

Unter der Haube

• Die CI fährt alle Migrationen auf einer leeren Datenbank hoch und prüft auf
  Schema-Drift, dazu Post-Migration-Setup und Slug-Backfill — jeweils zweimal,
  weil sie bei jedem Containerstart laufen. Bisher wurde nur das Schema
  validiert, nie die Migrationen ausgeführt.
• Deployment-Checkliste und DSGVO-Leitfaden überarbeitet. Der DSGVO-Leitfaden
  führte Datenexport und Konto-Löschung als „nicht implementiert", obwohl es
  beides längst gibt — wer eine Auskunftsanfrage danach bearbeitet hätte, wäre
  unnötig in Handarbeit gelaufen.
• BETTER_AUTH_GITHUB_CLIENT_ID und -SECRET aus README und
  Deployment-Doku entfernt: Im Code kommen sie nirgends vor, standen dort aber
  als erforderlich.

Migration

Eine neue: 20260910160000_maintenance_state legt die einzeilige Tabelle für
den Wartungsmodus an und trägt die Zeile gleich ein. Läuft beim Deploy
automatisch.

Neue Variablen

Für die Produktion später erforderlich, sonst lässt der Stack keinen Deploy zu:

• Secret MAINTENANCE_BYPASS_TOKEN (openssl rand -hex 24)
• Variable MAINTENANCE_MODE — leer lassen; nur zum Schließen auf true setzen