Files
WP-LIT-MCP/docs/guides/divi-design-system.md
T

11 KiB
Raw Blame History

Divi-Designsystem

lit-divi-design-system liest das Designsystem der Website live aus Divi:

  • Globale Farben (colors): ID (gcid-…), Name, Wert und der Platzhalter für neue Inhalte, z. B. {{color:primary}} für die Primärfarbe oder {{color:Nachtblau}} für eine eigene globale Farbe. Die fünf Theme-Farben heißen primary, secondary, heading, body und link.
  • Globale Variablen (variables): Zahlen, Texte, Bilder, Links (gvid-…), Platzhalter {{var:<Name>}}.
  • Theme-Schriften (fonts): Überschrift und Fließtext, Platzhalter {{font:heading}} / {{font:body}}.
  • Größen (sizes): Schriftgrößen, Inhaltsbreite und Spaltenabstand aus den Theme-Optionen.
  • Presets (presets): Modul-Presets je Modul (kind: module, z. B. alle Button-Presets) und Gruppen-Presets (kind: group); default: true markiert das Standard-Preset eines Moduls.

Auf großen Websites eingrenzen: only (Liste aus colors, variables, presets) liefert nur diese Teile (Schriften und Größen sind immer dabei), module (z. B. "button") nur die Presets dieses Moduls; höchstens 200 Presets je Antwort (notes sagt, wenn es mehr gibt).

Regeln:

  1. Vor dem Gestalten einer Seite das Designsystem lesen.
  2. Globale Farben, Variablen und Presets vor festen Werten verwenden; feste Farben oder Schriften nur, wenn der Nutzer es ausdrücklich möchte.
  3. Gibt es für einen Zweck noch keine Farbe, Variable oder kein Preset, dem Nutzer vorschlagen, es im Divi-Builder anzulegen, statt feste Werte zu verteilen.

Presets anlegen, ändern, löschen

Über mcp-adapter-execute-ability:

  • lit/divi-preset-get – ein Preset mit Einstellungen (attrs als Pfad → Wert wie bei lit-divi-node-get), verschachtelten Gruppen-Presets und den Seiten, die es verwenden (usage).
  • lit/divi-presets-set – items mit module (z. B. "button") oder group (z. B. "font-body"):
    • neu: name + Einstellungen (name nur für neue Presets); ändern: preset (Name oder ID), optional rename (nur zusammen mit preset); Namen 1–100 Zeichen ohne HTML, innerhalb des Moduls bzw. der Gruppe eindeutig;
    • Einstellungen in attrs (Vollform, Platzhalter {{color:…}}, {{var:…}}, {{font:…}}) oder aus einem gestalteten Modul: from_node = {"post_id": 12, "id": "s0.r0.c1.m2"} (Pfad-ID aus lit-divi-outline);
    • Presets tragen nur Gestaltung – Texte, Links und Bilder gehören ins Modul (sonst validation_failed);
    • group_presets (nur Modul-Presets), z. B. {"font": "Button-Schrift"}; make_default: true macht das Preset zum Standard seines Moduls bzw. seiner Gruppe;
    • neue Gruppen-Presets brauchen das Modul, aus dem die Gruppe stammt: source_module oder from_node.
  • lit/divi-presets-delete – nur Presets, die nirgends ausdrücklich verwendet werden (Seiten, Bibliothek, Theme Builder, verschachtelt in anderen Presets); sonst in_use mit den Fundstellen und dem Hinweis auf lit/divi-design-detach. Ein Standard-Preset darf gelöscht werden, auch wenn Module es ohne eigenes Preset nutzen: der Probelauf listet diese Seiten, danach zeigen sie das Divi-Standardaussehen. Das gilt auch für Standard-Gruppen-Presets: gelistet werden die Seiten mit Modulen, die diese Gruppe haben, aber kein eigenes Gruppen-Preset dafür.
  • lit/divi-design-snapshots / lit/divi-design-restore – vor jeder Änderung legt LIT MCP einen Snapshot an (je Bereich die letzten 20); wiederherstellen mit snapshot_id.

