ENDE
Zur Startseite

WPAgently-Dokumentation

Erste Workflows sicher ausführen

Starte mit einem kleinen Entwurf. So erkennst du, ob Verbindung, Editor-Rolle und Verifikations-Layer gemeinsam funktionieren.

Schritt 5: Smoke-Test (etwa 6 Minuten)

Jetzt der große Moment: Wir prüfen einmal komplett durch, ob alles zusammenspielt. „Smoke-Test“ ist nur ein gängiger Begriff für „kurz einschalten und schauen, ob es raucht“, also ein schneller Grundcheck.

Führe zuerst den Rundum-Check aus:

wp-agent doctor

Der Befehl erledigt in einem Durchlauf sieben Verbindungs- und Konfigurationsprüfungen. Er prüft Erreichbarkeit, Authentifizierung, Bot-Rolle, Lizenz, zentrale Companion-Steuerung, Kern-Abilities und MCP. Nur wenn alle sieben Checks OK melden, ist die Verbindung startklar. Schlägt eine Voraussetzung fehl, markiert wp-agent doctor abhängige Prüfungen als nicht ausgeführt. So kann eine nicht erreichbare Steuerung niemals als leere, aber angeblich vollständige Ability- oder MCP-Liste grün erscheinen.

Zusätzlich kannst du unter WPAgently > Agent verbinden eine externe Verbindungsdiagnose starten. WordPress ruft dabei ohne Zugangsdaten seine öffentliche REST-API, den MCP-Endpunkt und die OAuth-Metadaten über die normale Website-Adresse auf. Dadurch werden viele Sperren durch CDN, Firewall oder Security-Plugin sichtbar, die eine rein interne Prüfung nicht erkennt. Erkannte vorgeschaltete Dienste und bekannte aktive Security-Plugins erscheinen als Hinweise, nicht als pauschale Fehlerursache. Wenn eine bereits erfolgreich verwendete Verbindung später ihre Anmeldung verliert, zeigt WPAgently Administratoren außerdem eine Warnung mit direktem Link zu dieser Diagnose.

Für eine gezielte Einzelprüfung stehen zusätzlich wp-agent preflight (nur die Bot-Rolle) und wp-agent abilities (nur die Ability-Liste, jeweils markiert als readonly [R] = nur lesend oder schreibend [W]) zur Verfügung.

Zum Abschluss legst du einen ersten Test-Entwurf aus einer winzigen Textdatei an. Erzeuge sie zum Beispiel mit printf (ein Befehl, der schlicht Text in eine Datei schreibt):

printf '## Smoke-Test\n\nEin Absatz mit **Fett** und einer Liste:\n\n- eins\n- zwei\n' > test.md

Erzeuge daraus den Testartikel:

wp-agent article --markdown-file test.md --title "Smoke-Test" --slug smoke-test

Das Ergebnis muss Freiform: 0 melden. In der Render-Zeile steht zusätzlich Freiform=0. Das bedeutet, dass die Formatierung sauber in echte WordPress-Blöcke umgewandelt wurde und nichts in der alten, kaputten Editor-Ansicht gelandet ist. Der Beitrag bleibt automatisch ein Entwurf (Draft), du veröffentlichst also aus Versehen nichts.

Dieser Smoke-Test erzeugt bewusst einen minimalen Artikel. Ein vollständiger erster Beitrag mit Beitragsbild und anschließendem SEO-Read entsteht über den wp-article-Skill (Claude Code) beziehungsweise über die passenden Flags (--image, --alt, --seo-title, --seo-description, siehe wp-agent article --help). Mit Companion 0.4.30 oder neuer streamt die Artikel-Pipeline lokale Beitragsbilder automatisch über den kurzlebigen Direkt-Upload. Bei älteren Companion-Versionen nutzt sie kompatibel den bisherigen Core-REST-Upload. Öffentliche Bild-URLs werden heruntergeladen, wobei jedes Weiterleitungsziel erneut gegen den SSRF-Schutz geprüft wird. Für SEO-Angaben muss Rank Math, Yoast, AIOSEO oder SEOPress aktiv sein. set-seo-meta validiert die Eingabe, liest den Zustand frisch und bricht derzeit providerübergreifend mit HTTP 409 und manual_only vor jeder Mutation ab. Gewünschte Änderungen nimmst du im SEO-Plugin manuell vor und liest sie danach über get-seo-meta erneut.

