---
tittel: "WordPress 7.0 AI-klienten sett fra et utviklerperspektiv — isla Studio"
url: "https://isla-stud.io/en/allgemein/wordpress-7-ai-client-developer/"
dato: 2026-03-28
---
# WordPress 7.0 AI-klienten sett fra et utviklerperspektiv
WordPress 7.0 kommer med en innebygd AI-klient. Ikke som et plugin, ikke som en eksperimentell funksjonsflagg, men som en del av kjernen. Det er et klart signal.
Jeg har utviklet WordPress-plugins siden 2009 og har selv laget et AI-plugin med [citelayer®](https://citelayer.ai), som er direkte berørt av denne arkitekturbeslutningen. Her er min tekniske analyse: Hva kan API-et, hvor ligger styrkene, og hva må plugin-utviklere vite?
Inngangspunktet: `wp_ai_client_prompt()`
----------------------------------------
Alt starter med én enkelt funksjon:
```
$builder = wp_ai_client_prompt();
```
Dette returnerer et `WP_AI_Client_Prompt_Builder`-objekt – en 'Fluent Builder' som kobler sammen prompt, konfigurasjon og genereringsmetode. Grunnprinsippet: Utvikleren beskriver **hva** han trenger. WordPress tar seg av **hvordan**.
Et enkelt eksempel på tekstgenerering:
```
// Prompt direkte som parameter — praktisk for enkle tilfeller
$text = wp_ai_client_prompt( 'Oppsummer fordelene med caching i WordPress.' )
->using_temperature( 0.7 )
->generate_text();
// Feilhåndtering som overalt i WordPress: Sjekk WP_Error
if ( is_wp_error( $text ) ) {
return;
}
echo wp_kses_post( $text );
```
Promptteksten kan angis som parameter eller via `with_text()` — det siste er nyttig når prompten settes sammen dynamisk.
Mer enn tekst: bilde, språk, video
-----------------------------------
API-et er multimodalt. Bildegenerering fungerer etter samme mønster:
```
use WordPress\AiClient\Files\DTO\File;
$image = wp_ai_client_prompt( 'Et futuristisk WordPress-logo i neonstil' )
->generate_image();
if ( is_wp_error( $image ) ) {
return;
}
// Fil-DTO med Data URI — kan brukes direkte
echo '';
```
For variasjoner finnes `generate_images( 4 )` og `generate_texts( 4 )`. I tillegg kommer `convert_text_to_speech_result()`, `generate_speech_result()` og `generate_video_result()`. WordPress dekker dermed alle vanlige modaliteter.
Spesielt spennende: multimodal utdata i én enkelt forespørsel:
```
use WordPress\AiClient\Messages\Enums\ModalityEnum;
// Tekst og bilder i ett svar — resultatet inneholder begge deler
$result = wp_ai_client_prompt( 'Lag en oppskrift med bilder for hvert trinn.' )
->as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
->generate_result();
```
Dette åpner for en rekke muligheter for plugins som genererer innhold som går utover ren tekst.
Funksjonsdeteksjon: Ikke gjør noen antakelser
-----------------------------------------
Ikke alle WordPress-installasjoner vil ha en AI-leverandør konfigurert. Og ikke alle leverandører støtter alle modaliteter. API-et tilbyr deterministiske kontroller:
```
$builder = wp_ai_client_prompt( 'test' )
->using_temperature( 0.7 );
// Ingen API-kall — rent logisk sjekk mot tilgjengelige leverandører
if ( $builder->is_supported_for_text_generation() ) {
// Vis brukergrensesnitt for tekstgenerering
}
if ( $builder->is_supported_for_image_generation() ) {
// Vis knappen for bildegenerering
}
```
Dette er en elegant løsning. Sjekkene koster ingenting – ingen API-kall, ingen forsinkelse. Plugin-utviklere kan laste inn brukergrensesnittet sitt betinget og vise en nyttig melding hvis AI ikke er tilgjengelig. Regelen: **Aldri gå ut fra at AI-funksjoner fungerer bare fordi WordPress 7.0 er installert.**
Tilgjengelige sjekker: `is_supported_for_text_generation()`, `is_supported_for_image_generation()`, `is_supported_for_text_to_speech_conversion()`, `is_supported_for_speech_generation()`, `is_supported_for_video_generation()`.
Modellpreferanser i stedet for krav
------------------------------------
Her blir designfilosofien tydelig:
```
$result = wp_ai_client_prompt( 'Forklar historien om boktrykk.' )
->using_temperature( 0.1 )
->using_model_preference(
'claude-sonnet-4-6',
'gemini-3.1-pro-preview',
'gpt-5.4'
)
->generate_text_result();
```
`using_model_preference()` er en **preferanse**, ikke et krav. AI Client bruker den første tilgjengelige modellen fra listen — eller en hvilken som helst kompatibel modell hvis ingen av disse er konfigurert. Plugin-koden fungerer alltid, uavhengig av leverandør.
Dette er den riktige beslutningen. Plugin-utviklere bør aldri være avhengige av at en bestemt modell er tilgjengelig. Den offisielle anbefalingen: Sorter modellene dine slik at nyere modeller kommer før eldre. De tre offisielle leverandør-pluginene ved lanseringen gjør allerede dette.
Strukturerte svar med JSON-skjema
---------------------------------------
For plugins som trenger strukturerte data – og det er mange av dem – er dette et høydepunkt:
```
$schema = array(
'type' => 'array',
'items' => array(
'type' => 'object',
'properties' => array(
'plugin_name' => array( 'type' => 'string' ),
'category' => array( 'type' => 'string' ),
),
'required' => array( 'plugin_name', 'category' ),
),
);
$json = wp_ai_client_prompt( 'Liste over 5 populære WordPress-plugins med kategori.' )
->as_json_response( $skjema )
->generate_text();
// Strukturerte data direkte som en matrise — ingen manuell parsing nødvendig
$data = json_decode( $json, true );
```
Dette er gull verdt for SEO-plugins, skjema-plugins og verktøy for innholdsanalyse. I stedet for å parse ustrukturert tekst får man data som er klare til bruk.
To-lagsarkitekturen
------------------------------
Under panseret består AI-klienten av to lag:
1. **PHP AI Client** (`wordpress/php-ai-client`) — et leverandøruavhengig PHP-SDK, pakket som et eksternt bibliotek i kjernen. CamelCase-metoder, unntak, teknisk sett uavhengig av WordPress.
2. **WordPress-wrapper** — `WP_AI_Client_Prompt_Builder` pakker inn SDK-et i WordPress-konvensjoner: snake\_case-metoder, `WP_Error` i stedet for unntak, integrasjon med WordPress HTTP-transport, Abilities API, Connectors-infrastruktur og hook-systemet.
Dette er en elegant oppdeling. PHP SDK-et kan i teorien også brukes utenfor WordPress. WordPress-wrapperen gjør det idiomatisk. Og `GenerativeAiResult`-objektet kan serialiseres og overføres direkte til `rest_ensure_response()` — REST-API-integrasjon 'out of the box':
```
function my_rest_callback( WP_REST_Request $request ) {
$result = wp_ai_client_prompt( $request->get_param( 'prompt' ) )
->generate_text_result();
// WP_Error eller GenerativeAiResult — begge deler fungerer
return rest_ensure_response( $result );
}
```
Detaljert kontroll: Filteret
-------------------------------
For sikkerhet og samsvar finnes `wp_ai_client_prevent_prompt`:
```
add_filter(
'wp_ai_client_prevent_prompt',
function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
// Eksempel: AI kun for administratorer
if ( ! current_user_can( 'manage_options' ) ) {
return true;
}
return $prevent;
},
10,
2
);
```
Når en prompt blokkeres: ingen API-kall, `is_supported_*()` returnerer `false`, `generate_*()` returnerer `WP_Error`. Rent, forutsigbart, ingen race conditions.
Styrker og svakheter
---------------------
**Hva som er godt løst:**
- Leverandørabstraksjonen. Plugin-utviklere trenger aldri å forholde seg til API-nøkler, rate limits eller leverandørspesifikke særegenheter.
- Funksjonsdeteksjon uten API-kall. Ingen gjetninger om hva som fungerer.
- WordPress-konvensjonene. `WP_Error`, hooks, REST-kompatibilitet — dette føles som en naturlig del av systemet.
- Støtte for JSON-skjema. Strukturerte svar støttes på en førsteklasses måte.
- To-lagsarkitekturen. Klar skille mellom SDK og WordPress-integrasjon.
**Det jeg ser på med et kritisk blikk:**
- Konfigurasjonen av tilkoblingene ligger hos nettstedseieren. Plugins har ingen innflytelse på **om** en leverandør er konfigurert. Funksjonsdeteksjon tar seg av dette, men utfordringen med brukeropplevelsen gjenstår.
- Modelllandskapet endrer seg raskt. Det gjenstår å se hvor godt preferanselisten tåler tidens tann når nye modeller dukker opp hver tredje måned.
- Ytelsesimplikasjonene er fortsatt uklare. Hvordan oppfører systemet seg under belastning når 10 plugins sender prompt-forespørsler samtidig?
Hva dette betyr for eksisterende plugins
---------------------------------------
Hvert plugin som i dag har egne AI-integrasjoner, står overfor et valg: Skal det beholde sin egen API-tilkobling eller migrere til AI-klienten?
For **SEO-plugins** er svaret klart – strukturerte data, innholdsanalyse og generering av metabeskrivelser fungerer betydelig bedre via AI-klienten. For **skjema-plugins** åpner det seg muligheter for intelligent feltvalidering og autofyll. For **e-handels-plugins** blir AI-genererte produktbeskrivelser plutselig en enkel sak.
For et plugin som [citelayer® – AI Visibility for WordPress](https://wordpress.org/plugins/citelayer/), som fungerer som grensesnitt mellom WordPress og AI-systemer, er AI Client en naturlig utvidelse. Citelayer gjør innhold lesbart for AI – gjennom llms.txt, schema-injection, bot-sporing og protokoller som UCP og WebMCP. AI Client kan utvide disse analyselagene med smartere, AI-støttede evalueringer. Hva dette konkret betyr for AI-synlighet, har jeg [belyst nærmere i Citelayer-bloggen](https://citelayer.ai/blog/wordpress-7-ai-client).
Ikke et gadget, men infrastruktur
---------------------------------
WordPress 7.0 AI Client er ikke en gadget. Det er infrastruktur. Gjennomtenkt, WordPress-idiomatisk og med en klar designfilosofi: Utvikleren beskriver intensjonen, systemet tar seg av utførelsen.
Den som utvikler WordPress-plugins i dag, bør gjøre seg kjent med denne API-en. Ikke fordi man må – men fordi den er fundamentet som neste generasjon WordPress-plugins vil bygge på.
Den fullstendige API-dokumentasjonen finnes på [WordPress Make Blog](https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/).
';
```
For variasjoner finnes `generate_images( 4 )` og `generate_texts( 4 )`. I tillegg kommer `convert_text_to_speech_result()`, `generate_speech_result()` og `generate_video_result()`. WordPress dekker dermed alle vanlige modaliteter.
Spesielt spennende: multimodal utdata i én enkelt forespørsel:
```
use WordPress\AiClient\Messages\Enums\ModalityEnum;
// Tekst og bilder i ett svar — resultatet inneholder begge deler
$result = wp_ai_client_prompt( 'Lag en oppskrift med bilder for hvert trinn.' )
->as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
->generate_result();
```
Dette åpner for en rekke muligheter for plugins som genererer innhold som går utover ren tekst.
Funksjonsdeteksjon: Ikke gjør noen antakelser
-----------------------------------------
Ikke alle WordPress-installasjoner vil ha en AI-leverandør konfigurert. Og ikke alle leverandører støtter alle modaliteter. API-et tilbyr deterministiske kontroller:
```
$builder = wp_ai_client_prompt( 'test' )
->using_temperature( 0.7 );
// Ingen API-kall — rent logisk sjekk mot tilgjengelige leverandører
if ( $builder->is_supported_for_text_generation() ) {
// Vis brukergrensesnitt for tekstgenerering
}
if ( $builder->is_supported_for_image_generation() ) {
// Vis knappen for bildegenerering
}
```
Dette er en elegant løsning. Sjekkene koster ingenting – ingen API-kall, ingen forsinkelse. Plugin-utviklere kan laste inn brukergrensesnittet sitt betinget og vise en nyttig melding hvis AI ikke er tilgjengelig. Regelen: **Aldri gå ut fra at AI-funksjoner fungerer bare fordi WordPress 7.0 er installert.**
Tilgjengelige sjekker: `is_supported_for_text_generation()`, `is_supported_for_image_generation()`, `is_supported_for_text_to_speech_conversion()`, `is_supported_for_speech_generation()`, `is_supported_for_video_generation()`.
Modellpreferanser i stedet for krav
------------------------------------
Her blir designfilosofien tydelig:
```
$result = wp_ai_client_prompt( 'Forklar historien om boktrykk.' )
->using_temperature( 0.1 )
->using_model_preference(
'claude-sonnet-4-6',
'gemini-3.1-pro-preview',
'gpt-5.4'
)
->generate_text_result();
```
`using_model_preference()` er en **preferanse**, ikke et krav. AI Client bruker den første tilgjengelige modellen fra listen — eller en hvilken som helst kompatibel modell hvis ingen av disse er konfigurert. Plugin-koden fungerer alltid, uavhengig av leverandør.
Dette er den riktige beslutningen. Plugin-utviklere bør aldri være avhengige av at en bestemt modell er tilgjengelig. Den offisielle anbefalingen: Sorter modellene dine slik at nyere modeller kommer før eldre. De tre offisielle leverandør-pluginene ved lanseringen gjør allerede dette.
Strukturerte svar med JSON-skjema
---------------------------------------
For plugins som trenger strukturerte data – og det er mange av dem – er dette et høydepunkt:
```
$schema = array(
'type' => 'array',
'items' => array(
'type' => 'object',
'properties' => array(
'plugin_name' => array( 'type' => 'string' ),
'category' => array( 'type' => 'string' ),
),
'required' => array( 'plugin_name', 'category' ),
),
);
$json = wp_ai_client_prompt( 'Liste over 5 populære WordPress-plugins med kategori.' )
->as_json_response( $skjema )
->generate_text();
// Strukturerte data direkte som en matrise — ingen manuell parsing nødvendig
$data = json_decode( $json, true );
```
Dette er gull verdt for SEO-plugins, skjema-plugins og verktøy for innholdsanalyse. I stedet for å parse ustrukturert tekst får man data som er klare til bruk.
To-lagsarkitekturen
------------------------------
Under panseret består AI-klienten av to lag:
1. **PHP AI Client** (`wordpress/php-ai-client`) — et leverandøruavhengig PHP-SDK, pakket som et eksternt bibliotek i kjernen. CamelCase-metoder, unntak, teknisk sett uavhengig av WordPress.
2. **WordPress-wrapper** — `WP_AI_Client_Prompt_Builder` pakker inn SDK-et i WordPress-konvensjoner: snake\_case-metoder, `WP_Error` i stedet for unntak, integrasjon med WordPress HTTP-transport, Abilities API, Connectors-infrastruktur og hook-systemet.
Dette er en elegant oppdeling. PHP SDK-et kan i teorien også brukes utenfor WordPress. WordPress-wrapperen gjør det idiomatisk. Og `GenerativeAiResult`-objektet kan serialiseres og overføres direkte til `rest_ensure_response()` — REST-API-integrasjon 'out of the box':
```
function my_rest_callback( WP_REST_Request $request ) {
$result = wp_ai_client_prompt( $request->get_param( 'prompt' ) )
->generate_text_result();
// WP_Error eller GenerativeAiResult — begge deler fungerer
return rest_ensure_response( $result );
}
```
Detaljert kontroll: Filteret
-------------------------------
For sikkerhet og samsvar finnes `wp_ai_client_prevent_prompt`:
```
add_filter(
'wp_ai_client_prevent_prompt',
function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
// Eksempel: AI kun for administratorer
if ( ! current_user_can( 'manage_options' ) ) {
return true;
}
return $prevent;
},
10,
2
);
```
Når en prompt blokkeres: ingen API-kall, `is_supported_*()` returnerer `false`, `generate_*()` returnerer `WP_Error`. Rent, forutsigbart, ingen race conditions.
Styrker og svakheter
---------------------
**Hva som er godt løst:**
- Leverandørabstraksjonen. Plugin-utviklere trenger aldri å forholde seg til API-nøkler, rate limits eller leverandørspesifikke særegenheter.
- Funksjonsdeteksjon uten API-kall. Ingen gjetninger om hva som fungerer.
- WordPress-konvensjonene. `WP_Error`, hooks, REST-kompatibilitet — dette føles som en naturlig del av systemet.
- Støtte for JSON-skjema. Strukturerte svar støttes på en førsteklasses måte.
- To-lagsarkitekturen. Klar skille mellom SDK og WordPress-integrasjon.
**Det jeg ser på med et kritisk blikk:**
- Konfigurasjonen av tilkoblingene ligger hos nettstedseieren. Plugins har ingen innflytelse på **om** en leverandør er konfigurert. Funksjonsdeteksjon tar seg av dette, men utfordringen med brukeropplevelsen gjenstår.
- Modelllandskapet endrer seg raskt. Det gjenstår å se hvor godt preferanselisten tåler tidens tann når nye modeller dukker opp hver tredje måned.
- Ytelsesimplikasjonene er fortsatt uklare. Hvordan oppfører systemet seg under belastning når 10 plugins sender prompt-forespørsler samtidig?
Hva dette betyr for eksisterende plugins
---------------------------------------
Hvert plugin som i dag har egne AI-integrasjoner, står overfor et valg: Skal det beholde sin egen API-tilkobling eller migrere til AI-klienten?
For **SEO-plugins** er svaret klart – strukturerte data, innholdsanalyse og generering av metabeskrivelser fungerer betydelig bedre via AI-klienten. For **skjema-plugins** åpner det seg muligheter for intelligent feltvalidering og autofyll. For **e-handels-plugins** blir AI-genererte produktbeskrivelser plutselig en enkel sak.
For et plugin som [citelayer® – AI Visibility for WordPress](https://wordpress.org/plugins/citelayer/), som fungerer som grensesnitt mellom WordPress og AI-systemer, er AI Client en naturlig utvidelse. Citelayer gjør innhold lesbart for AI – gjennom llms.txt, schema-injection, bot-sporing og protokoller som UCP og WebMCP. AI Client kan utvide disse analyselagene med smartere, AI-støttede evalueringer. Hva dette konkret betyr for AI-synlighet, har jeg [belyst nærmere i Citelayer-bloggen](https://citelayer.ai/blog/wordpress-7-ai-client).
Ikke et gadget, men infrastruktur
---------------------------------
WordPress 7.0 AI Client er ikke en gadget. Det er infrastruktur. Gjennomtenkt, WordPress-idiomatisk og med en klar designfilosofi: Utvikleren beskriver intensjonen, systemet tar seg av utførelsen.
Den som utvikler WordPress-plugins i dag, bør gjøre seg kjent med denne API-en. Ikke fordi man må – men fordi den er fundamentet som neste generasjon WordPress-plugins vil bygge på.
Den fullstendige API-dokumentasjonen finnes på [WordPress Make Blog](https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/).