Aktualisiert am 20. Oktober 2026.
Wenn Sie das Semly-Plugin nutzen, beginnen Sie mit dessen Verbindungsdokumentation. Die folgende Diagnose gilt weiterhin für die standardmäßige WordPress REST API. Ein Anwendungspasswort ist keine Voraussetzung des Kopplungsverfahrens des Semly-Plugins.
Dokumentation des Semly-Plugins
Diese Anleitung betrifft das Schreiben über die Standard-REST-API einer selbst betriebenen WordPress-Installation. Sie beschreibt weder ein bestimmtes Semly-Plugin noch die WordPress.com-API. Ziel ist ein nachvollziehbarer Fehlerbefund und ein bestätigter Entwurf.
1. Anfrage und Antwort erfassen
Notieren Sie Methode, URL ohne Geheimnisse, Zeitpunkt, Status, Antworttyp sowie vorhandene Felder code und message. Standardbeiträge verwenden /wp-json/wp/v2/posts. Ein Unterverzeichnis oder eigener Inhaltstyp kann eine andere Route erfordern.
Prüfen Sie registrierte Routen unter /wp-json/. Mit ?rest_route=/wp/v2/posts lässt sich die URL-Umschreibung untersuchen. Ein erfolgreicher Lesezugriff beweist keine Schreibberechtigung.
2. Mögliche Ursachen unterscheiden
| Status | Prüfen |
|---|---|
| 401 | Zugangsdaten, HTTPS und Weitergabe von Authorization |
| 403 | Berechtigungen, Plugin, WAF- oder Proxy-Regel |
| 404 | Adresse, Methode, registrierte Route oder Beitrags-ID |
Der Status allein ist keine Diagnose. rest_cannot_create beweist keine erfolgreiche Anmeldung. Auch ein Proxy kann JSON liefern; HTML schließt eine WordPress-Antwort nicht aus. Gleichen Sie den Befund mit Administratorprotokollen ab.
3. Identität und Rechte prüfen
Verwenden Sie für unterstützte externe Verbindungen ein eigenes benutzergebundenes Anwendungspasswort über HTTPS. Hauptpasswort und Geheimnisse gehören nicht in Supportmeldungen. Die Weitergabe von Authorization lässt sich prüfen, ohne dessen Wert zu protokollieren.
Ein authentifizierter Abruf von /wp-json/wp/v2/users/me bestätigt die Benutzererkennung, nicht das Recht zur Beitragserstellung. Entwurf und öffentliche Veröffentlichung sind getrennte Vorgänge. Cookie-Anmeldung innerhalb von WordPress hat andere Anforderungen, einschließlich Nonce.
4. Einen Entwurf testen
Konfigurieren Sie POST an https://example.com/wp-json/wp/v2/posts mit Content-Type: application/json.
{"title":"API test","content":"Test","status":"draft"}
Hinterlegen Sie Zugangsdaten im Client, nicht im geteilten Beispiel. Prüfen Sie ID, Status und den Entwurf im Backend. Bei unklarer Antwort prüfen Sie zuerst, ob der Beitrag existiert; ein erneuter POST kann ein Duplikat erzeugen.
5. Reparatur übergeben und abnehmen
Übermitteln Sie Zeitpunkt, Route, Methode und bereinigte Antwort. Deaktivieren Sie nicht pauschal Sicherheitsmaßnahmen und vergeben Sie keine Administratorrolle nur für den Test. Die Reparatur ist bestätigt, wenn derselbe Test genau einen Entwurf erstellt und dessen ID erneut lesbar ist. Öffentliche Veröffentlichung ist zur Diagnose nicht nötig.
