Die [hsmr]-Webseite

Statische Seite mit Astro: Aus Textdateien wird beim Bauen fertiges HTML. Kein Login, keine Datenbank, nichts, was auf dem Server laufen muss.

Das hier ist für Leute aus dem Space, die etwas ändern wollen.

Lokal starten

Node.js muss da sein. Dann einmalig npm install, danach jedes Mal:

npm run dev

Die Seite liegt auf http://localhost:4321 und übernimmt Änderungen beim Speichern. Beenden mit Strg+C.

Fürs Telefon im selben WLAN: npm run dev -- --host, dann die angezeigte 192.168.…-Adresse eintippen.

Im Browser bearbeiten

Es gibt eine Redaktionsoberfläche, die direkt in die Dateien schreibt — ohne Git, ohne Konto. Bei laufendem npm run dev: http://localhost:4321/admin/index.html, dann „Work with Local Repository" und den Projektordner auswählen.

Nur in Chrome, Edge oder Brave — Firefox und Safari fehlt die Datei-Schnittstelle dafür. Die Seite selbst kannst du natürlich überall ansehen.

Der Editor macht keine Commits. Er ändert Dateien, mehr nicht.

Wo was liegt

src/content/
├── tagebuch/    ein Eintrag pro Tag
├── termine/     einmalige Termine
├── serien/      wiederkehrende Termine
├── projekte/    ein Projekt pro Datei
├── team/        wer welchen Bereich betreut
└── seiten/      Fließtext der festen Seiten

Die Seiten selbst liegen als Astro-Vorlagen in src/pages/. Die meisten holen ihren Text aus src/content/seiten/; Fotos, Karten und Projektkarten bleiben in der Vorlage. Was pro Seite bearbeitbar ist, steht als Kommentar oben in der jeweiligen Datei.

Adresse, Telefon, Mail, IBAN und Vorstand stehen zentral in src/data/space.yaml und wirken überall dort, wo sie angezeigt werden. Ausnahme: /kontakt und /en haben ihre Kontaktdaten im Fließtext stehen, weil sie dort mitten im Satz vorkommen. Wenn du in space.yaml etwas änderst, sieh dort kurz nach — vergessen kannst du es nicht, ein Test meldet es.

Tagebucheintrag

Neue Datei src/content/tagebuch/2026-08-24.md:

---
datum: 2026-08-24
---

* Lötkolben für die Elektrowerkstatt besorgt
* Getränkelager aufgefüllt

Stichpunkte reichen. Monatsübersicht, Archiv und RSS entstehen daraus von selbst.

Termin

Neue Datei unter src/content/termine/, Name egal:

---
titel: Lötworkshop für Einsteiger
beginn: 2026-09-12T18:00:00+02:00
ende: 2026-09-12T20:00:00+02:00
---

Kurzer Text, der unter dem Termin steht.

