# 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.
> **Stand.** Die Blazor-App liest ihren gesamten Inhalt aus PocketBase (Issue #8);
> die alte Datei-Schicht unter `Content/` gibt es nicht mehr. PocketBase ist damit
> 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:** (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.
### Was redaktionell geht — und was Code braucht
Redaktion arbeitet mit **Daten**, nicht mit Struktur. Konkret:
| Was du willst | Geht redaktionell? | Wie |
|---|---|---|
| Beitrag / Termin / Frage hinzufügen | **Ja** | Neuer Record in `posts` / `events` / `faqs` — erscheint sofort in der jeweiligen Liste |
| Neue Textseite | **Ja** | Neuer Record in `pages` (siehe unten) |
| Eine Seite mit einer Liste anteasern | **Ja** | Feld `embed` der Seite (`posts`/`events`/`faqs`) |
| **Neue Art von Liste** (eigene Seite mit eigener Sortierung/Gruppierung und eigener Adresse, z. B. „Protokolle") | **Nein** | Braucht Entwicklung: neue Collection **plus** Code |
Das heißt: **Bestehende Listen lassen sich beliebig erweitern**, aber eine *neue*
Listenart entsteht nicht durch Anlegen einer Collection allein. Die drei Listen
(`posts`, `events`, `faqs`) sind fest verdrahtet, weil jede eine eigene
Darstellung hat — Datum und Sortierung, Kalender/`.ics`, Themen-Gruppierung. Eine
weitere solche Ansicht anzulegen ist ein **Entwickler-Task**: eine neue Collection
in PocketBase, eine Lesemethode im `PocketBaseClient` und eine eigene Komponente
mit ihrer Route (siehe `docs/entwicklung.md`). Das ist Absicht: Inhalte sind
Daten, Struktur und Darstellung sind Code.
---
## 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 **Markdown**).
**Eine neue Seite anlegen** — Record in `pages`, dann ist die Adresse `/`
sofort live, ohne Code und ohne Rebuild:
1. `title` setzen (Pflicht).
2. `slug` setzen (Pflicht), englisch und ohne Umlaute — z. B. `slug = schulweg`
ergibt `/schulweg`.
3. `body` als Markdown schreiben (optional; darf leer bleiben).
4. **`public` anhaken.** Ohne Haken ist die Seite ein Entwurf und erscheint auf
der Website als „nicht gefunden" (404) — das ist der häufigste Stolperstein.
5. Optional `location` (`header`/`footer`) **und** `order` setzen, damit die Seite
ins Menü kommt; optional `embed` für eingebettete Blöcke (siehe unten).
- **Slug bleibt englisch und ohne Umlaute.** `imprint`, `privacy`, `contact`,
`board`, `patrons`. Der `title` darf deutsch mit Umlauten sein (`Förderverein`).
- **Reservierte Slugs.** `posts`, `events`, `faqs` und `/` (die Startseite `home`)
gehören den festen Listen-/Sonderansichten. Eine `pages`-Seite mit einem dieser
Slugs wird von der jeweiligen Ansicht verdeckt und **nicht** angezeigt; in der
Produktion dienen solche Records nur als Menü-Platzhalter.
- **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/`; 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.