Die Artikel- und Landing-Pipelines verlangen zusätzlich die flachen Schreibsemantiken remote_create und manual_only_update aus tools/list sowie das allgemeine manual_only. Companion-Stände, die diese Metadaten nicht liefern, werden für kombinierte Pipelines nicht als kompatibel angenommen: Die CLI bricht vor der ersten Remote-Mutation ab, weil sie einen späteren manuellen 409-Schreibpfad sonst nicht sicher erkennen kann. Das betrifft bestehende Markdown-Updates sowie SEO- und Status-Schritte. Einzelne Abilities bleiben nach ihrem jeweils installierten Schema nutzbar. Für Pipelines müssen CLI und Companion deshalb aus einem zusammengehörigen, semantisch kompatiblen Stand stammen.

Geschafft ist der Schritt, wenn wp-agent doctor siebenmal OK meldet und der Testartikel mit Freiform: 0 beziehungsweise Freiform=0 als Entwurf in deinem WordPress landet. Ein --publish-Aufruf ändert den Status derzeit nicht automatisch, weil set-post-status mit manual_only abbricht. Veröffentlichung und weitere Statuswechsel erfolgen nach der Prüfung manuell in WordPress. Ab hier steht die Verbindung.

Diagnose

Die sieben Checks von wp-agent doctor (siehe Schritt 5) im Detail. Der Befehl läuft sie der Reihe nach durch und meldet je Check OK oder FEHLER mit einem Klartext-Hinweis. Falls einer rot ist, findest du hier die Ursache:

  1. Erreichbarkeit: Ist die Seite unter WP_AGENT_SITE erreichbar, und antwortet die technische Schnittstelle unter /wp-json mit den erwarteten Daten (JSON)? Häufigster Anfängerfehler: Bei „Einfach“-Permalinks liefert /wp-json/ die Startseite als HTML statt der erwarteten Daten. Dieser Check erkennt das und gibt dir einen Permalink-Hinweis, statt fälschlich grün zu sein. Abhilfe: Pretty-Permalinks aktivieren (Einstellungen > Permalinks).
  2. Auth: Meldet der gespeicherte OAuth-Zugang den ausgewählten Redakteur korrekt an? Die CLI erneuert ein bald ablaufendes Token automatisch. Ein Fehler bedeutet meist, dass der Zugang serverseitig widerrufen wurde. Führe dann wp-agent logout --site "$WP_AGENT_SITE" --force und anschließend wp-agent login --site "$WP_AGENT_SITE" aus. Beim Passwort-Fallback prüfst du stattdessen Benutzername und Application Password.
  3. Bot-Rolle: Trägt der Bot die Rolle Editor und nicht Administrator? Das ist dieselbe Prüfung wie wp-agent preflight; Admin-Rechte sind ein harter Stopp und Absicht.
  4. Lizenz: Ist die lokale Lizenzbestätigung gültig und innerhalb der erlaubten Offline-Frist?
  5. Steuerung: Sind der zentrale Schalter, der Domain Lock und das Ability-Profil gültig, und melden die serverseitigen Diagnosen keinen Fehler?
  6. Abilities: Sind alle laut Kontrollzentrum aktivierten Abilities angemeldet? Fehlen welche, prüfe das Profil und den Companion-Schalter unter WPAgently > Übersicht.
  7. MCP: Antwortet der Server unter <site>/wp-json/wp-agent/mcp sauber, und enthält tools/list die Werkzeuge für alle laut Kontrollzentrum aktivierten Abilities? Fehlt der Server trotz aktivem Plugin, ist das Plugin unvollständig ausgeliefert und muss neu gebaut werden.

Für eine gezielte Einzelprüfung wiederholen wp-agent preflight (Check 3) und wp-agent abilities (Check 6) denselben Aspekt isoliert. wp-agent login richtet den CLI-Zugang ein, gehört aber nicht zu den sieben Doctor-Checks. wp-agent init testet ebenfalls nichts. Der Befehl schreibt nur optionale statische Verbindungsdateien (siehe Schritt 4).

Die Gesamtarchitektur der installierbaren Bausteine beschreibt die Architektur-Dokumentation.