Elternbeirat/docs/redaktion.md

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
faq_topics	Themen der häufigen Fragen (z. B. „Mensa und Mittagessen")	Als aufklappbare Gruppen auf /faqs
faqs	Häufige Fragen	Auf /faqs, in der Gruppe ihres Themas

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
Neues FAQ-Thema (neue Gruppe auf /faqs)	Ja	Neuer Record in faq_topics (siehe Häufige Fragen)
Neue Textseite	Ja	Neuer Record in pages (siehe unten)
Eine Seite mit einer Liste anteasern	Ja	Feld embed der Seite (posts/events)
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:

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; erzwungen per Pattern (siehe Slug-Regel wird erzwungen unten). 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 posts/events) hängt unter den Text der Seite dynamische Blöcke. So ist die Startseite (home) eine normale Seite mit embed = [posts, events]. Leeres embed = reine Textseite. Die FAQ-Liste ist kein embed: /faqs ist eine feste Ansicht (siehe Häufige Fragen).

Die Startseite (home)

Der body der Startseite füllt den farbigen Kopfbereich. Die App zerlegt ihn so:

• Die erste #-Überschrift wird die große Überschrift im Kopfbereich. Fehlt sie, steht dort „Elternbeirat der IGMH".
• Besteht der letzte Absatz nur aus Links (je Link eine Zeile), werden daraus Knöpfe — der erste hervorgehoben, die übrigen umrandet. Steht in dem Absatz noch anderer Text, bleibt er normaler Text.
• Alles andere ist der Einleitungstext daneben.

# Willkommen beim Elternbeirat der IGMH

Hier finden Sie aktuelle Informationen rund um die Elternarbeit.

[Kommende Termine](/events)
[Kontakt aufnehmen](/contact)

Darunter erscheinen automatisch:

• Nächster Termin — der früheste kommende Termin aus events; gibt es keinen, entfällt die Karte.
• Kacheln — eine pro öffentlicher Seite mit location = header (außer der Startseite), in Menü-Reihenfolge. Der Kacheltext ist der erste Satz des body (ohne Überschrift, ggf. gekürzt); beginnt der Text mit einer Liste oder einem Baustein, zeigt die Kachel nur den Titel. Auf dem Handy zeigen die Kacheln immer nur Symbol und Titel (zwei Spalten), ab Tablet-Breite auch den Text (drei Spalten). Das Symbol hängt am Slug und ist im Code festgelegt; eine neue Seite bekommt ein Standardsymbol.

Eigene Felder für Kacheltext und Symbol gibt es (noch) nicht.

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

Slug-Regel wird erzwungen

Ein Slug muss ein sauberes URL-Segment sein: Kleinbuchstaben, Ziffern und einzelne Bindestriche als Trenner, keine Umlaute (ueber-uns, nicht Über uns). Das ist keine Bitte, sondern eine Feldregel: PocketBase weist einen Slug ab, der sie verletzt, und zeigt beim Speichern einen Fehler. Gibst du Overview ein, kommst du erst weiter, wenn du overview daraus machst. Die Website verlässt sich darauf — sie repariert einen Slug nicht mehr nachträglich.

Die Regel steckt als Pattern am Feld slug. So ist sie gesetzt (einmalig, pro Collection mit einem Slug — pages und posts):

1. Collection öffnen → Edit collection (oben rechts) → Feld slug.
2. Am Feld auf das Zahnrad (Feldoptionen) → Pattern.
3. Als Pattern eintragen: ^[a-z0-9]+(-[a-z0-9]+)*$
4. Save (Feld) und Save (Collection).

Zum Prüfen: board, ueber-uns, faq-lunch werden angenommen; Overview, über-uns, my page, -x und a--b werden abgewiesen.

---

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. Anders als bei Terminen zählt hier nur der Tag — eine Uhrzeit wird nie angezeigt, und die UTC-Verschiebung aus dem Termine-Hinweis spielt keine Rolle. Trage einfach das Datum ein.
• slug ist englisch, klein, ohne Umlaute (z. B. new-sports-hall-opened) — dieselbe erzwungene Feldregel wie bei Seiten (siehe Seiten → Slug-Regel wird erzwungen).

---

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.

Trage einfach die Ortszeit ein. Gib die Uhrzeit ein, die auf der Seite stehen soll (Europe/Berlin) — z. B. 08:00. PocketBase speichert intern in UTC und zeigt dir nach dem Speichern deshalb einen um 1–2 Stunden früheren Wert an (aus 08:00 wird im Sommer 06:00). Das ist kein Fehler: Die Website rechnet beim Anzeigen automatisch nach Ortszeit zurück und zeigt wieder 08:00, Sommer- und Winterzeit inklusive. Du musst dich um UTC nicht kümmern.

---

Häufige Fragen (faq_topics und faqs)

Die FAQ-Seite /faqs besteht aus zwei Collections: Themen (faq_topics) und Fragen (faqs). Jedes Thema erscheint als aufklappbare Gruppe, darin seine Fragen. Eine Frage gehört zu genau einem Thema, das du aus einer Liste auswählst — du tippst es nicht als Text ein.

Themen (faq_topics)

