WordPress 7.0 får en innebygd AI Client. Ikke som utvidelse eller eksperimentelt funksjonsflagg, men som en del av kjernen. Det er et tydelig signal.
Jeg har utviklet WordPress-utvidelser siden 2009 og har med citelayer® selv laget en KI-utvidelse som blir direkte berørt av dette arkitekturvalget. Her er den tekniske analysen min: Hva kan API-et, hvor ligger styrkene, og hva trenger utvidelsesutviklere å vite?
Inngangspunktet: wp_ai_client_prompt()
Alt begynner med én funksjon:
$builder = wp_ai_client_prompt();
Den returnerer et WP_AI_Client_Prompt_Builder-objekt tilbake – en Fluent Builder, der prompt, konfigurasjon og genereringsmetode kjedes sammen. Grunnprinsippet: Utvikleren beskriver, hva som trengs. 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 med with_text() . Det siste er nyttig når prompten bygges opp dynamisk.
Mer enn tekst: bilder, tale og video
API-et er multimodalt. Bildegenerering følger 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;
}
// File DTO med Data URI — direkte brukbar
echo '<img src="' . esc_url( $image->getDataUri() ) . '" data-no-translation="" data-no-auto-translation="">';
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(). Dermed dekker WordPress alle vanlige modaliteter.
Særlig interessant er multimodale resultater 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();
Det åpner mange muligheter for utvidelser som genererer mer enn ren tekst.
Funksjonskontroll: Ikke ta noe for gitt
Ikke alle WordPress-installasjoner vil ha en KI-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 UI for tekstgenerering
}
if ( $builder->is_supported_for_image_generation() ) {
// Vis knapp for bildegenerering
}
Dette er elegant løst. Sjekkene koster ingenting – ingen API-kall, ingen ventetid. Plugin-utviklere kan laste brukergrensesnittet sitt betinget og vise et nyttig hint når ingen KI er tilgjengelig. Regelen: Ta aldri for gitt at KI-funksjoner virker bare fordi WordPress 7.0 er installert.
Tilgjengelige kontroller: 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 fremfor krav
Her blir designfilosofien tydelig:
$result = wp_ai_client_prompt( 'Forklar historien om boktrykking.' ) ->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() angir en preferanse, ikke et krav. AI Client velger den første tilgjengelige modellen i listen, eller en annen kompatibel modell hvis ingen av dem er konfigurert. Utvidelseskoden fungerer alltid, uavhengig av leverandøren.
Det er det riktige valget. Utvidelsesutviklere bør aldri være avhengige av at en bestemt modell er tilgjengelig. Den offisielle anbefalingen er å sortere modellene slik at nyere står foran eldre. De tre offisielle leverandørutvidelsene ved lansering gjør allerede dette.
Strukturerte svar med JSON Schema
For utvidelser som trenger strukturerte data, og dem finnes det mange av, 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( 'List opp 5 populære WordPress-utvidelser med kategori.' )
->as_json_response( $schema )
->generate_text();
// Strukturerte data direkte som array — ingen manuell parsing nødvendig
$data = json_decode( $json, true );
Dette er gull verdt for SEO-utvidelser, skjemautvidelser og verktøy for innholdsanalyse. I stedet for å tolke ustrukturert tekst får man data som kan brukes direkte.
Arkitekturen med to lag
Under panseret består AI Client av to nivåer:
- PHP AI Client (
wordpress/php-ai-client) – et leverandøruavhengig PHP-SDK, inkludert i kjernen som et eksternt bibliotek. CamelCase-metoder, exceptions og teknisk uavhengig av WordPress. - WordPress Wrapper –
WP_AI_Client_Prompt_Buildertilpasser SDK-et til WordPress-konvensjoner: snake_case-metoder,WP_Errori stedet for exceptions, og integrasjon med WordPress HTTP Transport, Abilities API, Connectors-infrastrukturen og hook-systemet.
Dette er en elegant oppdeling. PHP-SDK-et kan i teorien også brukes utenfor WordPress. WordPress-wrapperen gjør bruken naturlig i WordPress. Og GenerativeAiResult-objektet kan serialiseres og sendes direkte til rest_ensure_response() , slik at REST-API-integrasjonen er klar til bruk:
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 fungerer
return rest_ensure_response( $result );
}
Detaljert kontroll: Filteret
For sikkerhet og etterlevelse 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, blir det ikke gjort noe API-kall. is_supported_*() returnerer false , og generate_*() returnerer WP_Error. Ryddig, forutsigbart og uten race conditions.
Styrker og svakheter
Dette er godt løst:
- Leverandørabstraksjonen. Utvidelsesutviklere trenger aldri å forholde seg til API-nøkler, rategrenser eller særegenheter hos leverandørene.
- Funksjonskontroll uten API-kall. Man slipper å gjette om noe vil fungere.
- WordPress-konvensjonene.
WP_Error, hooks og REST-kompatibilitet gjør at det føles innebygd. - Støtte for JSON Schema. Strukturerte svar har førsteklasses støtte.
- Arkitekturen med to lag. Et tydelig skille mellom SDK-et og WordPress-integrasjonen.
Dette følger jeg med et kritisk blikk:
- Det er nettstedseieren som konfigurerer tilkoblingen. Utvidelser har ingen innflytelse på om en leverandør er konfigurert. Funksjonskontrollen håndterer dette, men utfordringen for brukeropplevelsen består.
- Modellandskapet endrer seg raskt. Det gjenstår å se hvor godt preferanselisten holder seg når det kommer nye modeller hver tredje måned.
- Konsekvensene for ytelsen er fortsatt uklare. Hvordan oppfører systemet seg under belastning når 10 utvidelser sender prompter samtidig?
Hva dette betyr for eksisterende utvidelser
Alle utvidelser som i dag har egne KI-integrasjoner, står overfor et valg: Beholde sin egen API-tilkoblingen eller gå over til AI Client?
For SEO-utvidelser er svaret klart: Strukturerte data, innholdsanalyse og generering av metabeskrivelser blir langt ryddigere med AI Client. For skjemautvidelser åpner det for intelligent feltvalidering og automatisk utfylling. For netthandelsutvidelser blir det plutselig svært enkelt å lage KI-genererte produktbeskrivelser.
For en utvidelse som citelayer® – AI Visibility for WordPress, som arbeider i skjæringspunktet mellom WordPress og KI-systemer, er AI Client en naturlig utvidelse. Citelayer gjør innhold lesbart for KI gjennom llms.txt, innsetting av Schema-data, bot-sporing og protokoller som UCP og WebMCP. AI Client kan tenkes å supplere dette analyselaget med mer intelligente, KI-støttede vurderinger. Hva det konkret betyr for AI Visibility, har jeg skrevet mer om i Citelayer-bloggen.
Infrastruktur, ikke en liten tilleggsfunksjon
WordPress 7.0 AI Client er ingen liten tilleggsfunksjon. Det er infrastruktur. Gjennomtenkt, i tråd med WordPress-konvensjoner og med en klar designfilosofi: Utvikleren beskriver hensikten, systemet tar seg av utførelsen.
Den som utvikler WordPress-utvidelser i dag, bør bli kjent med dette API-et. Ikke fordi man må, men fordi det er grunnlaget neste generasjon WordPress-utvidelser vil bygge på.
Den fullstendige API-dokumentasjonen finnes på WordPress Make Blog.





Diskusjon om innlegget
0 kommentarer