WP-LIT-MCP/docs/guides/workflows.md

Abläufe

Neue Website aufsetzen

1. lit-site-status und lit-content-types lesen.
2. Grundeinstellungen: lit/wp-settings-get, dann lit/wp-settings-update (Titel, Untertitel, Sprache, Zeitzone, Datumsformat, Permalinks /%postname%/). previous in der Antwort enthält die alten Werte.
3. Seiten als Entwürfe anlegen (lit-content-create), Hierarchie über parent.
4. Startseite: Seite veröffentlichen (nach Rückfrage), dann {"settings": {"page_on_front": <ID>, "show_on_front": "page"}}.
5. Menü: lit/menu-create (optional mit location aus lit/menu-list), Einträge mit lit/menu-set-items.
6. Veröffentlichen erst, wenn der Nutzer es ausdrücklich möchte.

Divi-Seite bauen

1. lit-divi-design-system lesen (Farben, Schriften, Presets) und lit-divi-catalog für die Module.
2. Seite als Entwurf mit Inhalt anlegen: lit-content-create mit divi (Abschnitte in Kurzform, siehe divi-shortform) – oder eine leere Seite anlegen und Abschnitte mit lit-divi-insert einfügen.
3. Weitere Abschnitte/Module mit lit-divi-insert, Anpassungen mit lit-divi-update; immer die tree_rev der letzten Antwort mitgeben.
4. lit-page-render-summary prüfen, warnings beheben, dem Nutzer preview_url und edit_url (Divi-Builder) nennen. Veröffentlichen nur auf Wunsch (lit-post-publish).

Text auf vielen Seiten ersetzen

lit/divi-replace-text zuerst mit dry_run: true (Standard): zeigt Treffer je Seite mit tree_rev. Nach Rückfrage mit dry_run: false, targets (post_id + tree_rev aus dem Probelauf) und confirm: true ausführen; jede Seite bekommt eine eigene Revision, results meldet das Ergebnis je Seite. Ersetzt wird nur sichtbarer Text (keine Links, Stile, Code oder dynamischen Inhalte); in reinen Textfeldern (Titel, Button-Texte) werden Leerzeichen am Anfang und Ende der Ersetzung entfernt. Globale Module werden nicht geändert, sondern in skipped_nodes genannt – dem Nutzer sagen, dass er sie in der Divi-Bibliothek ändern muss.

Menüs pflegen

• lit/menu-get liefert den Baum und menu_rev (Stand des Menüs). lit/menu-set-items verlangt diese menu_rev; hat sich das Menü inzwischen geändert, kommt rev_mismatch – dann mit lit/menu-get neu lesen. Die Antwort enthält die neue menu_rev für weitere Änderungen.
• Für größere Umbauten den Baum verändern und vollständig als items an lit/menu-set-items senden (bestehende Einträge mit id, neue ohne id). Wird der Baum unverändert zurückgeschickt, meldet das Tool „keine Änderung“ und schreibt nichts.
• Für kleine Änderungen operations: {op: "add", item, parent_id?, position?}, {op: "move", id, parent_id?, position?}, {op: "remove", id} (Kinder eines entfernten Eintrags rücken an seine Stelle).
• Neue Einträge ohne id: type post/taxonomy mit object_id, oder custom mit url (/pfad, #anker, http(s), mailto, tel) und title; jeweils optional children. Das Ziel eines bestehenden Eintrags lässt sich nicht ändern – dafür entfernen und neu anlegen.
• Verlinkt werden nur für den Nutzer lesbare, veröffentlichte Inhalte und Begriffe öffentlicher Taxonomien. Private Inhalte sind immer ausgeschlossen. Entwürfe, ausstehende oder geplante Inhalte lassen sich nur mit allow_unpublished: true verlinken – WordPress zeigt den Menüpunkt sofort an, Besucher bekommen bis zur Veröffentlichung einen toten Link (die Antwort enthält dazu eine Warnung).
• Fallen dabei Einträge weg, verlangt das Tool confirm: true; previous_items (Stand vorher) erlaubt das Zurückbauen – neu angelegte Einträge erhalten dabei eine neue id, CSS-Klassen, Linkziel und Beschreibung gehen verloren.
• lit/menu-assign-location mit menu_id: 0 entfernt ein Menü von seiner Position (es verschwindet dann von der Website) und braucht dafür confirm: true nach Rückfrage; die Antwort nennt das entfernte Menü.

Einträge eines eigenen Inhaltstyps (Pods)

1. lit-content-types mit post_type → Pflichtfelder, Auswahlwerte, Beziehungsziele.
2. lit-content-create mit allen Pflichtfeldern in fields.
3. Beziehungen über IDs (vorher mit lit-content-query suchen).