Ein Thema hat title, slug, intro (optional), order und public.

• title ist die Überschrift der Gruppe (z. B. Mensa und Mittagessen).
• intro ist ein kurzer Einleitungstext (Markdown), der beim Aufklappen über den Fragen steht.
• order legt die Reihenfolge der Gruppen fest (kleinere Zahl zuerst).
• slug ist englisch, klein, ohne Umlaute (z. B. lunch) — dieselbe Regel wie bei Seiten. Er wird derzeit nicht angezeigt, ist aber Pflicht.
• Eine neue Gruppe = ein neuer Record in faq_topics. Danach steht das Thema bei den Fragen zur Auswahl.

Fragen (faqs)

Eine Frage hat question, answer (Markdown), topic, order und public.

• topic: das Thema aus faq_topics auswählen.
• order legt die Reihenfolge innerhalb des Themas fest (kleinere Zahl zuerst).

Stolpersteine. Eine Frage ohne topic erscheint nirgends auf der Website. Ist ein Thema nicht public, verschwinden auch alle seine Fragen — egal, ob diese selbst public sind.

Überschrift und Rahmentext oben auf /faqs sind eine eigene Seite in pages (Slug faqs).

---

Gestaltungsbausteine

Alle Texte (body von Seiten und Beiträgen, intro und answer bei den FAQs) sind Markdown. Die Website gestaltet sie automatisch: Zwischenüberschriften (## …) bekommen einen grünen Strich, Listen grüne Punkte, Zitate (> …) einen farbigen Balken. Darüber hinaus gibt es ein paar Bausteine, mit denen du eine Seite selbst gestaltest — ohne Code und ohne HTML.

Kein HTML. HTML im Text (<div>, <br>, <script> …) wird nicht ausgeführt, sondern als Text angezeigt. Das ist Absicht: Die Datenschutzerklärung sagt zu, dass kein Programmcode im Browser läuft. Für Gestaltung die Bausteine unten nehmen.

Bausteine mit :::

Ein Baustein beginnt mit ::: name in einer eigenen Zeile und endet mit :::. Dazwischen steht normales Markdown. Vor und nach dem Baustein eine Leerzeile lassen. Die Namen sind fest; ein vertippter Name schadet nicht — der Inhalt erscheint dann einfach als normaler Text.

Kennzahlen — eine Liste wird zu großen Zahlen-Kacheln. Der fett geschriebene Anfang ist die Zahl, der Rest die Beschriftung darunter:

::: kennzahlen
- **seit 1975** im Einsatz für die IGMH
- **über 500** Mitglieder
- **ab 10 €** Jahresbeitrag
:::

Aufruf — eine hervorgehobene Box für die wichtigste Aktion der Seite. Links darin erscheinen als Button:

::: aufruf
Die Beitrittserklärung füllen Sie online beim Förderverein aus.

[Zur Beitrittserklärung](https://easyverein.com/public/FDI/applicationform/21612)
:::

Kacheln — eine Liste als Raster aus Karten. Ein fetter Anfang wird zur Überschrift der Karte:

::: kacheln
- **Pädagogik** Bessere Rahmenbedingungen für die Arbeit an der Schule
- **Projekte** Musische, sportliche und kulturelle Vorhaben
- **Ausstattung** Anschaffungen, die allen zugutekommen
:::

Hinweis — eine dezente Info-Box mit Info-Symbol:

::: hinweis
Bei dringenden Angelegenheiten wenden Sie sich bitte direkt an das Sekretariat.
:::

Links, die sich automatisch verändern

• Links auf andere Websites (https://…) bekommen ein kleines Pfeil-Symbol. Links auf eigene Seiten schreibst du ohne Domain: [Kontakt](/contact).

• PDF-Links (Adresse endet auf .pdf) bekommen ein Datei-Symbol und den Hinweis „PDF“. Steht der Link allein in einer Zeile oder einem Listenpunkt, wird er zur Datei-Karte — so wird eine Liste von Dokumenten zum Download-Bereich:

  - [Aufnahmeantrag Förderverein](/dokumente/aufnahmeantrag-foerderverein.pdf)
  - [Einzugsermächtigung](/dokumente/einzugsermaechtigung.pdf)
  

  Die PDF-Dateien selbst liegen nicht in PocketBase, sondern im Code unter wwwroot/dokumente/ (ein neues PDF braucht also einen Entwickler).

• E-Mail-Link allein in einem Absatz wird zum Button:

  [kontakt@elternbeirat-igmh.info](mailto:kontakt@elternbeirat-igmh.info)
  

  Steht der Link mitten im Satz („Schreiben Sie an …“), bleibt er ein normaler Link.

Tabellen

Tabellen gehen mit senkrechten Strichen; die zweite Zeile trennt die Kopfzeile ab. Auf dem Handy lässt sich eine breite Tabelle seitlich schieben.

| Tag      | Uhrzeit   | Ort        |
|----------|-----------|------------|
| Dienstag | 19:00 Uhr | Hörsaal 2  |

---

Regeln beim Speichern

• Nach dem Ändern einer Zugriffsregel immer den Haupt-Save der Collection drücken, sonst greift die Änderung nicht.
• Die fünf 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.