feat: der Dienst heisst media.d4rkst3r.de -- beide Namen liefern weiter aus

PUBLIC_URL umgestellt. FILES_HOST ist leer, der Dienst achtet also gar nicht
auf den Hostnamen, und in NPM stehen beide auf DEMSELBEN Host -- die drei
^~-Bloecke gelten damit fuer beide. Nachgemessen: unter beiden Namen health 200
und dasselbe Bild, bytegleich.

Nachgezogen:

    7 Stellen in den Ressourcen   d4rk_phone/config.lua (2)
                                  d4rk_photostudio/config.upload.lua
                                  d4rk_photostudio/config.upload.example.lua (2)
                                  d4rk_photostudio/settings.json (2)
    2 Watchdog-Eintraege im Bot   inklusive Anzeigename
   16 Stellen in Doku/Werkzeugen  README, docs/API.md, Home.md,
                                  npm-advanced.conf, proxy-pruefen.ps1,
                                  uebernehmen.ps1, .env.example

Die Freigabe-Links zeigen von selbst auf den neuen Namen -- sie werden aus
PUBLIC_URL gebaut und stehen nirgends gespeichert. Die alten funktionieren
weiter.

DIE ROADMAP BEHAELT DEN ALTEN NAMEN, an sechzehn Stellen und mit Absicht: dort
steht die Geschichte, warum er ueberhaupt "fivemanage" hiess. Sie zu ersetzen
machte aus einer Begruendung Unsinn.

ZWEI DINGE, DIE DABEI AUFFIELEN.

Cloudflare stand vor dem neuen Namen und brach die WebP-Auslieferung: der
Cache-Schluessel kennt Accept nicht, also bekam ein Aufrufer OHNE
"Accept: image/webp" die WebP-Fassung aus dem Zwischenspeicher -- unsere
eigenen Bytes unter einem .png-Namen. Nach dem Umstellen auf DNS-only gemessen
und in Ordnung: ohne Accept image/png 12295 B, mit Accept image/webp 2270 B,
Server: openresty, vary: Accept, dreimal hintereinander stabil.

Und der Lua-Syntaxtest schlug bei d4rk_phone/config.lua fehl -- an Zeile 93,
`customModel = \`prop_player_phone_02\``. Das ist kein Schaden, sondern eine
CfxLua-Erweiterung: Backticks sind dort ein joaat-Hash und in Standard-Lua 5.4
ein Syntaxfehler. 85 davon stecken in der Datei. luac -p taugt fuer
CfxLua-Dateien also nicht; geprueft wurde stattdessen, dass genau die zwei
URL-Zeilen anders sind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-12 01:02:28 +02:00
co-authored by Claude Opus 5
parent 72fd330ae6
commit 463a821199
8 changed files with 51 additions and 24 deletions
+35 -8
View File
@@ -960,7 +960,27 @@ einfügen.** Ein neuer Host bringt seine eigene `assets.conf` mit.
**3. Sagen.** Dann setze ich `PUBLIC_URL` um und ziehe Dokumentation, Fotostudio,
Handy und die Watchdog-Einträge nach.
#### ⚠️ DNS und NPM stehen — aber der Name hängt hinter Cloudflare
#### ✅ Umgestellt am 12.08.2026
`PUBLIC_URL=https://media.d4rkst3r.de`. **Beide Namen liefern weiter aus**
`FILES_HOST` ist leer, der Dienst achtet gar nicht auf den Hostnamen, und in
NPM stehen beide auf demselben Host. Nachgemessen: unter beiden Namen `health
200` und dasselbe Bild.
Nachgezogen: **7 Stellen** in den Ressourcen (`d4rk_phone/config.lua` ×2,
`config.upload.lua`, `config.upload.example.lua` ×2, `settings.json` ×2),
**2 Watchdog-Einträge** im Bot, **16 Stellen** in Dokumentation und Werkzeugen.
Die Freigabe-Links zeigen von selbst auf den neuen Namen — sie werden aus
`PUBLIC_URL` gebaut — und die alten funktionieren weiter.
> **Der Lua-Syntaxtest schlug bei `d4rk_phone/config.lua` fehl**, und zwar an
> Zeile 93: `` customModel = `prop_player_phone_02` ``. Das ist kein Schaden,
> sondern eine **CfxLua-Erweiterung** — Backticks sind dort ein joaat-Hash und
> in Standard-Lua 5.4 ein Syntaxfehler. 85 davon stecken in der Datei. `luac -p`
> taugt für CfxLua-Dateien also nicht; geprüft wurde stattdessen, dass genau die
> zwei URL-Zeilen anders sind.
#### ⚠️ Und die Falle auf dem Weg dorthin: Cloudflare
Am 12.08.2026 eingerichtet. NPM ist dabei sogar besser gelöst als vorgeschlagen:
**beide Namen auf demselben Host** (`server_name fivemanage.d4rkst3r.de
@@ -987,14 +1007,21 @@ Cloudflare variiert standardmäßig nur über `Accept-Encoding`.
Für ein Lua-Skript heißt das: `items/foo.png` liefert WebP-Bytes unter einem
`.png`-Namen, und das fällt erst auf, wenn irgendwo ein Bild nicht lädt.
**Deshalb ist `PUBLIC_URL` noch nicht umgestellt.** Zwei Wege heraus:
**Gelöst durch die graue Wolke** — Cloudflare-Proxy aus, DNS-only, wie bei
`fivemanage`. Danach gemessen, dieselben Dateien:
1. **Graue Wolke** für `media` — Cloudflare-Proxy aus, DNS-only, wie bei
`fivemanage`. Der Ursprung ist ohnehin nicht verborgen (`fivemanage` zeigt
direkt darauf), Cloudflare bringt hier also nichts, was den Bruch aufwöge.
2. Cloudflare behalten und dort eine **Cache Rule** anlegen, die `/f/*` und
`/t/*` vom Zwischenspeicher ausnimmt. Funktioniert, ist aber eine dritte
Stelle, an der dieselbe Regel gepflegt werden will.
```
media (grau) ohne Accept -> image/png 12295 B
mit Accept -> image/webp 2270 B
Server: openresty · vary: Accept · dreimal hintereinander stabil
Bytes identisch mit dem alten Namen (sha256 stimmt überein)
```
**Was das Umstellen der URLs in den Skripten NICHT gelöst hätte:** das Problem
saß am Host, nicht am Aufrufer. Hätten alle Skripte auf `media` gezeigt und
`media` wäre orange geblieben, bekämen *alle* die falschen Bytes — die
Umstellung hätte es verteilt statt behoben. Wer Cloudflare behalten will,
braucht dort eine Cache Rule, die `/f/*` und `/t/*` ausnimmt.
Gegenprüfen lässt sich beides mit dem, was schon da ist: