Content Office
Blog

WordPress-Anbindung von Content-Office: Einrichtung, Rechte, häufige Fehlerbilder und schnelle Fixes

Eine stabile Verbindung zu WordPress entscheidet darüber, ob Blogbeiträge planbar und fehlerfrei live gehen. Der folgende Leitfaden zeigt, wie Sie die Anbindung sauber einrichten, welche Rechte in WordPress wirklich nötig sind und wie Sie typische Fehlerbilder in wenigen Minuten beheben.

Was technisch passiert – in Kürze

Content-Office kommuniziert serverseitig mit der WordPress-REST-API. Typische Endpunkte:

  • /wp-json/ (API-Index, Erreichbarkeitscheck)
  • /wp-json/wp/v2/posts (Beiträge anlegen/aktualisieren)
  • /wp-json/wp/v2/media (Bilder hochladen/zuweisen)
  • /wp-json/wp/v2/categories und /wp-json/wp/v2/tags (Taxonomien abrufen/anlegen, je nach Rechten)

Wenn diese Endpunkte erreichbar sind und der verwendete WordPress-Nutzer passende Rechte hat, lassen sich Entwürfe aus Content-Office als Beiträge veröffentlichen und aktualisieren – inklusive Titelbild, Kategorien/Tags und geplantem Veröffentlichungszeitpunkt.

Einrichtung Schritt für Schritt

1) WordPress vorbereiten

  1. REST-API prüfen:
    curl -I https://example.com/wp-json/
    Erwartet wird ein HTTP-Status 200. Ein 404/403 weist auf Blockaden (Permalinks, Sicherheitsplugin, WAF) hin.
  2. Rolle festlegen: Für reine Blogbeiträge reicht in der Regel die Rolle „Autor“. Wenn Kategorien angelegt oder Beiträge anderer Nutzer bearbeitet werden sollen, ist „Editor“ sinnvoll.
  3. Dedizierten Nutzer anlegen: „content-office-bot“ o. ä., keine Administrator-Rechte.
  4. Authentifizierung einrichten: Empfohlen sind WordPress Application Passwords (ab WP 5.6). Im Nutzerprofil ein Anwendungspasswort erzeugen und sicher notieren.
  5. Medien-Upload testen (optional): Prüfen, ob ein Upload ≥ 2 MB akzeptiert wird (siehe Fehlerbild 413 unten).

