# Redaktion

Wie die sichtbaren Inhalte der Website gepflegt werden. Der Inhalt liegt in
**PocketBase** — einem kleinen Server mit eigenem Admin-Login — und wird dort
über die Weboberfläche bearbeitet. Keine Dateien, kein Commit, kein Rebuild: eine
Änderung im Admin ist sofort live.

> **Übergang (Stand #8).** Der Inhalt ist bereits vollständig in PocketBase; die
> Blazor-App wird gerade darauf umgestellt, ihn von dort zu lesen (Issue #8).
> Solange das läuft, kann die ausgelieferte Seite noch aus den alten Dateien
> unter `Content/` stammen. Sobald #8 durch ist, ist PocketBase die einzige
> Quelle und dieser Abschnitt der einzige Pflegeweg.

> **Sprachkonvention.** Feldnamen und Slugs sind **englisch** (`title`, `slug`,
> `board`, `posts`). Der Text, den ein Besucher liest, bleibt **deutsch** — also
> der Wert eines Feldes (`title: Vorstandsteam`) und der Fließtext. Englische
> Schlüssel, deutsche Werte.

---

## Anmelden

Das Admin heißt „Redaktion Elternbeirat" und ist unter der PocketBase-Adresse
erreichbar:

- **Lokal:** <http://localhost:8090/_/> (Dev-Stack, siehe `entwicklung.md`).
- **Auf dem Server:** über die NPM-Subdomain (Login von außen — noch offen, #9).

Redakteure sind **Superuser**: jede vertraute Person aus dem Vorstand bekommt
einen eigenen Superuser-Zugang (unter *Collections → System → `_superusers`*).
Es gibt bewusst keinen eigenen Login und keinen Editor in der Website selbst —
gepflegt wird nur im Admin.

---

## Die Inhaltsarten (Collections)

Jede Inhaltsart ist eine **Collection**. Ein neuer Eintrag = ein neuer Record in
der passenden Collection (Button *New record*).

| Collection | Was | Öffentlich sichtbar über |
|---|---|---|
| `pages` | Feste Seiten (Vorstand, Impressum, Kontakt …) | Slug, z. B. `/board` |
| `posts` | Neuigkeiten / Beiträge | `/posts`, neueste zuerst |
| `events` | Termine (Kalender) | `/events` und der `.ics`-Feed |
| `faqs` | Häufige Fragen | Werden auf der FAQ-Seite gruppiert angezeigt |

Jede Collection hat als **letztes Feld `public`** (ja/nein). Nur Records mit
`public = true` erscheinen auf der Website — so lässt sich ein Entwurf anlegen,
ohne dass er schon sichtbar ist.

---

## Seiten (`pages`)

Eine Seite hat `title` (Überschrift für Menschen, Umlaute erlaubt), `slug` (die
URL, klein und **ohne Umlaute**: `board`, nicht `über-uns`) und `body` (der
Text, als Editor-Feld).

- **Slug bleibt englisch und ohne Umlaute.** `imprint`, `privacy`, `contact`,
  `board`, `patrons`. Der `title` darf deutsch mit Umlauten sein (`Förderverein`).
- **Menü:** Ob eine Seite ins Menü kommt, steht an der Seite selbst — die Felder
  `location` (`header` oder `footer`) und `order` (Reihenfolge, ab 1). Die App
  baut Kopf- und Fußnavigation daraus; nichts wird im Markup angefasst.
- **Eingebettete Blöcke:** Das Feld `embed` (Mehrfachauswahl aus
  `faqs`/`posts`/`events`) hängt unter den Text der Seite dynamische Blöcke. So
  ist die Startseite (`home`) eine normale Seite mit `embed = [posts, events]`,
  und `/faqs` eine Seite mit `embed = [faqs]`. Leeres `embed` = reine Textseite.

> **Impressum und Datenschutz** hängen an ihren Slugs (`imprint`, `privacy`).
> Diese Slugs nicht ändern — sonst laufen die rechtlich verlinkten Adressen ins
> Leere (404).

---

## Beiträge (`posts`)

Ein Beitrag hat `date`, `title`, `body`, `slug` und `public`. Er erscheint unter
`/posts` (neueste zuerst) und unter `/posts/<slug>`; die neuesten werden auch auf
der Startseite als Vorschau angeteasert.

- `date` steuert Sortierung und angezeigtes Datum.
- `slug` ist englisch, klein, ohne Umlaute (z. B. `new-sports-hall-opened`).

---

## Termine (`events`)

Ein Termin hat `start` (Pflicht), `end` (optional, für mehrstündige oder
mehrtägige), `title`, `location` (optional), `note` (optional) und `public`.
Kein Slug.

Die Übersicht `/events` trennt automatisch in kommende und vergangene Termine;
die Reihenfolge der Records spielt keine Rolle. Besucher können `/events.ics` in
ihrer Kalender-App abonnieren — der Feed entsteht aus denselben Records.

> **Uhrzeit = Ortszeit.** Das Admin-Formular rechnet Datumsfelder in die
> Browser-Zeitzone um und zeigt eine gespeicherte `19:30` je nach Sommer-/Winter-
> zeit als 20:30/21:30 an. Das ist **kein** Fehler, nur zwei Bezugssysteme: der
> gespeicherte Zahlenwert **ist** die Ortszeit (Europe/Berlin), die App zeigt ihn
> unverändert. Trage die Uhrzeit ein, die auf der Seite stehen soll.

---

## Häufige Fragen (`faqs`)

Eine Frage hat `question`, `answer` (Markdown), `topic` (eines von
`mensa`/`schliessfach`/`elterneuro`/`elternarbeit`) und `public`. Die App baut
die FAQ-Seite generiert: sie gruppiert die Fragen nach `topic`. Der Rahmentext
oben auf `/faqs` ist eine eigene Seite in `pages` (Slug `faqs`).

---

## Regeln beim Speichern

- **Nach dem Ändern einer Zugriffsregel** immer den Haupt-*Save* der Collection
  drücken, sonst greift die Änderung nicht.
- Die vier Collections sind öffentlich **lesbar** (List/View offen), aber nur
  eingeloggt **schreibbar** — ein Schreibversuch ohne Login wird abgewiesen. Das
  ist Absicht; nicht „vereinfachen".
- **Backup:** Der gesamte Inhalt liegt in `pb_data`. Ein Backup dieses
  Verzeichnisses (plus Restore-Test) ist der Sicherungsweg — eingerichtet in #9.