WordPress KI-Workflows mit der Abilities API

#Was ist die WordPress Abilities API?

#Das Problem mit aktuellen Ansätzen

Die WordPress REST API ist leistungsfähig, aber ressourcenorientiert. Sie stellt Endpoints wie /wp/v2/posts und /wc/v3/products bereit, also CRUD-Operationen auf Datenobjekten. Ein KI-Agent kann diese Endpoints nutzen, muss aber vorprogrammiert wissen, was jeder Endpoint tut, welche Parameter er akzeptiert und wie mehrere Aufrufe verkettet werden müssen.

WPGraphQL verbessert dies durch flexible Abfragen, teilt aber dieselbe grundlegende Einschränkung: Es beschreibt Daten, keine Fähigkeiten.

Betrachten Sie dieses Szenario: Sie möchten, dass ein KI-Agent „einen Blogbeitrag über Frühlingsgartenarbeit schreibt, ihn SEO-optimiert, ein Beitragsbild hinzufügt und die Veröffentlichung für nächsten Dienstag plant.” Mit der REST API muss der Agent:

1. Den /wp/v2/posts-Endpoint und seine Parameter kennen
2. Wissen, dass SEO-Daten in einem Meta-Feld von Yoast oder RankMath liegen
3. Wissen, wie Medien über /wp/v2/media hochgeladen werden
4. Das Datumsformat für die Planung kennen
5. Diese Aufrufe in der richtigen Reihenfolge verketten

Mit der Abilities API kann ein Plugin stattdessen eng geschnittene Operationen wie content/create-draft oder media/attach-image registrieren. Eine authentifizierte Integration listet die freigegebenen Abilities, liest deren Schemas und ruft den passenden /run-Endpoint auf. Die Planung des Ablaufs und der Umgang mit Abhängigkeiten bleiben Sache des Aufrufers, solange das Plugin keine übergeordnete Operation anbietet, die den gesamten Vorgang kapselt.

#Architekturüberblick

Die API besteht aus vier Teilen. Eine Kategorie gruppiert verwandte Operationen. Eine Ability trägt einen eindeutigen Namen im Format namespace/ability-name, dazu ein Label, eine Beschreibung, Schemas und Callbacks. Das Register macht Abilities für WordPress-Code auffindbar. Die REST-Freigabe ist ein optionaler Transportweg für authentifizierte externe Systeme.

Die Registrierung läuft über eigene Hooks. Kategorien werden am Hook wp_abilities_api_categories_init mit wp_register_ability_category() angemeldet, Abilities am Hook wp_abilities_api_init mit wp_register_ability(). Dieses Timing ist keine Formalie: Wer stattdessen an einem allgemeinen Plugin-Ladehook registriert, läuft leicht in den Fall, dass das Register noch gar nicht bereitsteht, und wundert sich dann über eine leere Liste.

Das offizielle Handbuch dokumentiert die serverseitige API für WordPress 6.9 und neuer. WordPress 7.0 ergänzt Pakete, mit denen sich serverseitig registrierte Abilities im Admin nach JavaScript laden lassen. Diese Ergänzung ersetzt weder das PHP-Register noch dessen Berechtigungsmodell.

#REST-Erkennung und Ausführung

Die REST-Freigabe ist standardmäßig deaktiviert. Ein Plugin aktiviert sie pro Ability über meta.show_in_rest. Erst danach können authentifizierte Clients die Abilities unter /wp-json/wp-abilities/v1/abilities auflisten, eine einzelne Ability über Namensraum und Name abrufen und deren /run-Endpoint aufrufen. Welche HTTP-Methode dabei zulässig ist, hängt von den Annotationen und dem Verhalten der jeweiligen Ability ab.

Die REST-Authentifizierung von WordPress gilt weiterhin. Code auf derselben Domain kann Cookie-Authentifizierung nutzen. Für externen Zugriff empfiehlt die offizielle REST-Dokumentation Anwendungspasswörter, alternativ sind eigene Authentifizierungs-Plugins möglich. Und noch eine Unterscheidung, die im Code-Review gern untergeht: Eine Ability auflisten zu dürfen bedeutet nicht, sie ausführen zu dürfen. WordPress wertet dafür den permission_callback der Ability für den aktuellen Benutzer aus.