2) In Content-Office verbinden

  1. Im Projekt den Kanal „Blog (WordPress)“ öffnen.
  2. Website-URL exakt eintragen (inkl. https, ohne zusätzliche Pfade; bei Subdirectory-Installationen den Unterpfad angeben, z. B. https://example.com/blog).
  3. Anmeldedaten: Nutzername des dedizierten WordPress-Users und das zugehörige Application Password hinterlegen.
  4. Standardwerte festlegen: Veröffentlichungsstatus (z. B. „Entwurf“ oder „Veröffentlicht“), Standardkategorie, Autor-Zuordnung, optional Beitragsbild-Regel.
  5. Testverbindung ausführen und einen kurzen Testentwurf senden. Erscheint er in WordPress als Entwurf mit korrektem Autor und Titelbild, ist die Basis eingerichtet.

Rechte und Rollen: so wenig wie möglich, so viel wie nötig

  • Autor (empfohlen als Minimalrecht): Beiträge erstellen, eigene Beiträge veröffentlichen, Medien hochladen, vorhandene Kategorien zuweisen. Reicht für die meisten Blog-Setups, sofern Kategorien selten neu angelegt werden.
  • Editor (erweitert): Zusätzlich Kategorien/Tags erstellen, Beiträge anderer Nutzer bearbeiten, geplante Veröffentlichungen teamübergreifend verwalten. Sinnvoll bei Agentur- oder Mehrpersonen-Setups.
  • Administrator (nicht empfohlen): Für die Anbindung nicht erforderlich; erhöht unnötig das Risiko.

Sonderfälle:

  • Custom Post Types (CPT): Der CPT muss in WordPress mit 'show_in_rest' => true registriert sein, damit die REST-API ihn bedienen kann.
  • Multisite: Die Rolle gilt je Site. Der Content-Office-Nutzer braucht die passenden Rechte auf der Ziel-Site, nicht nur im Netzwerk.

Häufige Fehlerbilder – und schnelle Fixes

401 Unauthorized (Anmeldung fehlgeschlagen)

  • Falscher Nutzer/Anwendungspasswort: Neues Application Password erzeugen und exakt eintragen (Leerzeichen vermeiden).
  • HTTP Basic Auth vor der Website (Server- oder Staging-Schutz): Entweder temporär deaktivieren oder die Serverauthentifizierung für /wp-json/ freischalten.
  • 2FA/Anmelde-Plugins: Einige erzwingen Browser-Logins. Für REST-Zugriffe Application Passwords zulassen oder eine Ausnahme konfigurieren.

403 Forbidden (Zugriff blockiert)

  • Security-Plugin/WAF blockiert REST: In Wordfence, iThemes Security oder der WAF (z. B. Cloudflare) eine Regel anlegen, die /wp-json/ und /wp-json/wp/v2/* erlaubt.
  • Geo/IP-Blocker: Falls aktiv, die IP-Region des Servers, von dem Content-Office zugreift, erlauben (Allowlist-Regel).

404 Not Found auf /wp-json/

  • Permalinks stehen auf „Einfach“: In Einstellungen → Permalinks ein anderes Schema wählen (z. B. „Beitragsname“) und speichern.
  • Plugin „Disable REST API“ o. ä.: Für eingeloggte/anwendungsbasierte Zugriffe deaktivieren oder korrekt konfigurieren.
  • Subdirectory oder Reverse Proxy: Die öffentliche URL muss exakt stimmen (z. B. https://example.com/blog/wp-json/).

413 Request Entity Too Large (Bilder scheitern)

  • Serverlimits erhöhen: upload_max_filesize und post_max_size (z. B. auf 16M) sowie ggf. client_max_body_size im Webserver anpassen.
  • Zwischen-Caches/CDNs: Auch dort existieren Upload-Limits. Entweder erhöhen oder den Medien-Upload an WordPress direkt vorbeileiten.

429 Too Many Requests (Rate-Limit)

  • WAF/CDN-Limits anheben oder Endpunkte allowlisten.
  • Veröffentlichungen zeitlich entzerren (mehrere Posts/Medien nicht zeitgleich senden).

500er-Fehler (Serverfehler)

  • PHP-Memory knapp: memory_limit moderat erhöhen (z. B. 256M).
  • Plugin-Konflikt: Fehlermeldung im Serverlog prüfen, testweise Sicherheits-/REST-bezogene Plugins kurz deaktivieren.

Beitrag kommt an, aber ohne Titelbild/Kategorien

  • Rolle prüfen: „Autor“ darf keine neuen Kategorien anlegen – nur zuweisen. Entweder Kategorie vorab in WordPress erstellen oder Rolle auf „Editor“ anheben.
  • Medien-Endpunkt blockiert: Siehe 403/413. Ohne funktionierenden Medien-Upload kann kein Beitragsbild gesetzt werden.

Duplikate oder falsche Slugs

  • Slug-Kollisionen: Existiert der Slug bereits, hängt WordPress automatisch -2 an. Empfehlung: Eindeutige Titel oder Slug-Strategie verwenden (z. B. inklusive Datum).
  • Doppelte Veröffentlichungen durch manuelles Nachklicken: In Content-Office den Veröffentlichungsstatus klar festlegen (nur einmalig senden) und die Freigabeprozesse definieren.

Praxisnahe Beispiele

1) KMU hinter Cloudflare: 403 beim Senden

Ausgangslage: /wp-json/ liefert gelegentlich 403. Cloudflare stuft die Anfragen als verdächtig ein.

Vorgehen:

  1. In Cloudflare eine Page Rule oder WAF-Regel anlegen, die Anfragen an example.com/wp-json/* erlaubt (Security Level „Essentially Off“ oder gezielte Allowlist-Regel).
  2. Security-Plugin so konfigurieren, dass die REST-API für authentifizierte Zugriffe nicht blockiert wird.
  3. Testentwurf erneut senden – Status 200, Beitrag erscheint als Entwurf in WordPress.

2) Agentur mit Custom Post Type „magazin“

Ausgangslage: Beiträge lassen sich im CPT nicht anlegen. Ursache: REST-API für den CPT deaktiviert.

Fix in der CPT-Registrierung:

<?php
register_post_type('magazin', [
  'label' => 'Magazin',
  'public' => true,
  'show_in_rest' => true, // wichtig für Gutenberg & REST
  'supports' => ['title','editor','thumbnail','excerpt'],
]);

Nach dem Anpassen neu testen: Der Endpunkt /wp-json/wp/v2/magazin ist erreichbar, Content-Office kann Beiträge erstellen.

3) Bild-Uploads scheitern (413) auf Nginx

Ausgangslage: Beiträge kommen an, aber ohne Beitragsbild. Medien-Upload liefert 413.

Schneller Fix:

# nginx.conf / Server-Block
client_max_body_size 16M;

Ergänzend in PHP:

; php.ini
upload_max_filesize = 16M
post_max_size = 16M

Webserver neu laden, erneut testen – Bilder werden angenommen, Beitragsbild setzt korrekt.

Diagnose in 60 Sekunden: Mini-Checkliste

  1. Erreichbarkeit: curl -I https://example.com/wp-json/ → 200?
  2. Rolle: Dedizierter Nutzer mit „Autor“ oder „Editor“?
  3. Auth: Gültiges Application Password genutzt?
  4. Security: WAF/Plugin-Regeln erlauben /wp-json/wp/v2/*?
  5. Upload: upload_max_filesize & client_max_body_size ≥ Bildgröße?
  6. CPT: Falls genutzt, 'show_in_rest' => true gesetzt?

Best Practices für einen robusten Betrieb

  • Eigener Integrationsnutzer mit minimal nötigen Rechten; Application Passwords pro Umgebung (Prod/Staging) trennen und bei Teamwechsel rotieren.
  • Sicherheitsplugins strikt konfigurieren statt pauschal zu deaktivieren; REST-Ausnahmen eng fassen.
  • Standardkategorien und -Tags in WordPress vorab anlegen, um Autor-Rechte beizubehalten.
  • Regelmäßig einen kurzen Live-Test fahren (z. B. monatlich einen Entwurf senden), um frühzeitig Blockaden durch Updates zu erkennen.

Fazit

Mit wenigen, klaren Einstellungen verbindet sich Content-Office zuverlässig mit WordPress: REST-API erreichbar, dedizierter Nutzer mit passenden Rechten, sinnvolle Defaults für Status, Kategorien und Bilder. Tritt ein Fehler auf, führen Statuscodes schnell zur Ursache – 401/403 (Auth/Security), 404 (Permalinks/REST), 413 (Upload-Limits), 500/429 (Server/WAF). Wer diese Punkte im Blick behält und Ausnahmen in Sicherheits-Setups präzise konfiguriert, veröffentlicht Beiträge planbar und ohne manuelles Copy-Paste.

Zurück zur Übersicht