DogFatherGitandClaude Opus 5
356bb974b8
Zwei Rueckmeldungen vom 22.08.2026, beide behoben und mit Tests abgesichert.
1) "das sieht nicht gut aus" (Bildschirmfoto des Hauptknopfs)
Ursache: ".wd a" ist Klasse+Element und damit spezifischer als die reine
Knopfklasse ".wd-btn--haupt". Die Textfarbe des Knopfs wurde dadurch
ueberstimmt -- hellblaue Schrift auf hellblauem Grund, praktisch
unlesbar. Derselbe Spezifitaetsfehler wie zuvor bei den Namen auf der
Zugangswand. Fix: ".wd a:not(.wd-btn)" plus zweistufig geschriebene
Knopfregeln, damit das nicht wieder passieren kann.
2) "das sieht lang gezogen aus"
Die Pillenform (border-radius 999px) laesst breite Knoepfe
auseinandergezogen wirken, weil der Radius optisch mit der Breite
mitwaechst. Jetzt fester Radius von 14px -- gleiche Form bei jeder
Breite, ruhiger und hochwertiger.
3) "ich will das ich jedes mal den code gefragt werde wenn man die seite
zu macht"
Das Sitzungs-Cookie allein reicht dafuer nicht: Browser stellen genau
solche Cookies beim Wiederherstellen von Tabs zurueck ("Dort
fortfahren, wo du aufgehoert hast"), man landet dann ohne Codeabfrage
wieder mitten in der Seite. Zusaetzlich jetzt eine Sitzungsmarke im
sessionStorage, die beim echten Schliessen verschwindet. Fehlt sie bei
vorhandenem Cookie, wird die Sitzung serverseitig beendet und zur
Zugangswand geleitet. Token-Notbremse von 24 auf 8 Stunden gesenkt.
13/13 Tests im echten Browser, inklusive Schutz vor Endlosschleife.
DEPLOY.md: zwei Checkouts auf dem Server dokumentiert (/home/dogiweb und
/home/dogiintern) und der Vorfall, dass /webdesign nach dem Pull kurz ohne
Zugangsschutz erreichbar war, weil der Dienstneustart fehlte.
Co-Authored-By: Claude Opus 5 <[email protected]>
153 lines
7.7 KiB
Markdown
153 lines
7.7 KiB
Markdown
# DOGFATHER UNIVERSE — Go-Live-Anleitung
|
||
|
||
## ⚠️ ZUERST LESEN: Die echte Seite läuft auf dem NETCUP-SERVER, nicht auf Cloudflare
|
||
|
||
Seit dem öffentlichen Start (21.08.2026) wird `dogfather-universe.com` vom **eigenen
|
||
Netcup-Server** ausgeliefert. Der alte Cloudflare-Worker existiert zwar noch und lässt sich
|
||
auch weiterhin deployen — **er erreicht die echte Domain aber nicht mehr.**
|
||
|
||
Das ist die gefährlichste Stelle im ganzen Projekt: `npx wrangler deploy` läuft ohne Fehler
|
||
durch und meldet „Deployed", die Änderung ist danach auf `…workers.dev` sichtbar — und auf
|
||
`dogfather-universe.com` passiert **nichts**. Genau so ist es am 22.08.2026 beim Sprachfenster-
|
||
Fix passiert (siehe unten). Wer nur die Erfolgsmeldung von Wrangler liest, meldet „ist live",
|
||
obwohl Filipe auf dem Handy weiterhin den kaputten Stand sieht.
|
||
|
||
| Adresse | Läuft wo | Wird von wo beliefert |
|
||
|---|---|---|
|
||
| **`dogfather-universe.com`** ← **die echte Seite** | **Netcup**, Caddy → `localhost:4100`, systemd-Dienst `dogiweb.service`, Verzeichnis `/home/dogiweb/dogfather-universe/` | Gitea `git.dogfather-universe.com/DogFatherGit/dogfather-universe`, Zweig `main` |
|
||
| `www.dogfather-universe.com` | dasselbe (Caddy nimmt beide Namen) | dasselbe |
|
||
| `dogfather-universe.dogfather1608.workers.dev` | Cloudflare Worker (Altbestand) | `npx wrangler deploy` |
|
||
|
||
Erkennungsmerkmal im Zweifel: `curl -sI https://dogfather-universe.com/ | grep -i via`
|
||
→ zeigt `via: 1.1 Caddy`, also Netcup. Käme die Seite von Cloudflare, stünde da kein Caddy.
|
||
|
||
## So wird eine Änderung wirklich live (der einzige gültige Weg)
|
||
|
||
```bash
|
||
cd ~/Documents/Obelix/DogiHompage
|
||
# 1. Änderung committen
|
||
git add <dateien> && git commit
|
||
# 2. In die Ablage schieben (Gitea ist die Quelle der Wahrheit)
|
||
git push gitea master:main
|
||
# 3. Auf dem Server holen
|
||
ssh dogfather-server "cd /home/dogiweb/dogfather-universe && git pull --ff-only origin main"
|
||
```
|
||
|
||
Statische Dateien (HTML/CSS/JS/Bilder) sind damit **sofort** live — der Express-Dienst liefert
|
||
das Verzeichnis direkt aus, ein Neustart ist dafür **nicht** nötig.
|
||
|
||
## ⚠️ ES GIBT ZWEI CHECKOUTS AUF DEM SERVER, NICHT EINEN
|
||
|
||
Am 22.08.2026 beim Ausrollen des Webdesign-Bereichs gefunden — diese Datei
|
||
beschrieb vorher nur den ersten und war damit unvollständig:
|
||
|
||
| Dienst | Checkout | Liefert |
|
||
|---|---|---|
|
||
| `dogiweb.service` (Port 4100) | `/home/dogiweb/dogfather-universe/` | die öffentliche Website + `server/` |
|
||
| `dogiintern.service` (Port 4200) | `/home/dogiintern/dogfather-universe/` | die API unter `postfach.dogfather-universe.com` + `server-internal/` |
|
||
|
||
**Ein `git pull` in `/home/dogiweb` ändert an `server-internal/` also gar nichts.**
|
||
Wer nur dort zieht und danach `dogiintern.service` neu startet, startet den
|
||
Dienst mit unverändertem Code neu und wundert sich, warum nichts passiert.
|
||
|
||
`claudian` hat auf `/home/dogiintern/` **keinen Zugriff** (weder lesend noch
|
||
über den begrenzten sudo). Änderungen an `server-internal/` muss deshalb
|
||
Filipe selbst ausrollen:
|
||
|
||
```bash
|
||
sudo -u dogiintern git -C /home/dogiintern/dogfather-universe pull --ff-only origin main
|
||
sudo systemctl restart dogiintern.service
|
||
```
|
||
|
||
## Server-Code geändert? Dann ist ein Neustart PFLICHT
|
||
|
||
Statische Dateien sind nach dem Pull sofort live. Server-Code **nicht** —
|
||
der läuft weiter mit dem alten Stand, bis der Dienst neu startet.
|
||
|
||
```bash
|
||
ssh dogfather-server "sudo systemctl restart dogiweb.service" # nach Änderungen in server/
|
||
ssh dogfather-server "sudo systemctl restart dogiintern.service" # nach Änderungen in server-internal/
|
||
```
|
||
|
||
**Warum das hier besonders steht (Vorfall 22.08.2026):** Nach dem Pull des
|
||
Webdesign-Bereichs war `/webdesign/` für einige Minuten **ohne Zugangsschutz
|
||
öffentlich erreichbar** (HTTP 200 statt der Umleitung zur Zugangswand). Die
|
||
HTML-Dateien waren durch den Pull sofort da — die Schranke in
|
||
`server/webdesign-gate.js` lief aber erst nach dem Neustart von
|
||
`dogiweb.service`. Bei einem Bereich, der ausdrücklich nicht öffentlich sein
|
||
soll, ist genau dieses Zeitfenster der gefährliche Teil eines Deploys.
|
||
|
||
Merksatz: **Erst neu starten, dann „ist live" melden** — und danach mit
|
||
`curl -I` prüfen, dass die Schranke wirklich greift:
|
||
|
||
```bash
|
||
curl -sI https://dogfather-universe.com/webdesign/ | grep -iE "^location|x-robots-tag"
|
||
# erwartet: location: /webdesign/zugang.html?next=... und x-robots-tag: noindex, ...
|
||
```
|
||
|
||
**Achtung bei Zweig-Namen:** lokal heißt der Zweig `master`, auf dem Server und in Gitea `main`.
|
||
Deshalb `master:main` beim Push. Ein blankes `git push` schiebt sonst nach `gitea/master` —
|
||
einen alten, abgehängten Zweig, den niemand ausliefert.
|
||
|
||
## Pflicht-Prüfung nach JEDEM Deploy
|
||
|
||
Nicht auf die Erfolgsmeldung des Deploy-Befehls verlassen, sondern **die echte Domain fragen**:
|
||
|
||
```bash
|
||
# Kommt meine Änderung wirklich auf der Seite an, die Filipe benutzt?
|
||
curl -s https://dogfather-universe.com/assets/css/main.css | grep "<mein Merkmal>"
|
||
```
|
||
|
||
Erst wenn das anschlägt, gilt eine Änderung als erledigt. Bei optischen Änderungen zusätzlich
|
||
mit einem echten Browser im Handy-Format nachsehen (Playwright, Viewport 390×844) und einen
|
||
Screenshot machen — Text im Quelltext beweist noch nicht, dass es auch richtig aussieht.
|
||
|
||
## Der Cloudflare-Worker (Altbestand)
|
||
|
||
Bleibt vorerst bestehen, liefert aber nur noch `…workers.dev` aus. Ein Deploy dorthin ändert
|
||
an der echten Seite nichts. Der Versuch, die Domain per `wrangler` wieder anzubinden, schlägt
|
||
bewusst fehl:
|
||
|
||
```
|
||
Hostname 'dogfather-universe.com' already has externally managed DNS records
|
||
```
|
||
|
||
Das ist **kein Fehler, den man beheben sollte** — es ist die Schutzwirkung davon, dass die
|
||
Domain jetzt auf Netcup zeigt. `routes` mit `custom_domain = true` steht deshalb nur noch aus
|
||
historischen Gründen in `wrangler.toml`.
|
||
|
||
Der Bewerbungs-Postfach-Worker ist davon unabhängig und läuft weiter auf Cloudflare:
|
||
`https://dogfather-universe-postfach.dogfather1608.workers.dev` (`API_BASE_URL` in
|
||
`assets/js/forms.js`, `index.html`, `postfach.html`).
|
||
|
||
## Git-Ablage
|
||
|
||
- **Quelle der Wahrheit:** Gitea, `git.dogfather-universe.com/DogFatherGit/dogfather-universe`,
|
||
Zweig `main` (auf dem eigenen Server, kostenlos, in eigener Hand).
|
||
- Lokal heißt das Fernziel `gitea`, der Zweig `master`.
|
||
- Auf dem Server heißt das Fernziel `origin`, der Zweig `main`.
|
||
- `gitea/master` ist ein **alter, abgehängter Zweig** (Stand 44086b0) — nicht benutzen.
|
||
- Sicherungszweig `server-stand-vor-abgleich-22-08-2026` auf dem Server: der Stand, bevor die
|
||
beiden Fassungen am 22.08.2026 zusammengeführt wurden. Kann irgendwann weg, kostet nichts.
|
||
|
||
**Nie direkt auf dem Server Dateien bearbeiten, ohne sie danach in Gitea nachzutragen.** Genau
|
||
dadurch waren am 22.08.2026 zwei Reparaturen (Autofokus in `gate.html`, abgeschnittene
|
||
Öffnen-Knöpfe in `verwaltung.html`) nur auf dem Server vorhanden und wären beim nächsten
|
||
Deploy vom Rechner aus überschrieben worden.
|
||
|
||
## Offene Punkte
|
||
|
||
- Mehrere Hintergrundbilder liegen **nur auf dem Server und auf Filipes Rechner**, aber in
|
||
keiner Git-Ablage (`bg-bewerben-modi*.jpg`, `bg-bewerben-scout*.jpg`, `bg-links-seite*.jpg`,
|
||
`bg-medien-casper*.jpg`, `bg-medien-hasidog*.jpg`, `bg-supporter*.jpg`, `bg-modis.jpg`,
|
||
Ordner `assets/img/stimmen-avatare/`). Die Seiten `bewerben-modi.html`, `links.html`,
|
||
`medien-casper.html`, `supporter.html` u.a. benutzen sie live. Geht der Server verloren,
|
||
fehlen sie. Sie sind bewusst **nicht** in `.gitignore` — sie wurden schlicht nie hinzugefügt.
|
||
- CORS im Postfach-Worker weiterhin offen (`"*"`), siehe TODO in
|
||
`cloudflare-worker/src/lib/http.js`.
|
||
|
||
## Alternative Hosting-Optionen (nur als Notfall-Plan)
|
||
|
||
Die Seite ist reines statisches HTML/CSS/JS und läuft überall — `netlify.toml` und `.nojekyll`
|
||
liegen bereit. Relevant nur, falls der Netcup-Server einmal ausfällt.
|