Diese Trennung ist in der Praxis nützlich. Ein Plugin kann eine interne Ability registrieren, die nur anderer PHP-Code aufruft, und show_in_rest schlicht weglassen. Eine zweite, rein lesende Ability lässt sich einem Dienstkonto mit knapp bemessenen WordPress-Capabilities öffnen. Eine schreibende oder gar löschende Operation gehört hinter einen engeren Permission-Callback und zusätzliche Kontrollen auf Anwendungsebene.

#Wie eine KI-Anbindung tatsächlich entsteht

#Model Context Protocol: die Brücke müssen Sie bauen

Anthropics Model Context Protocol definiert, wie KI-Agenten externe Werkzeuge entdecken und nutzen. Die strukturierten Beschreibungen und JSON-Schemas der Abilities API sind eine gute Ausgangslage für diese Übersetzung, weil Name, Zweck und erwartete Parameter bereits maschinenlesbar vorliegen. Der Schritt zum Tool-Format eines Agenten bleibt trotzdem Integrationsarbeit.

WordPress stellt von sich aus keinen MCP-Endpoint und kein anbieterspezifisches Plugin-Manifest bereit. Eine Brücke muss sich gegenüber WordPress authentifizieren, die erlaubten Abilities auswählen, Schemas übersetzen, eigene Limits durchsetzen und Fehler verständlich an den Client zurückgeben. Die wichtigste Regel dabei ist eine Verzichtsregel: Die Brücke sollte weniger Operationen anbieten, als der zugrunde liegende WordPress-Benutzer ausführen könnte, und nicht einfach jede gefundene Ability durchreichen.

Ein Beispiel aus dem Support-Alltag. Ein Assistent bekommt genau zwei Operationen: eine lesende Produktabfrage und das Anlegen eines Ticket-Entwurfs. Rückerstattungen, das Löschen von Benutzern und Änderungen an den Seiteneinstellungen bleiben außerhalb der Brücke. Diese Aufteilung lässt sich in einem Review in wenigen Minuten prüfen. Ein Generalagent mit Administratorkonto lässt sich nicht prüfen, sondern nur hoffen.

#OpenAI-Funktionsaufrufe und generisches Tool-Calling

Für Systeme mit generischem Function-Calling gilt dieselbe Logik. Die deklarierten JSON-Schemas lassen sich auf Tool-Parameter abbilden, sodass jeder Agent mit strukturiertem Tool-Calling die Operationen konsumieren kann. Die Zuordnung, die Fehlerübersetzung und die Frage, welche Ability überhaupt sichtbar sein darf, liegen aber in der Integrationsschicht, nicht in WordPress.

#Praktische Anwendungsfälle

#Content-Erstellung-Workflows

Der unmittelbarste Anwendungsfall ist die intelligente Content-Erstellung. Anstatt dass eine KI Rohtext generiert, den ein Mensch in WordPress einfügt, arbeitet die Integrationsschicht mit klar benannten Operationen, die Plugins bereitstellen:

Benutzer: "Erstelle einen umfassenden Leitfaden über biologische Schädlingsbekämpfung für unseren Gartenblog"

Ablauf in der Integrationsschicht:
1. research_topics    → findet Trend-Unterthemen und Wettbewerbslücken
2. generate_content   → erstellt Artikelentwurf mit Überschriften und Bildreferenzen
3. optimize_seo       → fügt Meta-Beschreibung, Fokus-Keyword und interne Links hinzu
4. attach_image       → hängt ein freigegebenes Beitragsbild an
5. create_draft       → speichert als Entwurf mit allen Metadaten
6. notify_editor      → sendet Überprüfungsbenachrichtigung an das Redaktionsteam

Jede dieser Operationen kann von einem anderen Plugin stammen, SEO etwa von RankMath, Bildverarbeitung von einem Media-Plugin, Benachrichtigungen von einem Workflow-Plugin. Was die Abilities API beisteuert, ist der einheitliche Vertrag: gleiche Metadatenstruktur, gleiche Schemaform, gleiche Berechtigungsprüfung. Die Reihenfolge und den Umgang mit einem fehlgeschlagenen Schritt bestimmt weiterhin der Aufrufer.

