ENDE
Zur Startseite

WPAgently-Dokumentation

Architektur: vier Schichten, eine Prüfkette

Die Architektur trennt Verbindung, Agentenwissen und Verifikation. Genau diese Trennung macht die Grenzen sichtbar.

WPAgently verbindet deinen Assistenten mit WordPress und prüft wichtige Ergebnisse nach. Du musst die Technik dahinter nicht bedienen können. Diese Seite erklärt nur, warum der normale Ablauf zuerst einen Entwurf erstellt und bei unklaren Fällen lieber stoppt.

Für den Alltag genügt der Schnellstart. Die Architektur hilft dir, Sicherheitsmeldungen und Grenzen besser einzuordnen.

Vier Schichten

WPAgently trennt vier Aufgaben. Dadurch erhält ein einzelner Fehler nicht automatisch zu viele Rechte.

  1. WordPress-Werkzeuge

Eine Ability ist eine klar begrenzte Aktion, etwa einen Entwurf anlegen oder einen Beitrag prüfen. WordPress stellt nur die Funktionen bereit, die für dein gewähltes Profil aktiviert sind.

Das Companion-Plugin bringt den MCP-Adapter im Release-ZIP unter vendor/ mit und lädt ihn über vendor/autoload.php. Der eigene MCP-Endpunkt braucht deshalb kein Fremd-Plugin als Adapter-Host. Der Build sperrt Composer-Plugins beim Bundling, damit der Runtime-Bootstrap nur den geprüften Autoloader verwendet.

  1. Dein Assistent

Claude Code, Claude Desktop, Codex, ChatGPT und weitere unterstützte Assistenten verbinden sich mit diesen Werkzeugen. Sie erhalten keinen direkten Administratorzugang zu deiner Website.

  1. Die CLI und Skills

Die optionale Paid-CLI erleichtert wiederholbare Aufgaben im Terminal. Skills sind kurze Anleitungen für Claude Code oder Codex. Beide helfen beim Ablauf, ersetzen aber nicht die Regeln in WordPress.

  1. Der Chat in WordPress

Ab WordPress 7.0 kannst du zusätzlich WPAgently > Chat und Vorschau nutzen. Deinen eigenen KI-Anbieter richtest du unter Einstellungen > Connectors ein. Schreibende Vorschläge erscheinen als Plan und brauchen deine einzelne Freigabe. Die isolierte Vorschau lässt same-origin-Ressourcen, data:-Bilder, data:-Schriften und begrenzte Inline-Styles zu. Externe Stylesheets, CSS-Imports, Schriften, Bilder und Medien werden blockiert. Skripte und Netzwerkverbindungen sind in der Vorschau gesperrt.

Was bei einem normalen Auftrag passiert

Wenn du einen Artikel oder eine Landingpage erstellen lässt, läuft der normale Weg in einer festen Reihenfolge ab.

  1. WPAgently prüft die Verbindung und die Rolle des Agent-Nutzers.
  2. Der Assistent erstellt einen neuen Entwurf. Ein Entwurf ist noch nicht öffentlich sichtbar.
  3. WordPress wandelt den Inhalt in echte Blöcke um und prüft die Darstellung.
  4. WPAgently prüft wichtige Nacharbeiten, etwa die Darstellung und bei Bedarf den Cache.
  5. Du prüfst den Entwurf sichtbar im WordPress-Backend und veröffentlichst ihn dort selbst.

Der Assistent schreibt dabei keinen frei erfundenen Block-Code oder HTML direkt in deine Seite. Das verhindert, dass neue Inhalte unbemerkt im alten Classic-Editor-Format landen.

Artikel und Landingpages

Welche Abilities die CLI-Pipelines ARTIKEL und LANDING aufrufen, hängt von der Aufgabe, einem vorhandenen Slug und den gewählten Optionen ab. Ein Slug ist der letzte Teil einer Webadresse, zum Beispiel mein-neuer-artikel.

  • wp-agent/create-post-from-markdown erstellt einen neuen Artikel als Entwurf.
  • wp-agent/upsert-pattern erstellt eine Landingpage aus klar beschriebenen Abschnitten.
  • wp-agent/render-verify prüft nach einer Änderung die sichtbare Darstellung. wp-agent/render-check ist eine separate, schreibgeschützte Ability. Sie prüft die Block-Interpretation und meldet unter anderem einen Classic-Editor-Fallback.
  • wp-agent/refresh-hooks stößt wichtige Nacharbeiten an, die WordPress sonst oft erst beim manuellen Speichern erledigt.

