7.2 KiB
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: 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.
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 /<slug>
sofort live, ohne Code und ohne Rebuild:
titlesetzen (Pflicht).slugsetzen (Pflicht), englisch und ohne Umlaute — z. B.slug = schulwegergibt/schulweg.bodyals Markdown schreiben (optional; darf leer bleiben).publicanhaken. Ohne Haken ist die Seite ein Entwurf und erscheint auf der Website als „nicht gefunden" (404) — das ist der häufigste Stolperstein.- Optional
location(header/footer) undordersetzen, damit die Seite ins Menü kommt; optionalembedfür eingebettete Blöcke (siehe unten).
- Slug bleibt englisch und ohne Umlaute.
imprint,privacy,contact,board,patrons. Dertitledarf deutsch mit Umlauten sein (Förderverein). - Reservierte Slugs.
posts,events,faqsund/(die Startseitehome) gehören den festen Listen-/Sonderansichten. Einepages-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(headeroderfooter) undorder(Reihenfolge, ab 1). Die App baut Kopf- und Fußnavigation daraus; nichts wird im Markup angefasst. - Eingebettete Blöcke: Das Feld
embed(Mehrfachauswahl ausfaqs/posts/events) hängt unter den Text der Seite dynamische Blöcke. So ist die Startseite (home) eine normale Seite mitembed = [posts, events], und/faqseine Seite mitembed = [faqs]. Leeresembed= 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.
datesteuert Sortierung und angezeigtes Datum.slugist 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:30je 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.