Inhalte sollen an ausgewählten Stellen Bilder enthalten können (z. B. Beiträge, einzelne Seiten). Ob und wie wir das umsetzen, ist aktuell offen — hier festgehalten, damit es vor Go-Live entschieden wird.
Warum nicht "einfach den Rich-Editor"
Die body/answer-Felder wurden bewusst von editor (Rich-Text/HTML) auf text (rohes Markdown) umgestellt, weil die App Markdown selbst rendert. Der PocketBase-editor-Button "Bild einfügen" lädt keine Datei hoch, sondern setzt nur ein <img src="…">:
externe URL → verstößt gegen "Keine externen Ressourcen" (docs/recht.md, Datenschutz)
Base64-Data-URI → bläht den Datensatz auf, nicht cachebar/wiederverwendbar
Der Rich-Editor löst Bild-Upload also nicht und bringt das externe-Ressourcen-Problem zurück. Nicht der Weg.
Sauberer Weg (noch zu entscheiden)
text-Body (Markdown) beibehalten, zusätzlich ein file-Feld an der Collection (oder eigene media-Collection) für echte Uploads.
PocketBase speichert die Datei und liefert eine URL vom eigenen Server → datenschutzkonform.
Im Markdown referenziert per ; Web-App muss die Upload-URL auflösen/ausliefern.
Berührt zwei Architektur-Entscheidungen (bewusst zu treffen)
AE-3 "Inhalte liegen im Image, nicht im Volume": Bild-Uploads landen im PocketBase-Volume auf Unraid → Inhalte nicht mehr allein per git clone reproduzierbar. Abkehr von AE-3, muss in docs/architektur.md dokumentiert werden.
Recht/Fotos (docs/recht.md): bei Personen-/Kinderfotos Einwilligungen, Löschkonzept, Bildrechte.
Offene Punkte
Welche Stellen brauchen Bilder (Beiträge? Seiten? beides)?
Feld-/Collection-Design für Uploads (file-Feld vs. media-Collection)
Web-App: Upload-URLs auflösen und ausliefern (weiterhin keine externen Ressourcen)
AE-3 in docs/architektur.md nachziehen (Volume statt Image für Bilder)
Inhalte sollen an ausgewählten Stellen **Bilder** enthalten können (z. B. Beiträge, einzelne Seiten). Ob und wie wir das umsetzen, ist aktuell **offen** — hier festgehalten, damit es vor Go-Live entschieden wird.
## Warum nicht "einfach den Rich-Editor"
Die `body`/`answer`-Felder wurden bewusst von `editor` (Rich-Text/HTML) auf `text` (rohes Markdown) umgestellt, weil die App Markdown selbst rendert. Der PocketBase-`editor`-Button "Bild einfügen" lädt **keine Datei hoch**, sondern setzt nur ein `<img src="…">`:
- externe URL → verstößt gegen "Keine externen Ressourcen" (`docs/recht.md`, Datenschutz)
- Base64-Data-URI → bläht den Datensatz auf, nicht cachebar/wiederverwendbar
Der Rich-Editor löst Bild-**Upload** also nicht und bringt das externe-Ressourcen-Problem zurück. Nicht der Weg.
## Sauberer Weg (noch zu entscheiden)
- `text`-Body (Markdown) beibehalten, zusätzlich ein **`file`-Feld** an der Collection (oder eigene `media`-Collection) für echte Uploads.
- PocketBase speichert die Datei und liefert eine URL vom **eigenen** Server → datenschutzkonform.
- Im Markdown referenziert per ``; Web-App muss die Upload-URL auflösen/ausliefern.
## Berührt zwei Architektur-Entscheidungen (bewusst zu treffen)
- **AE-3 "Inhalte liegen im Image, nicht im Volume":** Bild-Uploads landen im PocketBase-**Volume** auf Unraid → Inhalte nicht mehr allein per `git clone` reproduzierbar. Abkehr von AE-3, muss in `docs/architektur.md` dokumentiert werden.
- **Recht/Fotos (`docs/recht.md`):** bei Personen-/Kinderfotos Einwilligungen, Löschkonzept, Bildrechte.
## Offene Punkte
- [ ] Welche Stellen brauchen Bilder (Beiträge? Seiten? beides)?
- [ ] Feld-/Collection-Design für Uploads (`file`-Feld vs. `media`-Collection)
- [ ] Web-App: Upload-URLs auflösen und ausliefern (weiterhin keine externen Ressourcen)
- [ ] AE-3 in `docs/architektur.md` nachziehen (Volume statt Image für Bilder)
- [ ] `docs/recht.md`: Einwilligungen / Bildrechte / Löschkonzept
Gehört zu #6.
Tom
added this to the Elternbeirat-Website milestone 2026-09-23 13:52:39 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Inhalte sollen an ausgewählten Stellen Bilder enthalten können (z. B. Beiträge, einzelne Seiten). Ob und wie wir das umsetzen, ist aktuell offen — hier festgehalten, damit es vor Go-Live entschieden wird.
Warum nicht "einfach den Rich-Editor"
Die
body/answer-Felder wurden bewusst voneditor(Rich-Text/HTML) auftext(rohes Markdown) umgestellt, weil die App Markdown selbst rendert. Der PocketBase-editor-Button "Bild einfügen" lädt keine Datei hoch, sondern setzt nur ein<img src="…">:docs/recht.md, Datenschutz)Der Rich-Editor löst Bild-Upload also nicht und bringt das externe-Ressourcen-Problem zurück. Nicht der Weg.
Sauberer Weg (noch zu entscheiden)
text-Body (Markdown) beibehalten, zusätzlich einfile-Feld an der Collection (oder eigenemedia-Collection) für echte Uploads.; Web-App muss die Upload-URL auflösen/ausliefern.Berührt zwei Architektur-Entscheidungen (bewusst zu treffen)
git clonereproduzierbar. Abkehr von AE-3, muss indocs/architektur.mddokumentiert werden.docs/recht.md): bei Personen-/Kinderfotos Einwilligungen, Löschkonzept, Bildrechte.Offene Punkte
file-Feld vs.media-Collection)docs/architektur.mdnachziehen (Volume statt Image für Bilder)docs/recht.md: Einwilligungen / Bildrechte / LöschkonzeptGehört zu #6.