123 lines
5.2 KiB
Markdown
123 lines
5.2 KiB
Markdown
# 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.
|