Concepts

Peacock CMS hat ein bewusst kleines Vokabular. Wer Storyblok kennt, findet die meisten Begriffe wieder.

Tenant

Eine Organisation oder ein Kunde. Self-Hosting hat meistens einen Tenant; die gehostete SaaS hat viele. Tenants sind voneinander isoliert (Multi-Tenancy via Spatie-Package).

Space

Eine Website pro Space. Beispiele: oblatinnen-site, ewm-website, peacock-marketing.

Jeder Space hat:

• Eigene Stories (Inhalt) und Component-Blueprints (Schema).
• Eigene Locales (Sprachen).
• Eigene API-Tokens — Public-Read (für Frontends/CDN-Calls) und Management (für Admin/MCP).
• Eigene AI-Approval-Policy (auto / review / read_only).

Ein Tenant kann beliebig viele Spaces haben. Mehrere Marken / Produkte / Sprach-Subdomains → mehrere Spaces.

Component Blueprint

Definiert das Schema eines wiederverwendbaren Content-Bausteins.

{
  "name": "hero",
  "label": "Hero",
  "group": "Content",
  "schema": {
    "type": "object",
    "properties": {
      "_component": { "const": "hero" },
      "headline": { "type": "string", "minLength": 1, "maxLength": 200 },
      "lead":     { "type": "string", "maxLength": 500 },
      "cta_url":  { "type": "string", "pattern": "^(https?://|/|#|mailto:|tel:)" },
      "cta_label": { "type": "string" }
    },
    "required": ["_component", "headline"],
    "additionalProperties": false
  }
}

Schema-Validierung läuft serverseitig (opis/json-schema) auf jedem PUT /v1/stories. Bricht eine Story das Schema, gibt es 422 zurück mit den exakten Pfaden, die fehlschlagen — das Admin-UI zeigt sie als Validierungs-Errors.

Pre-built Library: Jeder neue Space bekommt automatisch 8 starter-Blueprints (Hero, RichText, TextImage, Gallery, FAQ, Pricing, CTA, Quote) via App\Services\BlueprintLibrary::seed(). Eigene Blueprints fügst du per Admin oder API hinzu.

Story

Eine einzelne Page / Entry. Bäumchen-organisiert via parent_id, mit materialisiertem full_path für O(1)-Lookups.

{
  "uuid": "01HF...",
  "slug": "about",
  "full_path": "/marketing/about",
  "parent_id": 42,
  "lang": "de",
  "status": "published",
  "content": {
    "_component": "page",
    "headline": "Über uns",
    "body": [
      { "_component": "hero", "headline": "Hallo", ... },
      { "_component": "faq", "items": [...] }
    ]
  },
  "version": 7,
  "published_version_id": 6
}

Speichern erzeugt immer eine neue StoryVersion-Zeile — kein Datenverlust durch Mehrfach-Edits. published_version_id zeigt auf die Version, die der CDN-Endpoint ausliefert.

Version

Jede Save-Aktion in der Admin (oder via API) wird zu einer neuen Version. Versionen haben:

• version_no — monoton steigender Zähler pro Story
• content — der vollständige JSON-Snapshot
• message — optionale Notiz (z.B. "Restored from v3")
• created_by_token_id — Audit-Spur

Diff- und Restore-Operationen arbeiten gegen diese Tabelle — keine Magie, kein CRDT, keine Operational Transformations.

Locale

Eine Sprache pro Space. en-GB, de-AT, es-ES, pt-BR etc.

Pro Locale gibt es:

• Eigene Stories (eigene full_path)
• Eigene published_content pro Story
• Fallback-Resolution: wenn de-AT fehlt, fällt CDN auf de zurück, dann auf die Default-Locale des Space

Lies mehr unter Multi-Language.

Asset

Medien-Datei (Image, Video, PDF). S3-kompatibel gespeichert mit Spatie MediaLibrary + Glide für on-the-fly Bildverarbeitung. Hat:

• alt_text (kann AI-generated sein, siehe AI Co-Pilot)
• focal_point für Smart-Cropping
• metadata für EXIF/IPTC

API-Token

Pro Space gibt es zwei Token-Typen:

• Public Read — read-only auf den CDN-Endpoint, harmlos zu cachen, geht ins Browser-Bundle deiner Frontend-App.
• Management — Vollzugriff, gehört in Server-Env-Vars (PHP config(), Node process.env).

Tokens sind Sanctum-PATs mit polymorpher tokenable (Space, nicht User) — kontrolliert ablaufen, fein-granular abilities.

AI Job

Audit-Spur jeder AI-Mutation. Jede peacock init-Translation, jede MCP-Tool-Aktion, jeder SEO-Generate-Click landet hier mit:

• action ("translate_field", "generate_seo_meta", ...)
• model ("claude-3-7-sonnet")
• total_tokens
• approval_status (pending, approved, rejected, auto_applied)
• proposed_patch (optional JSON, falls Review-Modus aktiv ist)

Im review-Modus muss ein Mensch via Admin-Audit-Log approven; im auto-Modus läuft die Mutation direkt durch und der Audit-Eintrag dokumentiert nachträglich, was passiert ist. Read-only-Spaces erlauben gar keine AI-Mutationen.

Workflow Stage

Anpassbare Approval-Pipeline pro Space. Default: Draft → Review → Approved → Published. Stories tragen workflow_stage_id und durchlaufen die Stages via POST /transition.

Webhook

Event-Hooks für externe Systeme. Peacock feuert:

• story.published (HMAC-signed)
• asset.uploaded
• story.transitioned

Empfänger verifizieren die HMAC-Signatur (Konstant-Zeit-Vergleich!) und reagieren — z.B. Cache-Invalidierung auf dem Frontend-CDN.

Component Group

Optionales Sortierungs-Tag auf Blueprints (group: "Content", "Lists", "Conversion"). Der Admin-Block-Picker sortiert die Pre-built Library nach diesen Gruppen — Editoren finden "FAQ" sofort unter "Lists".

Zusammenhänge

Tenant
└─ Space (multi)
   ├─ Story (multi, tree)
   │  └─ StoryVersion (multi per Story)
   ├─ Component Blueprint (multi)
   ├─ Locale (multi)
   ├─ Asset (multi)
   ├─ API Token (multi)
   ├─ Webhook (multi)
   ├─ Workflow Stage (multi)
   ├─ AI Job (multi)
   └─ Agent Schedule (multi)