WordPress-Abilities filtern und sicher intern bereitstellen

Eine WordPress-Ability ist eine registrierte, beschriebene Funktion, die andere Komponenten gezielt auffinden und ausführen können. Für interne Tools entsteht daraus ein einheitlicher Funktionskatalog: Ein Dashboard kann beispielsweise zulässige Wartungsaktionen anzeigen, ohne deren Implementierung oder Plugin-Struktur kennen zu müssen. Sicher wird dieser Ansatz allerdings erst, wenn du Auswahl und Berechtigung getrennt behandelst.

Warum interne Tools einen begrenzten Funktionskatalog brauchen

Ein internes Werkzeug benötigt selten sämtliche Abilities einer Installation. Ein Redaktions-Dashboard braucht vielleicht eine Aktion zum Erneuern einer Vorschau und eine weitere zum Anstoßen eines Datenimports. Diagnosefunktionen, Exporte oder Aktionen anderer Plugins gehören dort nicht hinein.

Ohne eine zentrale Auswahlregel entsteht die Begrenzung häufig direkt in der Oberfläche. Dort werden Namen verglichen, einzelne Funktionen ausgeschlossen oder erlaubte Einträge fest verdrahtet. Sobald ein zweites internes Tool hinzukommt, wird dieselbe Logik erneut implementiert. Änderungen verteilen sich dann über mehrere Stellen.

Die bessere Grenze ist eine ausdrückliche Positivauswahl: Das Tool fragt nur nach Abilities, die für seinen Zweck vorgesehen sind. Alles andere bleibt außerhalb des Katalogs. Diese Auswahl verbessert Übersicht und Pflege, ist aber noch keine Zugriffskontrolle.

Was sich mit WordPress 7.1 bei wp_get_abilities() ändert

Die Funktion wp_get_abilities() dient dazu, registrierte Abilities zu ermitteln. Die offizielle Funktionsdokumentation nennt dafür unter anderem Debugging und administrative Oberflächen als Anwendungsfälle.

Für WordPress 7.1 erweitert WordPress die Abfrage um Filtermöglichkeiten nach Kategorie, Namespace und Metadaten. Hinzu kommen Callbacks, mit denen sich einzelne Treffer prüfen und das Gesamtergebnis weiterverarbeiten lassen. Die Details beschreibt der Core-Beitrag zur erweiterten Ability-Filterung.

Damit kann die Auswahl näher an die Registry rücken. Ein internes Dashboard muss nicht erst alle registrierten Abilities laden und anschließend an mehreren Stellen eigene Auswahlregeln anwenden. Es formuliert stattdessen, welchen Ausschnitt des Katalogs es benötigt.

Für bestehende Projekte bedeutet das keinen Zwang zum sofortigen Umbau. Falls deine Installation noch nicht auf WordPress 7.1 basiert, kannst du die Auswahl vorübergehend in einer projektspezifischen Adapterfunktion kapseln. Nach dem Update wird nur dieser Adapter auf die neue Abfrage umgestellt. So vermeidest du parallele Filterlogik in Dashboard, Kommandozeilenwerkzeug und Hintergrundprozess.

Namespace, Kategorie und Metadaten haben unterschiedliche Aufgaben

Die Filter lassen sich am besten nutzen, wenn jedes Merkmal genau eine fachliche Bedeutung hat. Ein Sammelfeld mit wechselnder Interpretation wird schnell so verständlich wie eine beschriftete Kabelkiste nach drei Büroumzügen.

Namespace: Wer verantwortet die Ability?

Der Namespace grenzt Abilities nach ihrem technischen Ursprung oder Verantwortungsbereich ein. Ein projektspezifisches Plugin könnte beispielsweise den Namespace projekt-redaktion verwenden. Ein internes Redaktionswerkzeug fragt dann nur Abilities aus diesem Bereich ab und ignoriert Funktionen fremder Plugins.

Das ist besonders nützlich, wenn mehrere Erweiterungen ähnliche Kategorien verwenden. Die Kategorie „Wartung“ sagt wenig darüber aus, welchem Plugin eine Aktion gehört. Der Namespace beantwortet diese Frage eindeutiger.

Kategorie: Welchem Arbeitsbereich dient die Funktion?

Kategorien ordnen Abilities nach ihrem fachlichen Zweck. Mögliche projektspezifische Kategorien wären etwa Redaktion, Datenpflege oder Support. Eine Oberfläche für Redakteure kann dadurch Funktionen verschiedener eigener Module zusammenführen, solange sie demselben Arbeitsbereich dienen.

Kategorien eignen sich nicht als Rollenmodell. Die Zuordnung zur Kategorie „Redaktion“ belegt lediglich, dass eine Funktion thematisch dorthin gehört. Sie sagt nicht, ob die aktuell angemeldete Person sie ausführen darf.

Metadaten: Für welchen Nutzungskontext ist die Ability vorgesehen?

