Jetzt mit KI-gestütztem Page Building über den MCP-Server

Entwurfsvorschau

Die Delivery-API liefert nur veröffentlichte Inhalte. Drei Mechanismen lassen die richtigen Leute Entwürfe sehen, ohne die Tür für alle zu öffnen.

Öffentliche Reads liefern veröffentlichte Inhalte und sonst nichts. Das ist eine Eigenschaft der API, kein Filter, an den deine App denken muss - deshalb kann eine unfertige Seite nicht versehentlich durchsickern.

Es heißt auch: Einen Entwurf zu sehen, verlangt einen bewussten Nachweis, wer du bist. Es gibt drei Wege, für drei verschiedene Personen.

1. Entwurfs-Cookie - für Reviewer

Wer eine Änderung gegenliest, will den Entwurf unter der echten URL sehen, ohne Editor davor. Die Route /api/draft setzt ein Cookie, das die öffentliche Route auf Entwurfsinhalte umschaltet:

/api/draft?secret=...&slug=/pricing

Die Route prüft das Secret gegen CMSSY_DRAFT_SECRET, setzt das Cookie und leitet auf den Slug um. Ab da sieht dieser Browser Entwürfe, bis das Cookie gelöscht wird. Alle anderen sehen weiter die veröffentlichte Site.

2. Dev-Entwurfs-Overlay - für dich beim Entwickeln

Hänge ?cmssyDev=1 an eine beliebige URL, um dein persönliches Entwurfs-Overlay zu rendern:

http://localhost:3000/pricing?cmssyDev=1

Das ist nicht der geteilte Entwurf, sondern deine eigene Arbeitskopie - und genau das macht sie sicher zum Ausprobieren eines noch nicht deployten Blocks: bei niemand anderem ändert sich die Vorschau.

Es braucht CMSSY_API_TOKEN und ist für die Entwicklung gedacht. Ohne das Flag bekommst du veröffentlichte Inhalte, ein gesetztes Token ändert also nichts an dem, was Besucher sehen.

3. Edit-Modus - für den Editor

Der Editor-Iframe sendet cmssyEdit=1 plus ein passendes cmssySecret. Die Middleware verifiziert das Paar und schreibt auf /cmssy-edit um, das Entwurfsinhalte liefert und die Edit-Bridge mountet.

Ein unverifiziertes ?cmssyEdit=1 bewirkt nichts. Genau das prüft der Smoke-Test, denn eine Vorschau-Route, die einem Query-String vertraut, ist ein öffentliches Entwurfsleck mit Zwischenschritten - siehe Testen.

Die Secrets

  • CMSSY_DRAFT_SECRET - schützt die Entwurfsvorschau-Bridge und den Edit-Modus. Ein beliebiger Zufallsstring; er muss nur zu dem passen, was der Admin sendet.
  • CMSSY_API_TOKEN - nötig für das ?cmssyDev=1-Overlay, denn den persönlichen Entwurf einer Person zu lesen ist eine authentifizierte Operation.
  • CMSSY_REVALIDATE_SECRET - schützt den /api/revalidate-Webhook, ein anderes Thema: Er invalidiert den Cache nach dem Veröffentlichen und legt keine Entwürfe offen.

Setze CMSSY_ADMIN_URL, wenn du den Admin selbst hostest; das Entwurfs-Banner nutzt sie für den Link „Im Editor öffnen“.

Veröffentlichen und der Cache

Veröffentlichen ist kein Deploy - und es erscheint auch nicht automatisch. Deine öffentliche Route cached nach ihrem eigenen revalidate-Wert, eine frisch veröffentlichte Seite kann also weiter die alte Kopie ausliefern, bis dieses Fenster abläuft.

Der /api/revalidate-Webhook schließt die Lücke: cmssy ruft ihn beim Veröffentlichen auf, die Route invalidiert die betroffenen Pfade. Wenn eine Änderung veröffentlicht ist und die Site trotzdem die alte Version zeigt, prüfe diesen Webhook, bevor du das CMS verdächtigst.

Nächste Schritte

  • Routen und Seiten - die drei Request-Formen, die diese Mechanismen bedienen.
  • Testen - beweisen, dass der Edit-Modus unverifizierte Anfragen weiter ablehnt.
  • API-Tokens - CMSSY_API_TOKEN erstellen und einschränken.