#WooCommerce-Shop-Management

Für E-Commerce-Seiten lassen sich Betriebsabläufe in ähnlich enge Operationen schneiden:

• Lagerverwaltung: Bestände lesen, Nachbestellvorschläge erzeugen, Mengen aktualisieren
• Preispflege: Vorschläge berechnen, Änderungen als Entwurf vorbereiten
• Produktbeschreibungen: Texte anhand von Produktattributen und SEO-Zielen erzeugen und aktualisieren
• Kundenservice: Bestellstatus lesen, Versandinformationen ergänzen
• Verkaufsanalyse: Berichte erzeugen, Trends identifizieren, Aktionen vorschlagen

Ein Shopbesitzer könnte fragen: „Welche Produkte wurden seit 90 Tagen nicht verkauft, und lohnt sich Rabatt, Bundle oder Auslistung?” Die lesenden Schritte lassen sich gefahrlos freigeben. Bei den schreibenden Schritten zahlt sich der Schnitt aus: Eine Preisanpassung als vorbereiteter Entwurf ist etwas anderes als eine Massenänderung, die sofort im Shop steht. Rückerstattungen gehören in dieser Logik ohnehin nicht an einen Agenten, sondern hinter eine menschliche Freigabe.

#SEO-Automatisierung

SEO-Aufgaben, die zuvor manuelle Arbeit oder separate Werkzeuge erforderten, lassen sich als benannte Operationen abbilden:

• analyze_page_seo - gibt Bewertung, fehlende Meta-Tags und Keyword-Dichte zurück
• suggest_internal_links - findet verwandte Inhalte für Cross-Linking
• check_broken_links - scannt nach 404-Fehlern und schlägt Ersatz vor
• generate_schema_markup - erstellt JSON-LD strukturierte Daten
• optimize_images - komprimiert Bilder und ergänzt Alt-Text
• audit_content_freshness - markiert veraltete Inhalte zur Überprüfung

Die lesenden Operationen dieser Liste sind der ideale Einstieg für ein erstes Projekt. Sie liefern strukturierte Ergebnisse, richten bei einem Fehlaufruf keinen Schaden an und zeigen sehr schnell, ob die Schemas praxistauglich geschnitten sind.

#Benutzerdefinierte Abilities in Ihrem Plugin implementieren

#Grundlegende Ability-Registrierung

Eine Ability braucht einen eindeutigen Namen, eine Kategorie, verständliche Metadaten, Schemas, einen Ausführungs-Callback und einen Permission-Callback. Die Kategorie wird zuerst registriert:

<?php
declare(strict_types=1);

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category(
        'redaktion',
        array(
            'label'       => __( 'Redaktion', 'wppoland' ),
            'description' => __( 'Abläufe rund um Entwürfe und Freigaben.', 'wppoland' ),
        )
    );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability(
        'wppoland/liegengebliebene-entwuerfe',
        array(
            'label'         => __( 'Liegengebliebene Entwürfe auflisten', 'wppoland' ),
            'description'   => __( 'Gibt Entwürfe zurück, die seit einer bestimmten Zahl von Tagen unverändert sind.', 'wppoland' ),
            'category'      => 'redaktion',
            'input_schema'  => array(
                'type'       => 'object',
                'properties' => array(
                    'unbearbeitet_seit_tagen' => array(
                        'type'        => 'integer',
                        'minimum'     => 1,
                        'maximum'     => 365,
                        'default'     => 30,
                        'description' => 'Mindestalter der letzten Änderung in Tagen.',
                    ),
                    'max_treffer' => array(
                        'type'        => 'integer',
                        'minimum'     => 1,
                        'maximum'     => 50,
                        'default'     => 20,
                        'description' => 'Obergrenze für die Trefferliste.',
                    ),
                ),
                'required'   => array( 'unbearbeitet_seit_tagen' ),
            ),
            'output_schema' => array(
                'type'       => 'object',
                'properties' => array(
                    'anzahl'    => array( 'type' => 'integer', 'minimum' => 0 ),
                    'entwuerfe' => array(
                        'type'  => 'array',
                        'items' => array(
                            'type'       => 'object',
                            'properties' => array(
                                'id'               => array( 'type' => 'integer' ),
                                'titel'            => array( 'type' => 'string' ),
                                'autor_id'         => array( 'type' => 'integer' ),
                                'letzte_aenderung' => array( 'type' => 'string', 'format' => 'date-time' ),
                            ),
                        ),
                    ),
                ),
            ),
            'execute_callback'    => 'wppoland_liegengebliebene_entwuerfe',
            'permission_callback' => function () {
                return current_user_can( 'edit_others_posts' );
            },
            'meta'                => array(
                'show_in_rest' => false,
                'annotations'  => array(
                    'readonly' => true,
                ),
            ),
        )
    );
} );

