5.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.
Ü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. Dertitledarf deutsch mit Umlauten sein (Förderverein). - 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.