Metadaten können die Auswahl um projektbezogene Merkmale ergänzen. Du könntest beispielsweise kennzeichnen, ob eine Ability in einem internen Dashboard erscheinen darf, ob sie einen besonders sensiblen Vorgang auslöst oder für einen bestimmten Kanal gedacht ist. Die konkreten Schlüssel und Werte sollten im Projekt verbindlich definiert und dokumentiert werden.

Eine sinnvolle Auswahl für ein kleines internes Werkzeug könnte konzeptionell so aussehen:

• Namespace entspricht dem eigenen Projekt- oder Plugin-Bereich.
• Kategorie entspricht dem Arbeitsbereich des Dashboards.
• Das Metadatum für die interne Anzeige ist ausdrücklich aktiviert.
• Abilities ohne vollständige Kennzeichnung werden nicht angezeigt.

Der letzte Punkt ist wichtig: Fehlende Metadaten sollten nicht versehentlich als Zustimmung gelten. Bei einem internen Funktionskatalog ist eine explizite Freigabe leichter zu prüfen als eine ständig wachsende Ausschlussliste.

Callbacks: Sonderregeln an einer Stelle bündeln

Ein Prüf-Callback kann zusätzliche Auswahlregeln abbilden, die sich nicht sauber durch Namespace, Kategorie oder Metadaten ausdrücken lassen. Denkbar wäre etwa, nur Abilities mit vollständig hinterlegten Beschreibungen und erwarteten Eingabeinformationen in einer automatisch erzeugten Oberfläche zuzulassen.

Die Ergebnisverarbeitung kann anschließend sortieren oder gruppieren. So erscheinen redaktionelle Aktionen gemeinsam und mit einer stabilen Reihenfolge. Diese Verarbeitung betrifft die Darstellung des Katalogs. Sie darf nicht zur einzigen Sicherheitsprüfung einer Aktion werden.

Praxisentwurf: Ein Dashboard zeigt nur freigegebene Abilities

Angenommen, ein internes WordPress-Dashboard soll zwei wiederkehrende Aufgaben anbieten: eine redaktionelle Vorschau erneuern und einen Produktfeed neu erzeugen. Gleichzeitig existiert eine Ability für einen personenbezogenen Datenexport. Diese dritte Funktion soll weder sichtbar noch über das Dashboard ausführbar sein.

Der Ablauf lässt sich ohne individuelle Sonderlogik pro Ability aufbauen:

1. Auswahlrichtlinie festlegen: Das Dashboard akzeptiert nur den eigenen Namespace, definierte Kategorien und eine ausdrücklich gesetzte Dashboard-Freigabe in den Metadaten.
2. Ability-Katalog abfragen: wp_get_abilities() liefert nur die Einträge, die zu dieser Richtlinie passen.
3. Einträge serverseitig aufbereiten: Das Tool gruppiert die Treffer und erzeugt aus ihren Beschreibungen verständliche Schaltflächen. Interne Namen bleiben technische Bezeichner und werden nicht ungeprüft als Beschriftung verwendet.
4. Berechtigung bei der Ausführung prüfen: Jeder Aufruf wird erneut gegen die Berechtigung der aktuellen Person geprüft. Das gilt auch dann, wenn die Schaltfläche nur berechtigten Rollen angezeigt wurde.
5. Eingaben validieren: Parameter werden anhand der erwarteten Struktur geprüft. Ein frei befüllbares Textfeld ist kein Ersatz für definierte Eingaben.
6. Ergebnis kontrolliert darstellen: Rückgaben werden für die jeweilige Ausgabe behandelt. Interne Fehlermeldungen und sensible Daten gehören nicht ungefiltert in die Oberfläche.

Der Datenexport bleibt außerhalb des abgefragten Katalogs, weil ihm die passende Dashboard-Freigabe fehlt. Seine eigene Berechtigungsprüfung muss trotzdem bestehen bleiben. Schließlich könnte die Ability an anderer Stelle aufgerufen werden.

Für riskante oder schwer umkehrbare Aktionen kann zusätzlich eine fachliche Bestätigung nötig sein. Wie du solche Entscheidungen gestaltest, hängt vom Schaden eines Fehlers ab; dazu passt der weiterführende Artikel über Freigabeschritte in Automationen.

Auffindbarkeit, REST-Sichtbarkeit und Berechtigung trennen

Bei der Absicherung helfen drei getrennte Fragen:

• Soll das interne Tool die Ability finden? Das bestimmen die Filter für Namespace, Kategorie, Metadaten und gegebenenfalls ein zusätzlicher Prüf-Callback.
• Soll die Ability über REST erreichbar sein? Das entscheidet die REST-Konfiguration.
• Darf die aktuelle Person die Ability jetzt ausführen? Das entscheidet die Berechtigungsprüfung am konkreten Aufruf.

