WordPress Abilities API

WordPress Abilities API er et register over operasjoner som en utvidelse, et tema eller kjernen selv deklarerer i ett forutsigbart format: navn, kategori, skjema for input og output, tilgangssjekk og en funksjon som utfører jobben. Denne siden er en referanse: hva API-et er, hvordan du registrerer en ability, hvilke REST-endepunkter som finnes, hvordan tilganger virker, hva versjon 7.0 og 7.1 la til, og hvor MCP Adapter kommer inn. Ser du etter eksempler på arbeidsflyter bygget på abilities, finner du dem i artikkelen KI-arbeidsflyter i WordPress med Abilities API.

#Hva er WordPress Abilities API

Dev note-en på make.wordpress.org definerer en enkelt ability slik:

“En ability er en selvstendig funksjonsenhet med definerte inndata, utdata, tillatelser og kjørelogikk.”

Jonathan Bossenger, Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

Alle registrerte abilities havner i et sentralt register. Det registeret brukes av PHP-kode på serveren, JavaScript-klienten i adminpanelet, REST API og KI-agenter koblet til via MCP Adapter. Utvidelsen beskriver operasjonen én gang, og hver av disse kanalene ser den i samme form, med samme skjema og samme tilgangssjekk.

Lanseringsnyheten for 6.9 beskriver det fra tilgangssiden:

“Det nye Abilities API gir et standardisert, maskinlesbart tillatelsessystem som åpner for neste generasjons AI-drevne og automatiserte arbeidsflyter.”

WordPress News, WordPress 6.9 “Gene”, egen oversettelse

Hver ability tilhører nøyaktig én kategori:

“Hver ability må tilhøre nøyaktig én kategori. Kategorier har en slug, en etikett og en beskrivelse.”

Common APIs Handbook, Abilities API, egen oversettelse

#Hvilken WordPress-versjon har Abilities API

Abilities API kom inn i kjernen med WordPress 6.9, som ble lansert 2. desember 2025. Handbook-en sier det rett ut i en boks øverst på siden:

“Abilities API er bare tilgjengelig for WordPress 6.9 og nyere.”

Common APIs Handbook, Abilities API, egen oversettelse

Senere versjoner har bygget ut API-et uten å endre grunnmuren:

En utvidelse som også skal kjøre på installasjoner eldre enn 6.9, sjekker at funksjonen finnes før registreringen: dev note-en på make.wordpress.org anbefaler betingelsen function_exists( 'wp_register_ability' ), og det er også den eksemplet nedenfor starter med.

Den bredere sammenhengen rundt 7.0, inkludert resten av KI-endringene, finner du i vår guide til WordPress 7.0 og KI-integrasjon.

#Slik registrerer du en ability i WordPress

Registreringen har to steg: først kategorien, så selve abilityen. Hvert steg har sin egen hook, og rekkefølgen betyr noe.

#Registrere en kategori for abilities

“Kategorier må registreres før de abilities som refererer til dem, ved hjelp av hooken wp_abilities_api_categories_init.”

Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

En kategori har slug, etikett og beskrivelse. Argumentet category er påkrevd når du registrerer en ability, og det må peke på slugen til en kategori som allerede ligger i registeret.

#Hooken wp_abilities_api_init

Selve abilityen registreres på en egen action. Registrering et annet sted går ikke gjennom:

“Abilities må registreres på action-hooken wp_abilities_api_init. Forsøk på å registrere abilities utenfor denne hooken vil utløse en _doing_it_wrong()-melding, og registreringen av abilityen vil mislykkes.”

Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

#Eksempel på wp_register_ability

Funksjonssignaturen ifølge Code Reference:

function wp_register_ability( string $name, array $args ): ?WP_Ability {

Kilde: Code Reference, wp_register_ability().

Ved suksess returnerer funksjonen den registrerte WP_Ability-instansen, ved feil null. Et minimalt eksempel: en kategori og én skrivebeskyttet ability som returnerer antall publiserte innlegg.

if ( function_exists( 'wp_register_ability' ) ) {

	add_action( 'wp_abilities_api_categories_init', function () {
		wp_register_ability_category( 'moja-wtyczka', array(
			'label'       => 'Moja wtyczka',
			'description' => 'Operacje udostępniane przez Moją wtyczkę.',
		) );
	} );

	add_action( 'wp_abilities_api_init', function () {
		wp_register_ability( 'moja-wtyczka/liczba-wpisow', array(
			'label'               => 'Liczba opublikowanych wpisów',
			'description'         => 'Zwraca liczbę opublikowanych wpisów.',
			'category'            => 'moja-wtyczka',
			'output_schema'       => array( 'type' => 'integer' ),
			'permission_callback' => function () {
				return current_user_can( 'edit_posts' );
			},
			'execute_callback'    => function () {
				return (int) wp_count_posts()->publish;
			},
			'meta'                => array(
				'show_in_rest' => true,
				'annotations'  => array( 'readonly' => true ),
			),
		) );
	} );
}

Denne abilityen tar ikke imot data, så den har ingen input_schema. Den returnerer en verdi, så output_schema er obligatorisk.

#Navn og navnerom for en ability

“Formatet skal være namespace/ability-name”

Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

Navnet består av små bokstaver, tall, bindestreker og en skråstrek. Navnerommet er som regel slugen til utvidelsen, noe som hindrer kollisjoner mellom utvidelser som registrerer lignende operasjoner.

#input_schema og output_schema

Skjemaene er ikke pynt for dokumentasjonen. Kjernen validerer input mot dem før kjøring og output etter kjøring.

“Det er obligatorisk å definere skjemaer når det finnes en verdi som skal sendes inn eller returneres.”

Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

Validatoren støtter ikke hele JSON Schema-spesifikasjonen:

“WordPress implementerer en validator basert på et delsett av JSON Schema versjon 4.”

Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

I praksis betyr det å skrive skjemaene i draft 4-syntaks og være forsiktig med nøkkelord utenfor dette utvalget.

#permission_callback og execute_callback

Begge callbackene er påkrevd. Code Reference beskriver dem slik:

“Påkrevd. En callback-funksjon som sjekker tillatelser før kjøring.”

Code Reference, wp_register_ability(), egen oversettelse

“Påkrevd. En callback-funksjon som kjøres når abilityen blir kalt.”

Code Reference, wp_register_ability(), egen oversettelse

Tilgangs-callbacken ser de samme dataene som kjøre-callbacken, så den kan ta en avgjørelse ut fra konkret input, for eksempel bare tillate redigering av et innlegg brukeren selv er forfatter av:

“Den mottar samme inndata som execute-callbacken og må returnere en boolean eller WP_Error”

Code Reference, wp_register_ability(), egen oversettelse

#Feilhåndtering i execute_callback

En feil returneres som et objekt, ikke som et unntak eller et tomt resultat:

“Abilities bør håndtere feil på en kontrollert måte ved å returnere WP_Error-objekter:”

Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

#Annotasjonene readonly, destructive og idempotent

Annotasjonene i meta.annotations beskriver hva slags operasjon det er. readonly betyr en ability som ikke endrer noe:

“Valgfri. Hvis true, endrer ikke abilityen omgivelsene sine.”

Code Reference, wp_register_ability(), egen oversettelse

De to andre annotasjonene er destructive og idempotent. De er ikke pynt: de styrer HTTP-metoden ved kall via REST, og en klient, for eksempel en KI-agent, kan bruke dem til å vurdere om operasjonen trygt kan gjentas.

Denne nettsiden kjører vår egen MCP-server, beskrevet i /.well-known/mcp/server-card.json, og den eksponerer bare lesende verktøy. Samme prinsipp fungerer for abilities, og passer godt for et lite team som vil komme i gang uten stor risiko: første versjon av en agentintegrasjon er abilities med readonly: true, kalt med GET. Skriveoperasjoner kommer senere, hver med sin egen permission_callback.

#REST-endepunkter i Abilities API

I WordPress 6.9 havner en ability ikke automatisk i REST API. Det må deklareres:

“Dette er mulig ved å sette argumentet meta.show_in_rest til true når en ability registreres.”

Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

Endepunktene ligger i navnerommet wp-abilities/v1: liste over abilities, én enkelt ability og kjøring. Kjørestien ser slik ut:

GET|POST|DELETE /wp-abilities/v1/abilities/{name}/run

Kilde: Make WordPress Core, Abilities API in WordPress 6.9.

#Autentisering i Abilities API

“Tilgang til alle REST API-endepunkter for Abilities krever en autentisert bruker.”

Make WordPress Core, Abilities API in WordPress 6.9, egen oversettelse

Det gjelder også listen over abilities. Sesjonscookie, application passwords eller en egen autentiseringsmekanisme fungerer. En anonym klient får ikke engang se hvilke abilities som finnes på nettstedet.

#Slik kaller du en ability via REST

HTTP-metoden for endepunktet run bestemmes av annotasjonene. En readonly-ability kalles med GET, en ability som er både destructive og idempotent med DELETE, og i alle andre tilfeller:

“Alle andre tilfeller: bruker POST”

Jorge Costa, Make WordPress Core, Client-Side Abilities API in WordPress 7.0, egen oversettelse

REST-dokumentasjonen i prosjektets repo understreker at dette er et krav for skrivebeskyttede abilities, ikke en anbefaling:

”- Skrivebeskyttede abilities må bruke GET (readonly: true)”

GitHub, WordPress/abilities-api, docs/rest-api.md, egen oversettelse

Ved GET og DELETE sendes input ikke i forespørselens body, men i parameteren input som URL-kodet JSON.

#Abilities API i JavaScript

WordPress 7.0 la til en klient i nettleseren, fordelt på to pakker. @wordpress/abilities er selve lageret for abilities, mens @wordpress/core-abilities henter abilities registrert på serveren via REST:

“Dette laster både @wordpress/core-abilities og avhengigheten @wordpress/abilities, og henter og registrerer automatisk alle abilities fra serversiden.”

Jorge Costa, Make WordPress Core, Client-Side Abilities API in WordPress 7.0, egen oversettelse

Feil i JS-klienten har faste koder. Mislykket validering gir ability_invalid_input eller ability_invalid_output, og avvist tilgang:

“Hvis permission-callbacken returnerer false, kastes en feil med koden ability_permission_denied.”

Jorge Costa, Make WordPress Core, Client-Side Abilities API in WordPress 7.0, egen oversettelse

#Hva er nytt i Abilities API i WordPress 7.1

Lanseringsnyheten for 7.1 oppsummerer endringene i én setning:

“Abilities API bygger på infrastrukturen som ble introdusert i WordPress 6.9, med en filtrerbar kjøringslivssyklus, tilpasset validering og felles oppdagelse.”

WordPress News, WordPress 7.1 “Mary Lou”, egen oversettelse

#Flagget public i Abilities API

WordPress 7.1 innførte meta.public, et felles eksponeringsflagg for klienter. Det fyller ut show_in_rest, men en eksplisitt angitt show_in_rest går foran, og standardverdien er fortsatt false:

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

Kilde: Milana Cap, Make WordPress Core, A unified public exposure flag for Abilities in WordPress 7.1.

Flagget styrer synlighet, ikke tilgang:

“Flagget public styrer oppdagbarhet og eksponering mot klienter.”

Milana Cap, Make WordPress Core, A unified public exposure flag for Abilities in WordPress 7.1, egen oversettelse

En ability merket som offentlig går fortsatt gjennom permission_callback. Flagget public erstatter den ikke.

#Filtre for kjøringen av en ability

“Abilities API tilbød tidligere actionene wp_before_execute_ability og wp_after_execute_ability.”

Make WordPress Core, New execution lifecycle filters for the Abilities API in WordPress 7.1, egen oversettelse

I tillegg til disse to actionene fra 6.9 la versjon 7.1 til fire filtre:

Actionene lot deg bare observere kjøringen. Filtrene lar deg gripe inn, for eksempel normalisere input eller endre resultatet av tilgangssjekken.

#Abilities API og MCP Adapter

Abilities API inneholder ingen Model Context Protocol-server. Den rollen har en egen pakke:

“Den offisielle WordPress-pakken for MCP-integrasjon, som eksponerer WordPress-abilities som Model Context Protocol (MCP)-verktøy, -ressurser og -prompter for AI-agenter.”

GitHub, WordPress/mcp-adapter, README, egen oversettelse

Standardinnstillingen er forsiktig:

“WordPress-abilities er private som standard.”

GitHub, WordPress/mcp-adapter, README, egen oversettelse

For at en ability skal være synlig for en MCP-klient, må meta.public (eller meta.mcp.public) settes til true. Adapterens standardserver eksponerer tre meta-verktøy som agenten bruker til å finne og kalle abilities. Tilkobling:

“Koble til via WP-CLI over STDIO, eller pek en HTTP-klient mot /wp-json/mcp/mcp-adapter-default-server.”

GitHub, WordPress/mcp-adapter, README, egen oversettelse

STDIO via WP-CLI passer for lokalt arbeid og staging, HTTP for en agent som kjører utenfor serveren. I begge tilfeller er det de samme permission_callback-ene og annotasjonene beskrevet ovenfor som avgjør hva agenten får lov til.

Mer om hvordan du kobler WordPress til KI-agenter via MCP, står i guiden MCP- og KI-integrasjon i WordPress. Trenger du en egen MCP-server eller et sett abilities tilpasset en bestemt nettbutikk eller tjeneste, har vi beskrevet det på siden utvikling av MCP-server for WordPress.

#Hvordan sjekke om WordPress støtter Abilities API

Enklest i koden: function_exists( 'wp_register_ability' ) returnerer true fra versjon 6.9. Fra utsiden, med en konto som har et application password, holder det å spørre etter navnerommet wp-abilities/v1 i nettstedets REST API. Finnes det ikke, kjører nettstedet en versjon eldre enn 6.9, eller noe blokkerer REST API. Listen viser bare abilities med show_in_rest eller public satt til true, så en tom liste betyr ikke at utvidelsene ikke registrerer noen abilities.

Sist verifisert mot kildene: 6. oktober 2026.