ostrelle
Menü

OSTRELLE · LERNEN · MIT ÜBUNGEN

3. Über den echten Operator rendern

Du importierst das Manifest und prüfst die wirkliche Themeausgabe. Mit konkreten Schritten, eigener Übung, Musterlösung und Erfolgskontrolle.

Ostrelle für Entwickler · Lektion 3 von 4 · Quellstand 3. November 2026

Das lernst du

Du importierst das Manifest und prüfst die wirkliche Themeausgabe.

product_site ist ein geschlossener SQLiteoperator für diese Produktwebsite. Er akzeptiert die ausdrückliche lokale Produkthostadresse, prüft das ganze Manifest vor dem Datenbanköffnen und verweigert fremde unmarkierte Datenverzeichnisse. Er ist kein allgemeiner Provisionierungsersatz für beliebige Kunden.

Templates, Teile und Assets liegen im vorhandenen Theme-Paket. Vererbungsziele gehören in der Sandbox unter parts/. Der ThemeCatalog wird beim Start geladen; ein Dateiedit ist nicht automatisch ein laufender Hotreload. Für eine Themeänderung musst du deshalb den isolierten Prozess mit dem neuen Paket starten.

Schritt für Schritt

  1. Baue wpnext-server und das Beispiel product_site aus deinem Stand. Setze einen eigenen Cargo-Targetpfad und beachte im betreuten Workspace den globalen Buildlock.
  2. Erzeuge ein neues privates temporäres Datenverzeichnis und importiere das aktuelle Produktmanifest mit dem unten gezeigten Operator. Verwende ausschließlich ostrelle.localhost.
  3. Starte den Server mit demselben Datenverzeichnis, dem Produkt-Themeordner und freien Loopbackports. Bei Umgebungen ohne .localhost-Auflösung lege den Hostheader beziehungsweise eine lokale Namensauflösung kontrolliert fest.
  4. Lade /lernprobe/ mit dem Host ostrelle.localhost. Prüfe Titel, H1, Absatz, Linkziel, Statuscode und CSP.
  5. Ändere einen Satz und erzeuge das Manifest erneut. Beende den Testserver, aktualisiere nur deine markierte Produktinstanz mit WPNEXT_PRODUCT_UPDATE=1 und starte wieder. Prüfe die geänderte Antwort.
cargo build --locked -p wpnext-server --bin wpnext-server --example product_site
product_dir=$(mktemp -d "${TMPDIR:-/tmp}/ostrelle-produktkurs.XXXXXX")
chmod 700 "$product_dir"
WPNEXT_STORE_DATA_DIR="$product_dir" \
WPNEXT_PRODUCT_HOST=ostrelle.localhost \
WPNEXT_PRODUCT_CONTENT="$PWD/website/content/pages.json" \
  "${CARGO_TARGET_DIR:-target}/debug/examples/product_site"
WPNEXT_STORE_DATA_DIR="$product_dir" \
WPNEXT_RENDER_THEMES_DIR="$PWD/website/themes" \
WPNEXT_RENDER_DEFAULT_THEME_FALLBACK=ostrelle-product \
WPNEXT_SERVER_PUBLIC_BIND=127.0.0.1:18580 \
WPNEXT_SERVER_INTERNAL_BIND=127.0.0.1:18581 \
  "${CARGO_TARGET_DIR:-target}/debug/wpnext-server"
# Zweites Terminal:
curl --resolve ostrelle.localhost:18580:127.0.0.1 \
  http://ostrelle.localhost:18580/lernprobe/

Deine Übung

Belege, dass dein neuer Satz nicht nur im JSON steht, sondern wirklich durch Ostrelle ausgeliefert wird. Welche zusätzliche Prüfung unterscheidet 404 von einer scheinbaren Erfolgsseite?

Musterlösung und Erklärung

Ein tatsächlicher HTTPabruf mit passendem Host liefert 200 und den neuen Satz im Inhalt. Ein absichtlich unbekannter Pfad liefert 404 und keine als Erfolg getarnte Standardseite. Du hast keine eigene statische HTMLnachbildung verwendet.

Falls der Operator abweist, lies die Manifestvalidierung und die Eigentumsmarke. Verwende kein fremdes vorhandenes Verzeichnis als Ausweichziel. Der Operator ist SQLite-only; PG-Übernahme und Restore haben die gesonderten dokumentierten Werkzeuge.

So prüfst du dein Ergebnis

  • Der eigene Satz steht im tatsächlichen HTTPbody.
  • Das Theme wird von demselben Renderer geladen wie andere Produktseiten.
  • Unbekannte Pfade liefern echte 404.

← Vorherige Lektion · Kursübersicht · Nächste Lektion →