Bei einer REST-Bereitstellung sind Sichtbarkeit und Ausführungsberechtigung ausdrücklich getrennt. Nach der WordPress-Dokumentation zu Ability-Endpunkten steuert show_in_rest die REST-Exposition, während permission_callback die Ausführung absichert.

Eine Ability kann also im gefilterten Katalog eines Tools erscheinen und trotzdem nicht über REST bereitgestellt werden. Umgekehrt darf eine über REST sichtbare Ability nicht allein deshalb ausgeführt werden. Ebenso wenig bedeutet ein Metadatum wie internal_dashboard = true, dass eine Person automatisch berechtigt ist.

Auch ein WordPress-Nonce ersetzt die Berechtigungsprüfung nicht. Ein Nonce schützt einen Request insbesondere gegen unbeabsichtigte oder untergeschobene Aufrufe aus einer anderen Sitzungssituation. Ob die handelnde Person die Aktion fachlich ausführen darf, muss die Anwendung separat prüfen.

Wann ein interner PHP-Aufruf sinnvoller als REST ist

Die technische Bereitstellung sollte sich danach richten, wo der Aufruf stattfindet. REST ist kein obligatorischer Bestandteil eines Ability-basierten internen Werkzeugs.

PHP-Aufruf innerhalb von WordPress

Ein interner PHP-Aufruf passt, wenn Oberfläche und Ausführung im selben WordPress-System liegen. Das betrifft beispielsweise eine eigene Administrationsseite, einen geplanten Hintergrundprozess oder ein Kommandozeilenwerkzeug innerhalb der Installation.

Vorteile sind ein kleinerer öffentlich erreichbarer Umfang und der direkte Zugriff auf den bestehenden WordPress-Kontext. Du musst keinen REST-Endpunkt bereitstellen, wenn kein separater Client ihn benötigt. Berechtigungen, Eingaben und Fehlerbehandlung bleiben trotzdem verpflichtend.

REST für getrennte Clients

REST ist sinnvoll, wenn ein separates Frontend, ein internes Portal oder ein anderes System die Ability aufrufen soll. Dann brauchst du einen klaren Vertrag für Authentifizierung, Berechtigungen, Eingaben, Rückgaben und Fehlerfälle.

Die Entscheidung für REST sollte pro Ability fallen. Eine reine Lesefunktion für ein internes Portal hat ein anderes Risikoprofil als eine Aktion, die Daten löscht, exportiert oder an Dritte übermittelt. Du musst daher nicht den gesamten gefilterten Katalog über denselben Kanal veröffentlichen.

Eine einfache Entscheidungsregel

Bleibt der Aufruf vollständig innerhalb derselben WordPress-Installation, beginne mit einer internen PHP-Integration. Benötigt ein tatsächlich getrenntes System die Funktion, prüfe eine gezielte REST-Bereitstellung. „Vielleicht brauchen wir später eine App“ ist noch keine technische Anforderung.

Checkliste für die Umsetzung

• Definiere den konkreten Zweck des internen Tools, bevor du Abilities auswählst.
• Verwende Namespaces für technische Zuständigkeiten und Kategorien für fachliche Bereiche.
• Lege dokumentierte Metadaten für Nutzungskontexte wie interne Dashboards fest.
• Arbeite mit einer Positivauswahl: Nur ausdrücklich vorgesehene Abilities erscheinen.
• Kapsle die Ability-Abfrage, falls du unterschiedliche WordPress-Versionen unterstützen musst.
• Behandle Filter-Callbacks als Auswahlhilfe, nicht als Autorisierung.
• Prüfe die Berechtigung bei jeder Ausführung erneut.
• Validiere Eingaben und kontrolliere Ausgaben unabhängig vom Aufrufkanal.
• Aktiviere eine REST-Bereitstellung nur für Abilities, die ein getrennter Client wirklich benötigt.
• Prüfe bei riskanten Aktionen, ob zusätzlich eine Bestätigung oder fachliche Freigabe erforderlich ist.

Fazit: Der Filter baut den Katalog, die Berechtigung schützt die Aktion

Die erweiterten Filter von wp_get_abilities() in WordPress 7.1 helfen dir, einen gezielten Ability-Katalog für interne Werkzeuge zusammenzustellen. Namespace, Kategorie und Metadaten beantworten, welche Funktionen ein Tool auffinden und anzeigen soll. Callbacks ergänzen projektspezifische Auswahl- und Darstellungsregeln.

Die Sicherheitsgrenze liegt weiterhin an der Ausführung. Eine gefilterte Ability ist weder automatisch für REST geeignet noch automatisch für die aktuelle Person erlaubt. Wenn du Auffindbarkeit, Bereitstellung und Berechtigung als getrennte Entscheidungen behandelst, bleibt das interne Tool übersichtlich, ohne seine Oberfläche mit einer Zugriffskontrolle zu verwechseln.