Page-Cloning

Feature-Idee aus Theme-Strategie-Brainstorm 2026-04-28. Korrektur: nicht nur Demo→Tenant, sondern generisches Cloning fuer alle Pages.

Bedarf

Pages-Cloning soll universell funktionieren:

  • Demo-Pages (= normale Pages mit tenant_id = NULL, optional theme_id-verknuepft) klonen → Tenant-Page
  • Tenant-Page klonen → andere Tenant-Page (gleicher Tenant: Variation; cross-Tenant: Sysadmin-Tool)
  • Tenant-Page klonen → andere Page im selben Tenant (z.B. Standort-Klone)

Kern-Mechanik

Cloning = Kopie von:

  1. Page-Stammdaten (Slug bekommt Suffix oder wird neu vergeben; Status = draft)
  2. RenderContext-Hierarchie (Page → Section → ContentSlot rekursiv)
  3. TemplateBindings (Slot → Component + Variant pro Slot)
  4. BlockContent (Global + Unit-Overrides)

Daraus folgt automatisch das Rendering — keine spezielle Demo-Page-Tabelle, kein theme-spezifischer Code.

Datenmodell-Implikation

  • page.theme_id INT NULL — nur fuer Demo-Pages eines Themes; bei Tenant-Pages immer NULL
  • Bestehende page.tenant_id schon NULL-able fuer system-weite Pages
  • Demo-Page = tenant_id IS NULL AND theme_id IS NOT NULL

Keine separate theme_demo_page-Tabelle.

Was NICHT kopiert wird

  • Live-Status (geklonte Seite startet als draft)
  • Section-Drafts der Quell-Page (nur publishierter Stand)
  • Tenant-Bindings, RBAC-Settings (Ziel-Tenant pflegt das selbst)
  • Asset-Files: bleiben referenziert (Bilder werden nicht dupliziert); bei cross-Tenant Asset-Re-Referenzierung pruefen

Ziel-Auswahl-UI

Cloning braucht UI an mehreren Stellen:

  • Theme-Browse-View — pro Demo-Page „Klonen”-Button (Onboarding-Flow)
  • Tenants-Overview (Sysadmin) — Cross-Tenant-Klone
  • Site-Editor — innerhalb eines Tenants Page duplizieren

Aufwand-Schaetzung (grob)

  • Backend-Service PageCloneService::cloneTo(int $sourcePageId, int $targetTenantId, array $opts): int — M (1-2 Tage)
  • UI-Buttons + Flow — M (zusaetzlich 1 Tag)
  • Cross-Tenant-Permissions + Asset-Re-Referenzierung — wenn benoetigt: zusaetzlich 1-2 Tage

Zusammenhaenge