Für ein lokales Beitragsbild kann der Ablauf zusätzlich wp-agent/create-direct-media-upload, wp-agent/get-post und wp-agent/set-featured-image nutzen. Schlägt die Prüfung des Direkt-Uploads nach dem Speichern fehl, bleibt der Anhang erhalten und die Ability meldet HTTP 409 mit wpagent_direct_upload_recovery_required, recovery_required=true und der attachment_id zur manuellen Kontrolle. Für SEO liest WPAgently den Zustand mit get-seo-meta. set-seo-meta und set-post-status stoppen derzeit absichtlich mit manual_only. SEO-Änderungen und die Veröffentlichung nimmst du deshalb nach deiner Prüfung in WordPress vor.

Bei einem vorhandenen Slug liest WPAgently zuerst den aktuellen Zustand. Mehrere oder nicht exakt passende Treffer führen vor jeder Mutation zum Abbruch, ohne dass ein Beitrag ausgewählt wird. So überschreibt die Automatisierung nicht einfach den falschen Inhalt.

Die fünf stillen Fehlerarten

WPAgently soll diese fünf Probleme sichtbar machen, bevor ein Entwurf veröffentlicht wird.

  1. Unformatierter Inhalt: WordPress würde den Inhalt als Classic-Block speichern. WPAgently hält den Vorgang an.
  2. SEO ohne Wirkung: Ein SEO-Plugin würde eine Änderung nicht zuverlässig übernehmen. WPAgently stoppt und du änderst den Wert im SEO-Plugin.
  3. Alte Vorschau oder Sitemap: Ein Cache oder eine Nacharbeit ist noch nicht aktuell. WPAgently stößt die passende Nacharbeit an.
  4. Unsichere oder unvollständige Bilder: Ein Bild-Link zeigt auf einen geschützten Bereich oder es fehlt Alt-Text. WPAgently weist ihn zurück.
  5. Doppelter Artikel: Ein Auftrag könnte denselben Beitrag ein zweites Mal anlegen. WPAgently stoppt bei einem unklaren Treffer.

Die konkrete Hilfe dazu findest du in der Fehlerbehebung.

Safety-Layer

Der Safety-Layer ist die Prüfschicht rund um normale WPAgently-Aufgaben. Er ist keine Garantie gegen jeden Fehler, sondern eine Reihe konkreter Grenzen.

  • Bot-nicht-Admin: Vor einer Aufgabe prüft WPAgently, dass der Agent-Nutzer nur Editor oder Redakteur ist. Hat er Administratorrechte, stoppt der Ablauf absichtlich.
  • Entwurf zuerst: CLI-Pipelines legen neue Inhalte standardmäßig als Entwürfe an. Auch ein angeforderter Veröffentlichungsbefehl veröffentlicht sie derzeit nicht automatisch.
  • Sichere Bildquellen: WPAgently akzeptiert nur öffentliche Bildadressen und blockiert lokale sowie private Netzwerkadressen.
  • Keine stillen Duplikate: Ein bereits belegter oder mehrdeutiger Slug stoppt die Erstellung, bevor etwas geändert wird.
  • Begrenzte Werkzeuge: Eine ausgeschaltete Ability erscheint deinem Assistenten gar nicht erst.

BYO-Prinzip

BYO bedeutet „Bring your own“, also „du verwendest deinen eigenen Zugang“. Du wählst selbst deinen KI-Anbieter und deine WordPress-Seite. Deine WordPress-Inhalte und Zugangsdaten werden nicht über einen WPAgently-Textdienst geleitet.

Bei einer externen Verbindung liegt der Zugang bei dir, entweder in deiner lokalen Konfigurationsdatei oder in der bestätigten Browser-Anmeldung. Beim optionalen WordPress-Chat sendet WordPress die Anfrage direkt an den KI-Anbieter, den du selbst unter Einstellungen > Connectors eingerichtet hast.

Die Lizenzprüfung und Updates benötigen technische Verbindungen. Sie übertragen dabei keine WordPress-Inhalte oder WordPress-Zugangsdaten.

Produktions-Hinweis

Auch mit diesen Grenzen prüfst du jede sichtbare Änderung selbst, bevor du sie veröffentlichst. Nutze für normale Inhalte den Companion und den Redakteur aus der Einrichtung.

Power ist bewusst nicht Teil dieses Wegs. Es ist ein separates Plugin für technischen Zugriff auf Dateien, Datenbank und PHP. Als normaler WordPress-Nutzer lässt du es ausgeschaltet. Wenn du es für eine Testkopie brauchst, lies zuerst den Power-Modus.