Own fixture pod lit_fixture_person (ruling Q1), template and body layout
built through Divi's Theme Builder and Visual Builder UI, brief render with
the template limited to one person (Q5), findings 10-12 in the README.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Exportiert werden nur Posts mit Titel „[Fixture] …“ und die Standardvorlage, wenn sie auf Fixture-Layouts zeigt. Das Skript löscht vorher alle `*.json`/`*.html` in diesem Ordner.
Seit den Etappe-3b-Fixtures (`stage3b/`, 2026-09-27) steht deren Vorlage 2394 ebenfalls in der Live-Liste; ein neuer Export ergäbe ein anderes `theme-builder.json`. Diesen Ordner daher nur auf einer Site ohne die 3b-Fixtures neu exportieren (Ruling B21).
## Aufräumen (lokal)
Die Daten bleiben vorerst zum Ansehen stehen. Zum Entfernen (DDEV, WordPress-Wurzel; IDs vorher mit `manifest.json` abgleichen):
# Divi-5-Fixtures für Etappe 3b (Theme Builder mit Pods)
Echte Daten aus Divi 5.2.1 und Pods 3.3.9.2, erzeugt am 2026-09-27 auf der lokalen DDEV-Site (`https://wordpress.ddev.site:8443`). Vorlage und Body-Layout sind **über die Oberfläche** entstanden: echter Theme-Builder-Editor und der darin geöffnete Visual Builder in einem headless Chrome (per DevTools-Protokoll gesteuert, echte Mausklicks und Tastatureingaben, angemeldet als Administrator). Anders als in `stage3/` wurde kein Inhalt per `setContent` gesetzt und keine TB-Nutzlast nachgebaut: Module, Dynamic Content, Admin-Labels, Titel, Bedingungen und der Aktiv-Schalter kamen aus Divis eigenen Dialogen. Plugin-Code hat nichts geschrieben.
Pfade zu Divi relativ zu `wp-content/themes/Divi/includes/`. Die TB-App ist `builder/frontend-builder/build/theme-builder.js` (minifiziert, dort steht ein Suchbegriff statt einer Zeile).
## Dateien
Aufbau wie `stage3/`: je Post `<rolle>.json` (Post-Zeile, alle Meta roh in Speicherreihenfolge, Terme) und `<rolle>.html` mit `post_content` byte-genau; `manifest.json` (Rolle → ID), `theme-builder.json` (Live-TB-Post mit Vorlagenliste, `et_tb_*`-Optionen, als ungenutzt markierte Posts), dazu `render--person-erika.txt` (sichtbare Ausgabe, siehe Schritt 4).
Nicht exportiert: die Pods-Definition (Pod 2381, Felder 2382–2384), die Revisionen 2392/2393 des Body-Layouts, die Standardvorlage 1065 und der Header 1061 (liegen in `stage3/`).
## Wie die Fixtures entstanden sind
### 1. Pod und Personen (Ruling Q1)
`wp eval-file …/tests/Integration/pods-fixture.php fixture` legt den eigenen Pod `lit_fixture_person` („[Fixture] Personen“, Post-Typ, Speicherung `meta`, öffentlich) mit `role` (Text), `level` (Auswahl `junior|Junior`, `senior|Senior`) und `mentor` (Beziehung auf `lit_fixture_person`, einzeln) an und danach die zwei Personen über `pods()->add()`. Der Aufruf ist wiederholbar (legt nichts doppelt an). `lit_person` (Pod der wp-basis-smoke) bleibt unberührt; `pods-fixture.php delete` löscht nur `lit_person`. Personen haben `post_author` 0, weil WP-CLI ohne Benutzer lief.
`et_builder_enabled_for_post_type('lit_fixture_person')` liefert „divi aus“. Die Divi-Einstellung „Beitragstyp-Integration“ wurde **nicht** geändert (Ruling Q5); der Theme Builder braucht sie nicht, die Bedingung „[Fixture] Personen“ bot er trotzdem an.
Vor dem ersten Live-Speichern gab es keine verwaisten TB-Posts: `_et_template` von 1064 war [1065, 1066], kein Post trug `_et_theme_builder_marked_as_unused` (B5).
### 2. Vorlage im Theme-Builder-Editor (`wp-admin/admin.php?page=et_theme_builder`)
1. „Neue Vorlage hinzufügen“ → „Neue Vorlage erstellen“ → im Dialog „Template-Einstellungen“ unter „[Fixture] Personen“ den Haken „Alle [Fixture] Personen“ → „Vorlage erstellen“. Divi setzt dabei selbst „Globaler Header“ (1061) als Kopfzeile und den Titel „Alle [Fixture] Personen“ (`autogenerated_title` 1); die neue Vorlage ist **aktiv** (`enabled` 1).
2. Hauptinhalt: „Benutzerdefinierten Hauptinhalt erstellen“ → `et_theme_builder_api_create_layout` (`builder/frontend-builder/theme-builder/api.php:12-46`) → 2391, dann `et_theme_builder_api_get_layout_url` (`api.php:116-147`); der Editor öffnet den Visual Builder als Overlay (`iframe#et-fb-app-frame`, `…?et_fb=1&et_tb=1&app_window=1`).
3. Im Visual Builder (Schritt 3), danach „Beenden“.
5. „Änderungen Speichern“ → `et_theme_builder_api_save` mit `live=1` (`api.php:160-273` → `et_theme_builder_store_template`, `builder/frontend-builder/theme-builder/theme-builder.php:1463`). Die neue Vorlage bekam dabei die ID 2394 (die UUID aus dem Editor wurde ersetzt).
### 3. Body-Layout im Visual Builder (2391)
Der leere Abschnitt kam von Divi. Dann über die Oberfläche: grünes „+“ → „Zeile einfügen“ → eine Spalte; Modulsuche „Überschrift“; danach über „Spalte → Elemente → Element hinzufügen“ dreimal „Text“ und einmal „Inhalt posten“ (so heißt `divi/post-content` in der deutschen Modulliste). Je Modul im Einstellungsdialog:
- Überschrift: Knopf „Dynamic Content“ am Feld „Überschrift“ → „Beitrag/Archivtitel“ → „Anwenden“; Meta → Elementbeschriftung „Person Titel“.
- Texte: Knopf „Dynamic Content“ am Feld „Fließtext“ → „Benutzerdefiniertes Feld“ → Auswahl „Benutzerdefiniertes Feld auswählen“ → unter „Standard-Meta-Keys“ `role` bzw. `level` bzw. `mentor` → „Anwenden“; Elementbeschriftung „Person Funktion“/„Person Stufe“/„Person Mentor“. Die Pods-Felder standen in der Liste, eine manuelle Eingabe des Schlüssels war nicht nötig.
- Seiteneinstellungen (Zahnrad → „Seiteneinstellungen“) → Titel „[Fixture 3b] Person Body“; „Speichern“ → `POST divi/v1/sync-to-server` mit `post_status: publish` (wie in `stage3/`).
Beim Text „Person Stufe“ wurde zuerst versehentlich „Beitrag/Archivtitel“ gewählt, dann mit „Reset field“ zurückgesetzt und neu gewählt. Deshalb steht dort `builderVersion`/`module` vor `content`– die Schlüsselreihenfolge spiegelt die Bearbeitungsreihenfolge, der Inhalt ist identisch mit den anderen beiden Texten.
### 4. Darstellung (Ruling Q5, Vorlage kurz aktiv)
Im TB-Editor: Bedingung auf genau eine Person eingeschränkt („Bestimmte [Fixture] Personen“ → nur „[Fixture 3b] Erika Muster“, `singular:post_type:lit_fixture_person:id:2385`), „Template Aktivieren“, „Änderungen Speichern“. Ein Wächter im Browser hätte jedes Live-Speichern abgebrochen, in dem eine aktive Vorlage etwas anderes als genau diese Bedingung trägt; ein Notfall-Skript (`_et_enabled` = 0, Bedingung zurück auf „alle“, Cache leeren) lief im `finally` mit. Dann Seiten abgerufen (`?p=2385`, `?p=2386`, Startseite), sofort „Template Deaktivieren“ + Speichern und die Bedingung wieder auf „Alle [Fixture] Personen“ + Speichern. Die Vorlage war etwa zwei Minuten aktiv.
Geprüft: `_et_enabled` von 2394 = `0`; während der aktiven Zeit enthielten Max (2386) und die Startseite keine `_tb_body`/`_tb_header`-Module; danach enthalten weder Erika noch Max, die Startseite noch die Seite 1053 ein TB-Modul.
`render--person-erika.txt` ist der sichtbare Text der fünf Module aus dem HTML von `?p=2385` (je Zeile „Admin-Label: Text“).
### 5. Befund 10 (Schritt 9)
Tab A: TB-Editor frisch geladen (drei Vorlagen). Im Terminal eine deaktivierte Vorlage „[Fixture 3b] Stale-Test“ (2395) so angehängt wie `DiviThemeBuilder::attach()` (Backup-Option, `add_post_meta(1064, '_et_template', 2395)`, Backup löschen) → Liste [1065, 1066, 2394, 2395]. In Tab A „[Fixture 3b] Person“ umbenannt und zurückbenannt, „Änderungen Speichern“. Danach 2395 und die TB-Entwurfsreste (siehe Befund 11) mit `wp post delete --force` gelöscht; `_et_template` = [1065, 1066, 2394].
## Was echt ist und was nachgebildet wurde
**Echt aus Divi (Oberfläche + Server):** Blockstruktur und Attribute aller Module (auch die Standardattribute beim Einfügen, z. B. `columnStructure`/`flexColumnStructure` der Zeile), die Dynamic-Content-Werte mit ihren `settings`, Admin-Labels, Titel, alle Meta des Body-Layouts und der Vorlage, `_et_template` am TB-Post, die Bedingung, der Aktiv-Schalter.
**Nachgebildet bzw. nicht aus Divi:** nur die Zuordnung der Stale-Test-Vorlage in Befund 10 (nachgebaut nach `DiviThemeBuilder::attach()`) und die Pods-Daten (über die Pods-API, nicht die Pods-Oberfläche). Das Notfall-Skript aus Schritt 4 hat nach Divis Speichern noch einmal `_et_use_on` gelöscht und neu gesetzt (gleicher Wert); das spätere Speichern in Befund 10 hat die Vorlage 2394 wieder über `et_theme_builder_store_template` geschrieben, die exportierten Meta sind also Divis eigene.
## Befunde
**Befund 10 – ein alter TB-Editor entfernt fremd angehängte Vorlagen aus der Liste.** Beobachtet: Nach dem Speichern in Tab A stand 2395 **nicht mehr** in `_et_template` (Liste [1065, 1066, 2394]), und 2395 bekam `_et_theme_builder_marked_as_unused` = `2026-09-27 12:47:02`. Divi hätte den Post nach sieben Tagen beim nächsten TB-Speichern in den Papierkorb gelegt. Ursache im Code: `et_theme_builder_api_save()` löscht beim letzten Teil-Request die komplette Zuordnung (`api.php:233`, `delete_post_meta( $theme_builder_id, '_et_template' )`) und schreibt nur die Vorlagen, die der Editor mitschickt (`api.php:238-240`); der Editor schickt seinen beim Laden übernommenen Stand (`et_theme_builder_bundle.config.templates.live`). Bei `live=1` folgt `et_theme_builder_trash_draft_and_unused_posts()` (`api.php:245-247` → `theme-builder.php:591-678`): alle TB-Vorlagen und -Layouts, die die neue Liste nicht referenziert, werden markiert (`theme-builder.php:646`), markierte Posts älter als sieben Tage in den Papierkorb gelegt (`theme-builder.php:651-676`). Der Editor zeigt die fremde Vorlage nicht an und warnt nicht. Folge für das Plugin: Jede über MCP angehängte Vorlage (und ihre Layouts) geht verloren, sobald jemand einen vorher geöffneten TB-Editor speichert – Divi hebt die Markierung nur wieder auf, wenn die Vorlage erneut in der Liste steht (`theme-builder.php:620-623`).
**Befund 11 – der TB-Entwurf entsteht erst durch Divis Autosave.** Öffnen des Editors: kein Entwurf. Erste ungespeicherte Änderung (neue Vorlage): sofort noch kein Entwurf. Divi speichert Entwürfe per Intervall alle 120 s, wenn es ungespeicherte Änderungen gibt (`theme-builder.js`, Suche `e.autosave=setInterval`, `12e4`, `save({draft:!0})` → `et_theme_builder_api_save` mit `live=0`). Beim ersten Tick entstand der Entwurfs-TB-Post 2387 (`auto-draft`) mit **Kopien aller Vorlagen** als eigene `et_template`-Posts (2388–2390, Status `publish`, die Kopie der neuen Vorlage mit `enabled` 1). Weitere Ticks aktualisierten dieselben Posts. Das Live-Speichern legte 2387 in den Papierkorb (`theme-builder.php:604`) und markierte 2388–2390 als ungenutzt. Das neue Body-Layout 2391 entstand unabhängig davon beim Klick „Benutzerdefinierten Hauptinhalt erstellen“, also schon vor jedem Speichern. Solange ein Entwurf besteht, zeigt der Editor beim nächsten Öffnen dessen Stand (`config.templates.hasDraft`).
**Befund 12 – Form der Pods-Felder im Body.** Der echte Dialog schreibt für ein aus der Liste gewähltes Pods-Feld **weder**`custom_meta_role` als Namen **noch**`post_meta_key` mit `meta_key``role`, sondern:
(in `post_content` steht `\u0022` statt `"`, `tb-body--person-body.html`). Gleiches für `level`/`mentor`. `meta_key` ist leer, `date_format`/`custom_date_format`/`enable_html` werden immer mitgeschrieben. Der Beitragstitel hat nur `{"before":"","after":""}`. Divi nennt diese Form im Server „Legacy complex format“ und löst sie über `select_meta_key` auf (`builder-5/server/Packages/Module/Layout/Components/DynamicContent/DynamicContentOptionPostMetaKey.php:236-262` bzw. `:278-296`); `custom_meta_<key>` als Name heißt dort „Simple format (preferred)“ (`:225-235`). Ein aus der Liste gewähltes Feld gilt nicht als manuelle Eingabe (`DynamicContentUtils.php:527-537`) und braucht im Builder das Recht `read_dynamic_content_custom_fields` (`DynamicContentOptionPostMetaKey.php:305-316`), im Frontend nicht. Die Liste „Standard-Meta-Keys“ stammt aus `DynamicContentOptions::get_most_used_meta_keys()` (`DynamicContentOptions.php:286-316`): Meta-Schlüssel ohne führendes `_` mit nicht serialisierten Werten aus öffentlichen Post-Typen der ganzen Site, 5 Minuten zwischengespeichert – nicht die Felder des Pods; `_pods_mentor` (serialisiert) fehlt deshalb, `mentor` steht drin. Das Plugin schreibt selbst die Namensform `custom_meta_<key>` (`src/Integrations/Divi/Compose/Placeholders.php:196`) und prüft `select_meta_key`-Werte bereits (`src/Integrations/Divi/Compose/DynamicContentRules.php:175-180`). Wer im Body nach „dem Feld role“ sucht oder es ändert, muss beide Formen erkennen.
Ausgabe laut `render--person-erika.txt`: `role` → „Geschäftsführung“; `level` → **`senior`** (gespeicherter Wert, nicht die Beschriftung „Senior“); `mentor` bei Erika leer (sie hat keinen Mentor; Divi gibt im Frontend bei leerem Wert nichts aus, `DynamicContentOptionPostMetaKey.php:433`). Für Max wurde die Vorlage nicht aktiviert (Q5: genau eine Person); Divis Resolver liefert dort nur lesend aufgerufen (`DynamicContentUtils::get_resolved_value`, Kontext `display`) für `mentor`**`2385`** – die rohe Beitrags-ID, keinen Titel (F26).
## Wirkung auf die Live-Site
Die Vorlage 2394 ist deaktiviert (`_et_enabled` = 0); `ET_Theme_Builder_Request::get_template()` überspringt sie (`builder/frontend-builder/theme-builder/ThemeBuilderRequest.php:393`). Sie wäre zudem nur für Fixture-Personen zuständig. Die Standardvorlage 1065 und 1066 blieben deaktiviert. Stale-Test 2395 und die Entwurfsreste 2387–2390 sind gelöscht, kein Post ist als ungenutzt markiert, es gibt keinen TB-Entwurf. Die Divi-Einstellung „Beitragstyp-Integration“ ist unverändert. Neu und sichtbar sind nur die zwei öffentlichen Fixture-Personen unter `/lit-fixture-person/…` und der Menüpunkt „[Fixture] Personen“ im Backend.
Exportiert werden Posts mit Titel „[Fixture 3b] …“ (auch vom Typ `lit_fixture_person`). Das Skript löscht vorher alle `*.json`/`*.html` in diesem Ordner –`render--person-erika.txt` und diese README bleiben. Ohne Argumente exportiert es wie bisher `stage3/`; dessen `theme-builder.json` enthält seit diesen Fixtures auch 2394 (siehe `stage3/README.md`).
## Aufräumen (lokal)
Die Fixtures bleiben stehen. Zum Entfernen (DDEV, WordPress-Wurzel; IDs vorher mit `manifest.json` abgleichen):
```
# Vorlage aus der Live-Liste nehmen, dann Vorlage und Body-Layout (Revisionen fallen mit weg)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Claude Opus 5.5