Beachten Sie zwei Details. Erstens steht hier show_in_rest bewusst auf false: Solange kein externes System die Operation braucht, ruft anderer PHP-Code sie einfach über wp_get_ability() auf. Zweitens ist die Capability im Permission-Callback an den tatsächlich zurückgegebenen Daten ausgerichtet. Die Liste zeigt fremde Entwürfe, also passt edit_others_posts. Mit manage_options wäre die Hürde ohne Not auf Administratorrechte gesetzt, mit edit_posts bekäme jede Autorenrolle Einblick in unveröffentlichte Texte der Kolleginnen und Kollegen.

#Komposition gehört zum Aufrufer

Der Core liefert Registrierung, Auffindbarkeit, Validierung und Ausführung. Er baut daraus keinen Workflow-Planer, und es gibt kein Feld, mit dem eine Ability andere Abilities als Voraussetzung deklariert. Wenn mehrere Operationen zwingend in fester Reihenfolge laufen müssen, gibt es zwei saubere Wege: eine einzige serverseitige Ability, die den gesamten Vorgang als Transaktion besitzt, oder eine geprüfte Orchestrierungsschicht, die die Einzeloperationen nacheinander aufruft.

Bei gekoppelten Änderungen ist die serverseitige Variante die sicherere. Ein einziger Callback kann die vollständige Eingabe validieren, beim ersten Fehler abbrechen und ein einziges strukturiertes Ergebnis zurückgeben. Komposition auf Client-Seite eignet sich für unabhängige Leseoperationen, verlangt dem Aufrufer aber Teilfehlerbehandlung und eine Wiederholungsstrategie ab.

#Betriebliche Kontrollen explizit ergänzen

Verlassen Sie sich nicht auf undokumentierte Middleware-Hooks. Fachliche Validierung gehört in den Ausführungs-Callback oder in einen Service, den dieser aufruft. Rate-Limiting setzen Sie am Gateway, am Reverse Proxy oder in der Anwendungsschicht durch. Und protokollieren Sie nur die Felder, die das Projekt auch aufbewahren darf.

#Was WordPress 7.1 am 19. August 2026 ergänzt

Für die Abnahme einer Ability ändert sich mit WordPress 7.1 vor allem eine Zeile im Prüfprotokoll. Bisher stand die Freigabeentscheidung ausschließlich in meta['show_in_rest']. Daneben tritt nun ein allgemeiner Schlüssel meta['public'], mit dem ein Plugin einmal erklärt, dass eine Operation für externe Clients gedacht ist, statt dieselbe Entscheidung für jeden künftigen Kanal zu wiederholen.

Für das Review zählt vor allem die Rangfolge, und die Entwicklernotiz formuliert sie unmissverständlich: „Channel-specific settings take precedence over the general public setting.” Die kanalspezifische Einstellung geht der allgemeinen also vor. Im Core steht dahinter genau eine Zeile:

$show_in_rest = $meta['show_in_rest'] ?? $meta['public'] ?? false;

Wer show_in_rest bewusst auf false gesetzt hat, öffnet die Ability mit public nicht versehentlich wieder. Umgekehrt genügt in der Registrierung künftig der allgemeine Schlüssel, solange keine kanalspezifische Ausnahme nötig ist:

'meta' => array(
    'public' => true,
),

