Anmelden

WordPress-Layouts mit Structure Contracts steuern

Ein Structure Contract macht aus dem vorgesehenen Gutenberg-Layout eines Blueprints ein serverseitig erzwungenes Dokumentmodell. Ein Agent kann damit Felder wie hero.title oder body.additional ansprechen, ohne fragile Blockpfade oder die Berechtigung zum Neuaufbau der Seite zu erhalten.

Editor-Sperren verbessern die Bedienung, sind aber keine Sicherheitsgrenze. Composer prüft den Vertrag bei REST-, nativen Editor- und MCP-Schreibvorgängen erneut. Rohes Block-Markup kann ihn nicht umgehen.

Eigentumsmodell​

Jeder deklarierte Knoten hat genau einen Eigentümer:

  • Blueprint-eigene Struktur schützt erforderliche Container, Reihenfolge, Blocktyp und Darstellung.
  • Instanzeigener Inhalt darf pro Beitrag variieren und wird über eine stabile semantische ID bearbeitet.
  • Benutzereigener Slot-Inhalt ermöglicht kontrollierte redaktionelle Freiheit innerhalb einer Allowlist sowie minimaler und maximaler Kardinalität.

So bleibt das Design erhalten, ohne jedes Wort einzufrieren.

Stabile semantische IDs​

Eine semantische ID ist dauerhafte Policy und kein Array-Index. Verwenden Sie Namen, die die Rolle beschreiben:

hero
hero.title
body
body.text
body.additional

Eine Umbenennung ist eine Contract-Migration. Theme-Version, Datenbank-ID, Umgebungsname und aktuelle Blockposition gehören nicht in die ID.

Erweiterungsslots​

Ein Slot definiert semantische ID und Elternknoten, erlaubte direkte Blocktypen, minimale und maximale Kinder, Pflichtstatus sowie Lock- und Appender-Verhalten.

Composer bietet semantisches Einfügen, Aktualisieren, Verschieben und Entfernen. Jeder eingefügte Baum erhält eine stabile benutzereigene Identität. Nach jeder Änderung wird das gesamte Dokument validiert; Kardinalitäts- und Allowlist- Fehler werden atomar abgewiesen.

Synchronisierte Struktur-Patterns​

Wiederverwendbare Struktur liegt in einem veröffentlichten, synchronisierten WordPress-wp_block-Pattern. Der Beitrag enthält eine native gesperrte core/block-Referenz statt einer Kopie.

Für deklarierte Instanzfelder dienen native Pattern Overrides. Composer speichert Slot-Kinder an der Pattern-Instanz des Beitrags, nicht im gemeinsamen wp_block. Eine Instanz kann daher nicht alle Seiten verändern.

Der Site Contract identifiziert Pattern, lokalen wp_block-Datensatz, Version, Override-Bindings und kompatiblen Structure Contract. Theme & providers meldet eine fehlende Quelle nur, wenn dieser Quellentyp relevant und tatsächlich nicht verfügbar ist.

Native WordPress-Erstellung​

Der Site Contract steuert Add New pro Post-Typ:

  • off: native Erstellung bleibt unverwaltet;
  • optional: ein Administrator kann einen kompatiblen Blueprint auswählen;
  • required: ein neues Dokument muss aus dem Standard-Blueprint entstehen.

Das native Dokument erhält denselben Blueprint, synchronisierte Patterns, Structure Contract, Baseline, Sprache und serverseitigen Schreibschutz. Dadurch wird es nicht automatisch Eigentum des Agents.

Pattern-Evolution und Abstimmung​

Eine kompatible Revision darf geschützte Darstellung ändern, wenn alle erforderlichen semantischen Felder und Slots erhalten bleiben. Pattern Overrides und benutzereigene Slot-Kinder bleiben an ihrer Instanz.

Entfernt oder verändert eine Revision ein erforderliches Binding, meldet Composer explizit „ungültig“ oder „Abstimmung erforderlich“. Gespeicherte Beiträge werden nicht still umgeschrieben und Inhalte nicht verworfen.

Bei versionierten Contract-Änderungen:

  1. aktiven Config Set klonen;
  2. Nachfolger für Structure Contract und Blueprint registrieren;
  3. exakte Quell-Ziel-Migration definieren;
  4. Ergebnis ohne Schreibzugriff vorab anzeigen;
  5. automatische und prüfpflichtige Elemente klassifizieren;
  6. revisionsgebundene Änderungsvorschläge erstellen;
  7. akzeptierte Vorschläge durch einen Menschen zusammenführen lassen.

Die Bulk-Planung ist begrenzt und die Vorschlagserstellung explizit. Migrationen führen nie zu automatischer Massenveröffentlichung.

Verantwortung von Theme und Providern​

Das Theme besitzt Templates, synchronisierte Patterns, Markup, Styles und theme.json-Tokens. Ein Provider besitzt Schema und Materializer seiner Komponenten. Composer besitzt semantischen Vertrag, Validierung, gesteuerte Mutation, Abstimmungszustand, Vorschläge und Audit-Trail.

AI Kit Knowledge Base Sections können semantische Container für gesteuerte native Gutenberg- oder Agent-Canvas-Nachfahren sein. Feature und Doc Search behalten ihre strengere Kindvalidierung.

Abnahmecheckliste​

  • Jede semantische ID ist stabil und eindeutig.
  • Jedes Pflichtfeld und jeder Slot wird nach Pattern-Auflösung genau einmal gefunden.
  • Jeder erlaubte Block ist registriert und validiert.
  • Slot-Grenzen entsprechen der beabsichtigten redaktionellen Freiheit.
  • Pattern Overrides decken alle Instanzfelder ab.
  • Instanz-Slots ändern den gemeinsamen wp_block nicht.
  • Add New, MCP-Bearbeitung, Vorschau, Vorschlag und Abstimmung sind mit dem aktiven Theme getestet.
  • Änderungen an veröffentlichten Inhalten bleiben vorschlagsbasiert und menschlich freigegeben.

Weiter: Konfiguration und Lebenszyklus, Theme-Integration und MCP-Zugriff und OAuth.