Ablauf jeder Änderung: Aufruf ohne confirm = Probelauf (confirm_required mit diff, betroffenen Seiten und design_rev), dem Nutzer die Änderung zeigen, dann derselbe Aufruf mit confirm: true und design_rev. Hat sich der Bestand inzwischen geändert (z. B. im Divi-Builder), kommt rev_mismatch – neu prüfen. confirm: true ohne design_rev ergibt validation_failed; läuft gerade eine andere Änderung, kommt conflict – kurz warten und den Probelauf wiederholen.

Rechte: Presets ändern verlangt das Recht, das Design anzupassen, und in Divis Rollen-Editor den Visual Builder. Konten ohne das Recht unfiltered_html (z. B. Redakteure) werden abgewiesen (forbidden), wenn vorhandene Presets HTML oder CSS enthalten – Divi würde es beim Speichern entfernen; dann einen Administrator bitten. Das gilt auch für das Löschen und für lit/divi-design-restore.

Presets auf Seiten zuweisen und Verweise entfernen

Einzelne Module bekommen Presets mit lit-divi-insert, lit-divi-update und lit-content-create (Stapel, group_presets, clear_overrides: siehe divi-shortform). Für viele Seiten gibt es zwei Werkzeuge (über mcp-adapter-execute-ability); beide ändern Seiteninhalt, nicht den Preset-Bestand.

lit/divi-presets-assign – ein Preset oder einen Stapel (preset) und/oder Gruppen-Presets (group_presets) allen Modulen eines Typs (module, z. B. "button") zuweisen:

  • Filter: post_ids (1–50 Einträge; ohne die Angabe alle Fundstellen mit diesem Modultyp), only_without_preset: true (nur Module ohne Preset) oder only_with_preset: "<Name>" (nur Module, die dieses Preset schon tragen; nicht zusammen), clear_overrides: true (lokale Werte entfernen, die das Preset überdecken).
  • preset: null, ein leerer Text und null oder ein leerer Text als Wert in group_presets werden abgewiesen (validation_failed): site-weit entfernt lit/divi-design-detach Verweise.
  • Ablauf: erst ohne confirm aufrufen (Probelauf: confirm_required mit pages – je Seite post_id, title, status, die betroffenen Knoten mit Pfad-ID, Modul und Label sowie warnings zu überdeckten Werten –, dazu pages_count, nodes_count, skipped und gegebenenfalls blocked_ids). Dem Nutzer Seiten, Anzahl der Module und Überdeckungen zeigen und erst nach seiner Antwort denselben Aufruf mit confirm: true senden. Ohne confirm wird nie etwas geschrieben. Ist nichts zu ändern, antwortet der Probelauf normal mit „nichts zu tun“ (kein confirm_required).
  • Je Aufruf werden höchstens 50 Seiten geschrieben. Die Antwort nennt saved (je Seite post_id, revision_id, Anzahl Module) und remaining: Ist remaining größer als 0, denselben Aufruf wiederholen – bereits umgestellte Module ändern sich nicht noch einmal. Jede Seite bekommt ihre eigene WordPress-Revision; einen Snapshot gibt es für Seiteninhalte nicht.
  • Blockaden: Ohne post_ids verweigert der Aufruf alles und schreibt nichts: mit forbidden (und blocked_ids), wenn das Konto eine veröffentlichte, private oder geplante Fundstelle nicht bearbeiten darf, mit unsupported, wenn es mehr als 2000 solcher Fundstellen gibt.
  • Mit post_ids blockieren nur die genannten Seiten, die Obergrenze von 2000 gilt nicht. Eine genannte veröffentlichte, private oder geplante Seite ohne Bearbeitungsrecht verweigert den ganzen Aufruf (forbidden mit blocked_ids, nichts wird geschrieben; der Probelauf listet sie unter blocked_ids). Eine genannte Seite, die nicht live ist (Entwurf usw.) und nicht bearbeitet werden darf, steht unter skipped. Gibt es mehr als 2000 Live-Fundstellen, entfällt die Vorabprüfung der Bearbeitungsrechte; dann steht auch eine genannte Live-Seite ohne Bearbeitungsrecht unter skipped statt in forbidden.
  • Die Sperre für Live-Seiten ergibt sich allein aus der Fundstellensuche: Eine Live-Seite, die das Konto nicht bearbeiten darf, blockiert den ganzen Aufruf, auch wenn die Filter (only_with_preset, only_without_preset) auf dieser Seite nichts ändern würden.
  • Scheitert das Speichern mitten im Lauf, meldet partial_write die bis dahin gespeicherten Seiten (saved): zuerst die genannte fehlgeschlagene Seite prüfen (lit-divi-outline), dann denselben Aufruf mit confirm: true wiederholen; bereits geänderte Module trifft er nicht noch einmal.
  • Globale Module und die Bibliothek: Eine globale Instanz ([global <ID>] in lit-divi-outline) wird auf der Seite nicht umgeschrieben, sondern unter skipped gemeldet – „globales Modul – im Bibliothekseintrag ändern“, wenn das Konto Bibliotheks-IDs sehen darf, sonst „globales Modul – im Divi-Builder ändern“. Der Bibliothekseintrag selbst ist eine eigene Fundstelle und wird wie eine Seite umgeschrieben (wirkt dann überall, siehe divi-library). Seiten, die sich nicht ändern lassen (Divi 4, beschädigtes Markup), stehen mit dem Grund unter skipped.
  • Rechte wie bei den Presets (Recht, das Design anzupassen, und Visual Builder) plus edit_post für jede Fundstelle; Theme-Builder-Layouts nach den Regeln des Theme Builders.

