Das Kennzeichen „public“ in der Abilities API von WordPress 7.1: Was es freigibt und was trotzdem gesperrt bleibt

„Public“ heißt in der Abilities API nicht „darf jeder“. Das Kennzeichen, das WordPress 7.1 am 19.08.2026 eingeführt hat, regelt ausschließlich, ob eine Fähigkeit für externe Clients sichtbar und erreichbar ist, also für die REST-Schnittstelle, den MCP-Adapter und damit für KI-Agenten. Ob der Aufruf dann tatsächlich ausgeführt wird, entscheidet weiterhin allein die Rechteprüfung der Fähigkeit, und die läuft bei jedem Aufruf gegen den angemeldeten Benutzer. Wer das verwechselt, baut entweder zu viel Angst auf oder zu wenig Schutz ein. Dieser Beitrag ist der Teil der Betriebsanleitung für KI-Agenten in WordPress, der sich mit den Metadaten beschäftigt.

Drei Ebenen, eine Rangfolge

Vor 7.1 gab es nur show_in_rest: wahr oder falsch, bezogen auf die REST-Schnittstelle. Der MCP-Adapter brachte sein eigenes Kennzeichen mcp.public mit. Plugin-Autoren mussten also für jeden Kanal getrennt entscheiden, und das Core-Team hat mit dem Vorschlag vom 04.08.2026 ein gemeinsames Dach darüber gesetzt:

1. meta.public ist die allgemeine Absicht: „Diese Fähigkeit ist für externe Clients gedacht.“ Fehlt die Angabe, ist die Fähigkeit nicht öffentlich.
2. meta.show_in_rest ist die kanalspezifische Entscheidung für REST. Sie hat Vorrang. Ein ausdrückliches „falsch“ bleibt erhalten, auch wenn „public“ wahr ist.
3. meta.mcp.public ist dieselbe Logik für den MCP-Kanal. Der offizielle Adapter respektiert seit Version 0.6 die Regel: alles, was „public“ ist, erscheint im Standardserver, es sei denn, mcp.public sagt ausdrücklich nein.

Die Auflösung ist in einer Zeile beschrieben: Erst der kanalspezifische Wert, dann der allgemeine, dann die Voreinstellung „falsch“. Ein leerer Wert fällt durch, ein gesetztes „falsch“ nicht. Die drei Kernfähigkeiten core/get-site-info, core/get-user-info und core/get-environment-info wurden mit 7.1 auf dieses Kennzeichen umgestellt.

Warum „public“ keine Rechte vergibt

Der Satz steht so im Vorschlag des Core-Teams, und er ist der wichtigste des ganzen Themas: Das Kennzeichen steuert Auffindbarkeit und Erreichbarkeit, nicht Ausführbarkeit. Jede Fähigkeit bringt ihren eigenen Permission Callback mit, eine Funktion, die bei jedem Aufruf entscheidet, ob der aktuelle Benutzer darf. Die Beispiele der Dokumentation prüfen etwa current_user_can('manage_options') oder current_user_can('export'). Ein Agent, der als Redakteur angemeldet ist, sieht eine öffentliche Export-Fähigkeit in der Liste, bekommt beim Aufruf aber die Antwort ability_invalid_permissions.

Das hat zwei Folgen für Betreiber. Erstens: Die Liste unter /wp-json/wp-abilities/v1/abilities zeigt, was ein Agent sehen kann, nicht, was er tun kann. Zweitens: Die Qualität der Rechteprüfung ist Sache des Plugin-Autors. Eine Fähigkeit, deren Callback schlicht „wahr“ zurückgibt, ist für jeden angemeldeten Benutzer ausführbar, sobald sie öffentlich ist. Das ist kein Fehler der API, sondern derselbe Zustand, den die REST-Schnittstelle seit Jahren hat.

Die drei Hinweise: readonly, destructive, idempotent

Neben dem Kennzeichen tragen Fähigkeiten Anmerkungen, die dem Client sagen, womit er rechnen muss:

• readonly: Die Fähigkeit ändert nichts. Die REST-Schnittstelle führt sie per GET aus.
• destructive: Die Fähigkeit löscht oder zerstört. REST verlangt DELETE.
• idempotent: Ein zweiter Aufruf mit denselben Eingaben ändert nichts mehr. Wichtig für Agenten, die nach einem Zeitüberschreitungsfehler wiederholen.

WooCommerce zeigt mit seinen sieben Fähigkeiten aus Version 10.9, wie das in der Praxis aussieht: Produkt- und Bestellabfragen sind readonly und idempotent, Produkt löschen ist destructive und idempotent, Bestellstatus ändern ist ebenfalls als destructive markiert, Produkt anlegen ist weder das eine noch das andere. Ein gut gebauter Client fragt vor destruktiven Aufrufen nach. Nur sind die Anmerkungen Erklärungen des Autors, keine Prüfung durch WordPress. Eine als readonly markierte Fähigkeit, die trotzdem schreibt, wird nicht gestoppt.

Was 7.1 sonst noch für die Kontrolle mitbringt

Der Beitrag des Core-Teams vom 31.07.2026 listet vier Ergänzungen, die für Betreiber mit Entwicklerunterstützung interessant sind:

• Die Filter wp_ability_validate_input und wp_ability_validate_output ergänzen die Schemaprüfung um eigene Regeln, etwa „keine Beiträge in dieser Kategorie“.
• Die Aktion wp_ability_invoked feuert zu Beginn jeder Ausführung und ist der vorgesehene Ort für Protokolle.
• Die Aktionen wp_before_execute_ability und wp_after_execute_ability erhalten die Fähigkeit als zusätzliches Argument.
• Ein Parameter fields erlaubt Clients, nur bestimmte Felder abzufragen, etwa den Seitennamen ohne die Umgebungsdaten.

Zusammen ergibt das einen brauchbaren Kontrollkasten: Sichtbarkeit über „public“, Rechte über den Callback, Zusatzregeln über die Filter, Protokoll über die Aktion. Was WordPress nicht liefert, ist eine Oberfläche dafür. Alles davon ist Code. Für Betreiber ohne Entwickler bleiben die Hebel, die ich im Beitrag zu Anwendungspasswörtern und Rollen beschreibe.

Quellen

• Make WordPress Core: A unified public exposure flag for Abilities in WordPress 7.1 (04.08.2026)
• Make WordPress Core: Abilities API improvements in WordPress 7.1 (31.07.2026)
• WordPress Developer Resources: Abilities API, REST API endpoints

Kurz beantwortet

Macht „public“ eine Fähigkeit für jeden nutzbar?

Nein. Es macht sie für Clients sichtbar und erreichbar. Ausführen darf nur ein angemeldeter Benutzer, der die Rechteprüfung der Fähigkeit besteht.

Kann ich eine Fähigkeit nur für REST, nicht für MCP freigeben?

Ja. show_in_rest und mcp.public gelten je Kanal und haben Vorrang vor dem allgemeinen Kennzeichen.

Sind die Hinweise readonly und destructive verlässlich?

Sie sind Angaben des Plugin-Autors und steuern in REST die HTTP-Methode. WordPress prüft nicht, ob sich die Fähigkeit daran hält.