Genau hier muss eine Abnahme präzise bleiben. public hält eine Absicht fest: dass diese Operation externen Clients zugänglich sein soll, etwa REST-Konsumenten, MCP-Adaptern oder KI-Agenten. Es bedeutet nicht, dass der Core diese Adapter mitliefert. Auch 7.1 bringt keinen MCP-Server, keine agentenspezifischen OAuth-Scopes, keine Rate-Limits, keinen Audit-Trail und keine Freigabe-Warteschlange mit. Wer das Flag im Abnahmeprotokoll als vorhandene Schnittstelle verbucht, verspricht dem Auftraggeber etwas, das niemand gebaut hat.

#Gefiltertes Auffinden mit wp_get_abilities()

Vor 7.1 musste ein Aufrufer, der nur einen Ausschnitt des Registers brauchte, sämtliche Abilities holen und die Liste anschließend selbst per array_filter() durchsehen. wp_get_abilities() nimmt nun ein optionales $args-Array mit category, namespace, meta, item_include_callback und result_callback entgegen. Die Entwicklernotiz beschreibt die Verknüpfung so: „Conditions are combined using AND logic. An ability must satisfy every supplied argument to be included.” Jede angegebene Bedingung muss also erfüllt sein, damit eine Ability in der Liste erscheint.

Zwei neue Filter, wp_get_abilities_item_include und wp_get_abilities_result, greifen in dieselbe Abfrage ein, und rest_abilities_collection_params erweitert das Argumentschema der REST-Collection. Für das folgende Kapitel ist die Abgrenzung entscheidend: Diese Filter bestimmen, was beim Auffinden zurückkommt. Ob der aktuelle Benutzer eine Operation ausführen darf, entscheidet weiterhin allein der permission_callback.

#Sicherheitsaspekte für extern erreichbare Abilities

#Authentifizierung und Autorisierung

Die REST-Endpoints der Abilities nutzen die REST-Authentifizierung von WordPress. Für Anfragen von derselben Domain steht Cookie-Authentifizierung zur Verfügung, für externen Zugriff sind Anwendungspasswörter dokumentiert, und Projekte können ein eigenes Authentifizierungs-Plugin ergänzen.

Die Authentifizierung beantwortet, wer der Aufrufer ist. Der permission_callback der Ability beantwortet, ob dieser WordPress-Benutzer genau diese Operation ausführen darf. Beide Prüfungen gehören zusammen. Ein geteiltes Administratorkonto hebelt den gesamten Sinn eines eng geschnittenen Ability-Vertrags aus, egal wie sorgfältig die Schemas formuliert sind.

Die REST-Sichtbarkeit ist die dritte Grenze. Registrierte Abilities bleiben intern, solange show_in_rest nicht auf true steht. Nehmen Sie dieses Flag in die Review-Checkliste auf und geben Sie nur frei, was die Integration wirklich benötigt.

#Freigabe für riskante Änderungen

WordPress bringt keine allgemeine Freigabe-Warteschlange für Abilities mit. Wenn eine Rückerstattung, eine Löschung oder eine Einstellungsänderung eine menschliche Bestätigung braucht, bauen Sie diese in der Fachanwendung. Ein bewährtes Muster: Die Ability legt eine Anfrage im Status „ausstehend” an, und ein berechtigter Benutzer bestätigt sie über eine separate Admin-Aktion.

Halten Sie Freigabe und Ausführung strikt getrennt. Der Freigabedatensatz sollte die vorgeschlagene Änderung, den Prüfer, eine Ablaufzeit und eine Prüfsumme der exakten Eingabe festhalten. Wird eine einmal erteilte Freigabe für veränderte Eingaben wiederverwendet, entsteht genau die Lücke, die der Prozess schließen sollte.

#Audit-Trail

Die API erzeugt keinen vollständigen Audit-Trail von selbst. Legen Sie für extern erreichbare Operationen bewusst fest, was aufgezeichnet wird:

• authentifizierter WordPress-Benutzer oder Dienstkonto,
• Name der Ability und Korrelations-ID der Anfrage,
• Ergebniskategorie und Dauer,
• Referenz auf die Freigabe bei sensiblen Änderungen,
• Zeitstempel und relevante Anwendungsversion.

