Skip to content

Legal pages are the operator's own Markdown files

Superseded by ADR 0027: the app now links the pages instead of rendering them.

Context and Problem Statement

Every public instance needs an Impressum (§ 5 DDG) and a privacy policy (Art. 13 DSGVO), and with billing also terms. Each operator has different details, processors and obligations. Where do these texts come from?

Considered Options

  • The operator's own Markdown files, mounted into the container and named by IMPRINT_FILE, PRIVACY_FILE and TERMS_FILE
  • Texts generated by the app from OPERATOR_* and PRIVACY_* settings
  • Fixed texts in the code for the author's instance

Decision Outcome

Chosen option: "The operator's own Markdown files", because legal texts are the operator's responsibility and change for legal reasons, not software releases. It is the same setup the author already runs for another service.

  • Traureise ships none of the texts. Without a readable file the page (/impressum, /datenschutz, /agb) is a 404 and neither the app footer nor the wedding websites link to it.
  • Files are read on every request (at most 256 KiB), so an edit shows at once. The author keeps the instance's texts in a separate public deployment repository, versioned, so it is clear what a page said on which day.
  • Markdown is rendered with raw HTML escaped and only web, mail and phone links kept.
  • The app logs a warning at startup when IMPRINT_FILE or PRIVACY_FILE is missing or names nothing readable.

A generated version was built first and dropped: it put German legal wording into the code, where every operator would need a code change for their own wording, and it could only describe the processors it knew about.

Consequences

  • Good, because each operator's texts are exactly theirs, reviewed by their lawyer, and change without a release.
  • Bad, because a fresh instance has no legal pages until the operator writes them. The README and the docs say what a privacy policy for Traureise usually covers.

Confirmation

Unit tests for the file reader and the renderer. E2E checks that the default instance has no legal pages or links, and that the billing instance renders mounted fixture files and links them from the app and the wedding websites.