Der Text wird wörtlich übernommen, Markdown wirkt hier nicht — derselbe Text geht in den Kalender-Feed, und der kann kein Markdown. Eine Web-Adresse schreibst du deshalb einfach hin (mehr unter https://di.day/): Auf der Webseite wird sie zum anklickbaren Verweis, im Kalender bleibt sie Text.

ende ist optional. ort nur angeben, wenn der Termin nicht im Space stattfindet. Fällt ein Termin aus: abgesagt: true — er bleibt dann sichtbar und durchgestrichen, statt einfach zu verschwinden.

Wiederkehrende Termine

Eine Datei pro Serie unter src/content/serien/:

---
titel: Chaostreff
rhythmus: woechentlich
wochentag: MO
beginn: '18:00'
ende: '21:00'
---
Space-Montag — offen für alle, kein Vorwissen nötig.

Bei rhythmus: monatlich kommt position dazu: 1 bis 4, oder -1 für „der letzte". Das Ende ist eine Uhrzeit, keine Dauer; liegt es vor dem Beginn, ist der nächste Tag gemeint.

Einzelne Termine absagen:

faellt_aus:
  - 2026-12-24

Sie verschwinden nicht, sondern stehen durchgestrichen da — auch bei allen, die den Kalender abonniert haben. Ein vertipptes Datum lässt den Bau fehlschlagen; lieber das als eine Absage, die stillschweigend nichts tut.

Was Markdown hier automatisch macht

Im Fließtext einer Seite und im Tagebuch:

• ## setzt den Zwischenstrich darüber, die Leiterbahn mit den Lötaugen
• - wird zur kurzen Bahn mit Lötauge statt zum runden Punkt
• --- zeichnet denselben Trenner ohne Überschrift

Nummerierte Listen behalten ihre Zahlen.

Was nicht im Editor steht

Die Umgangsvereinbarung und der englische Code of Conduct (src/components/Umgangsvereinbarung.astro, CodeOfConduct.astro). Das ist vom Plenum beschlossener Text, der wortwörtlich stehen muss — ein Test vergleicht ihn bei jedem Bau Wort für Wort. Ein Editor-Dialog dafür wäre eine Falle: Jede Änderung ließe den Test scheitern, auch eine beschlossene. Änderungen daran sind Handarbeit, danach die Referenzfassung in tests/fixtures/ nachziehen.

Bauen und testen

npm run build

Prüft Typen, baut die Seite und geht danach jeden Verweis durch — tote Links, ins Leere zeigende Weiterleitungen und kaputte Shell-Blöcke in den Workflows fallen dabei auf. Verweise innerhalb der Seite fangen immer mit / an, nicht mit ../.

Dazu npm test für die schnellen Tests und npm run test:e2e für die im echten Browser. Für einen Tagebucheintrag brauchst du beides nicht.

Wie die Seite live geht

Ein Push auf main baut und rollt aus, ohne dass jemand etwas tun muss:

push → Tests → Bau → Abbild in die Registry → per SSH auf wega → Container neu

Läuft ein Test oder der Bau nicht durch, entsteht kein Abbild und es wird nichts ausgerollt. Der Container auf wega liegt hinter Caddy; Einzelheiten dazu in deploy/wega/README.md.

nginx.conf enthält außerdem 33 Weiterleitungen von den alten PmWiki-Adressen, damit Links aus Mails und Suchmaschinen nicht ins Leere laufen. Wer daran etwas ändert: scripts/weiterleitungen-pruefen.sh fährt sie gegen einen echten Container.

Dieselbe Datei schaltet die Zugriffsprotokollierung ab. Die Seite führt keine Liste darüber, wer wann was gelesen hat — /datenschutz sagt das zu, also muss es stimmen. Einzelheiten in deploy/wega/README.md.

Das Wiki

Seit dem 13. September 2026 liegt die Dokumentation in Outline auf wiki.hsmr.cc, nicht mehr im PmWiki. Sie hat zwei Teile: einen öffentlichen, ohne Anmeldung lesbaren, und einen für Mitglieder — dort stehen die Infrastruktur-Dokumentation und die Protokolle der Mitgliederversammlungen.

Die Adressen dafür stehen in src/data/space.yaml unter wiki und wiki_protokolle. Es sind bewusst die Freigabe-Adressen (/s/…) und nicht wiki.hsmr.cc selbst: Letzteres führt ohne Konto direkt in die Anmeldemaske. Wird die Freigabe in Outline neu erteilt, ändert sich ihre Kennung — dann müssen beide Zeilen mit.

Wie der Umzug lief und was dabei wohin sortiert wurde, steht in docs/wiki-migration.md.

Was ein Mensch entscheiden muss

Nichts davon hält die Seite auf, aber entscheiden kann es keine Technik:

• Das Meldeformular aus der Umgangsvereinbarung. Der beschlossene Text verspricht ein pseudonymes Formular für Grenzüberschreitungen; eine statische Seite hat keins, und /regeln sagt das auch. Ob eins gebaut oder der Text geändert wird, entscheidet das Plenum.
• Zwei Telefonnummern. Impressum, Kontaktseite und altes Wiki nennen übereinstimmend +49 6421 9689159, die separat gepflegte SpaceAPI dagegen +49 6421 4924981. Diese Seite nimmt durchgehend die aus space.yaml — korrigiert gehört die Quelle, die falsch ist.
• Die vier Raumfotos auf /besuchen sind 200×200-Pixel-Vorschaubilder aus dem alten Wiki. Querformatige, helle Fotos wären der größte einzelne Hebel dafür, wie die Seite wirkt.
• /verein/team ist leer. Solange niemand eingetragen ist, zeigt die Seite einen Hinweiskasten statt einer Liste — sie sieht nicht kaputt aus, sagt aber auch nichts.

Warum einzelne Dinge absichtlich so sind, wie sie sind — und nicht reparaturbedürftig —, steht in docs/entscheidungen.md.

Wer wissen will, was hinter alldem steckt — welche Software, wie die Teile zusammenhängen, wo die Seite läuft —, findet das in docs/aufbau.md.