lit/divi-design-detach – Verweise auf ein Preset überall entfernen, damit es sich löschen lässt:

  • Eingabe: preset ist ein Objekt {"module": "button", "preset": "<Name oder ID>"} bzw. {"group": "font", "preset": "<Name oder ID>"}, optional post_ids (Filter wie oben, 1–50).
  • Ablauf wie bei jeder Änderung des Bestands: Probelauf (confirm_required mit Seiten und, wenn andere Presets das Gruppen-Preset verschachteln, diff und design_rev), dem Nutzer zeigen, dann confirm: true (mit design_rev, wenn der Probelauf eine nannte; veraltet: rev_mismatch, dann wird weder am Bestand noch an Seiten etwas geschrieben). Gibt es keine Verweise mehr, ist der Probelauf ein normales „nichts zu tun“.
  • Ohne post_ids werden zuerst verschachtelte Verweise in anderen Presets entfernt (mit Snapshot, wie lit/divi-presets-set), danach die Seiten (höchstens 50 je Aufruf, remaining wie oben; ein weiterer Aufruf findet keine verschachtelten Verweise mehr und macht mit den Seiten weiter). Scheitert das Speichern der ersten Seite nach diesem Presets-Schritt, nennt die Fehlermeldung Snapshot und diff: die Verweise in den Presets sind dann schon entfernt. Mit post_ids werden nur diese Seiten geändert, Verweise in Presets bleiben.
  • Die Module fallen auf das nächste Preset ihres Stapels zurück, sonst auf das Standard-Preset bzw. Divis Standardaussehen. Ein Standard-Preset wird nicht „entkoppelt“, weil Divi es ohne Verweis anwendet; detach entfernt dort nur ausdrückliche Verweise und sagt das in warnings. Zum Beenden der Standardwirkung das Preset löschen (lit/divi-presets-delete) oder mit make_default: false den Standard aufheben.
  • Variablen: variable wird noch nicht unterstützt (unsupported; Variablen folgen mit Etappe 4c).
  • Meldet die Antwort hidden_count größer als 0, können Seiten, die dieses Konto nicht lesen darf, noch Verweise enthalten; dann nennt sie den Hinweis auf lit/divi-presets-delete nicht.
  • Danach lit/divi-presets-delete aufrufen (Probelauf, confirm, design_rev); es meldet kein in_use mehr, solange niemand das Preset neu zugewiesen hat.