Verzichten Sie auf das Protokollieren von Geheimnissen, vollständigen Prompts oder überflüssigen personenbezogenen Daten. Aufbewahrungsfrist und Zugriff auf die Logs brauchen einen Verantwortlichen, nicht nur eine Datenbanktabelle. In Projekten mit DSGVO-Bezug ist das keine Kür, sondern Teil des Verarbeitungsverzeichnisses.

#Eingabesanitisierung

Die Abilities API validiert Eingaben vor der Ausführung gegen das deklarierte JSON-Schema. Schemavalidierung prüft aber nur die Form. Sie macht eine Zeichenkette nicht für jedes Ziel sicher. Verwenden Sie in den Callbacks weiterhin die Sanitisierungs- und Escaping-Funktionen von WordPress passend zum tatsächlichen Kontext (sanitize_text_field(), wp_kses_post(), esc_url_raw()) und vorbereitete Datenbankabfragen, wo eigene SQL-Zugriffe nötig sind.

#Vergleich mit bestehenden Ansätzen

#REST API vs. Abilities API

#WPGraphQL vs. Abilities API

WPGraphQL glänzt bei flexibler Datenabfrage, weil Clients genau die Daten anfordern, die sie benötigen, in einer einzigen Anfrage. Die Abilities API ist kein Ersatz dafür. Abilities können intern GraphQL für Datenabrufe nutzen und nach außen eine höherstufige Operation anbieten.

Einfach gesagt: GraphQL beantwortet „Welche Daten hast du?” während die Abilities API beantwortet „Was kannst du tun?”

#Wann was verwenden

• REST API: Server-zu-Server-Integrationen, Mobile Apps, traditioneller Frontend-Konsum
• WPGraphQL: Komplexe Datenabfragen, Headless-Frontends, Jamstack-Architekturen
• Abilities API: Anbindung von Agenten, automatisierte Abläufe, auffindbare Operationen

#Wohin sich KI-gesteuerte WordPress-Workflows entwickeln

#Multi-Agent-Orchestrierung

Mit der Reifung von KI-Systemen dürften mehrere spezialisierte Agenten bei WordPress-Aufgaben zusammenarbeiten: einer für Text, einer für Optimierung, einer für Layout und Bilder, einer für Prüfung und Tests. Die Abilities API liefert dafür die gemeinsame Vertragsbasis. Die Koordination selbst findet weiterhin außerhalb von WordPress statt.

#Auswirkungen auf den Marketplace

Das Plugin-Ökosystem wird sich um Ability-Bündel erweitern, also Plugins, die primär existieren, um Operationen für Automatisierung bereitzustellen. Denkbar ist ein Plugin ohne jede Oberfläche, das ausschließlich saubere, dokumentierte SEO-Operationen registriert. Der Wert verschiebt sich damit von menschenorientierten Interfaces zu maschinenlesbaren Verträgen, und die Qualität eines Schemas wird zu einem Verkaufsargument.

#WordPress als KI-Backend

Mit der Abilities API rückt WordPress näher an die Rolle eines orchestrierbaren Backends. Eine Multisite mit WooCommerce, LMS, Mitgliedschaft und Event-Plugins bündelt viele Fachprozesse, die sich als benannte Operationen beschreiben lassen. Der Engpass ist dann nicht mehr die Schnittstelle, sondern die Governance: wer welche Operation freigeben darf und wer die Protokolle liest.

#Integration mit externen KI-Diensten

Es gibt keine allgemeine Funktion, mit der WordPress eine „externe Ability” aufruft. Ein Plugin kann einen externen Dienst über die HTTP API von WordPress ansprechen und diesen Aufruf in eine eigene Ability kapseln. Verantwortlich für Zugangsdaten, Timeouts, Wiederholungen, Kostenkontrolle und Validierung der Antwort bleibt dabei das Plugin.

Halten Sie den externen Aufruf hinter einer eng geschnittenen Fachoperation. Eine Ability namens media/create-approved-variant lässt sich prüfen. Ein allgemeiner Prompt-Weiterleiter, der beliebige Anweisungen entgegennimmt und das Ergebnis direkt in Beitrags-Metadaten schreibt, lässt sich nicht prüfen.

#Was vor der Abnahme einer schreibenden Ability belegt sein muss

In Agenturprojekten entscheidet nicht das Bauchgefühl des Entwicklungsteams darüber, ob eine Ability schreiben darf, sondern die Abnahme. Der Auftraggeber braucht drei belegte Aussagen, und zwar in einer Form, die auch ohne PHP-Kenntnisse nachvollziehbar ist: wer die Operation auslösen darf, welcher Zustand nach einem Abbruch mitten im Vorgang zurückbleibt, und ob die Antwort dem entspricht, was in der Leistungsbeschreibung steht.

Nur die erste Aussage lässt sich vollständig automatisiert belegen. Ein PHPUnit-Test auf Basis von WP_UnitTestCase legt einen Benutzer mit einer definierten Rolle an und prüft, dass der Handler für diese Rolle gar nicht erst anläuft:

public function test_ability_bleibt_fuer_autorenrolle_gesperrt(): void {
    wp_set_current_user( self::factory()->user->create( array( 'role' => 'author' ) ) );

    $ability = wp_get_ability( 'wppoland/liegengebliebene-entwuerfe' );
    $result  = $ability->execute( array( 'unbearbeitet_seit_tagen' => 30 ) );

    $this->assertWPError( $result );
}

Solche Tests laufen bei jedem Release und ergeben ein datiertes Protokoll, das sich einer Abnahme beilegen lässt. Ein einmaliger Klicktest im Staging leistet das nicht, weil er nach der nächsten Rollenänderung im Kundenprojekt nichts mehr aussagt.

Für die zweite Aussage gibt es keine Abkürzung. Der Handler muss einen definierten Zustand hinterlassen, wenn er in der Mitte abbricht, und dieser Zustand gehört schriftlich in die Dokumentation der Operation: entweder teilweise geschrieben und als unvollständig markiert, oder vollständig zurückgerollt. Wer das offenlässt, verschiebt die Frage auf den ersten Störfall, und dann wird sie unter Zeitdruck beantwortet.

Die dritte Aussage betrifft den Vertragscharakter des output_schema. Weicht die tatsächliche Rückgabe davon ab, bricht die aufrufende Kette an einer Stelle, die weit vom Verursacher entfernt liegt, und die Fehlersuche landet zuerst beim falschen Gewerk. Ein Testfall, der eine echte Ausführung gegen das deklarierte Schema hält, kostet wenige Zeilen und macht diese Abweichung sichtbar, bevor der Kunde sie meldet.

#Jetzt loslegen

Für WordPress 6.9 oder neuer:

1. Eine Operation auswählen. Beginnen Sie mit einer kleinen, rein lesenden Ability.
2. Kategorie registrieren. Am Hook wp_abilities_api_categories_init.
3. Ability registrieren. Mit wp_register_ability() am Hook wp_abilities_api_init.
4. Schemas definieren. Ein- und Ausgabe mit JSON Schema beschreiben.
5. Berechtigungen prüfen. Mit berechtigten und unberechtigten Benutzern testen.
6. REST standardmäßig geschlossen lassen. show_in_rest nur für einen echten externen Konsumenten aktivieren.
7. Fehlende Kontrollen ergänzen. Rate-Limits, Audit-Einträge und Freigaben gehören in die Projektarchitektur.

Der praktische Gewinn ist ein einheitlicher Vertrag zwischen WordPress-Komponenten und externer Automatisierung. Dieser Gewinn trägt auch ohne KI-Agenten: Plugins können benannte Operationen finden, deren Schemas lesen und sie über dasselbe Register aufrufen. Wer sein WordPress-Plugin heute so strukturiert, dass Fachlogik und Darstellung getrennt sind, hat den größten Teil der Arbeit bereits erledigt.

Für Unterstützung bei der Umsetzung senden Sie WordPress-Version, Plugin-Liste, geplante Operation, Identität des Aufrufers und den benötigten Datenzugriff über die Kontaktseite. Auch für WordPress-Wartung gilt: Je enger die freigegebene Operation, desto ruhiger der Betrieb.

Geprüft gegen das offizielle Handbuch zur WordPress Abilities API und die Entwicklernotizen zu WordPress 7.0 und 7.1 am 9. August 2026.