---
title: WordPress 7.0 AI-klienten ur ett utvecklarperspektiv - isla Studio
url: https://isla-stud.io/sv/allgemein/wordpress-7-ai-client-developer/
datum: 2026-03-28
---
# AI-klienten WordPress 7.0 ur utvecklarens perspektiv
WordPress 7.0 ger en inbyggd AI-klient. Inte som ett plugin, inte som en experimentell funktionsflagga, utan som en del av kärnan. Det är ett uttalande.
Jag har utvecklat WordPress-plugins sedan 2009 och har själv byggt ett AI-plugin, citelayer®, som påverkas direkt av detta arkitektoniska beslut. Här är min tekniska analys: Vad kan API:et göra, vilka är dess styrkor och vad behöver plugin-utvecklare veta?
Innehållsförteckning
Ingångspunkten: wp_ai_client_prompt()
Allt börjar med en enda funktion:
$builder = wp_ai_client_prompt();
Detta returnerar ett WP_AI_Client_Prompt_Builder-objekt - en Fluent Builder via vilken prompt-, konfigurations- och genereringsmetoden är länkad. Grundprincipen: Utvecklaren beskriver vad de behöver. WordPress tar hand om hur.
Ett enkelt exempel på textgenerering:
// Fråga direkt som en parameter - bekvämt för enkla fall
$text = wp_ai_client_prompt( 'Sammanfatta fördelarna med cachelagring i WordPress.' )
->använda_temperatur( 0.7 )
->generate_text();
// Felhantering som överallt i WordPress: Kontrollera WP_Error
if ( is_wp_error( $text ) ) {
returnera;
}
echo wp_kses_post( $text );
Snabbtexten kan ställas in som en parameter eller via with_text() - det senare är användbart om snabbtexten monteras dynamiskt.
Mer än bara text: Bild, tal, video
API:et är multimodalt. Bildgenerering fungerar enligt samma mönster:
använd WordPress\AiClient\Files\DTO\File;
$image = wp_ai_client_prompt( 'En futuristisk WordPress-logotyp i neonstil' )
->generera_bild();
if ( is_wp_error( $image ) ) {
returnera;
}
// Fil-DTO med data-URI - direkt användbar
echo '';
För variationer finns det generate_images( 4 ) och generate_texts( 4 ). Det finns också convert_text_to_speech_result(), generate_speech_result() och generate_video_result(). WordPress täcker därmed alla vanliga modaliteter.
Särskilt spännande: multimodal utdata i en enda begäran:
använd WordPress\AiClient\Messages\Enums\ModalityEnum;
// Text och bilder i ett svar - resultatet innehåller båda
$result = wp_ai_client_prompt( 'Skapa ett recept med foton för varje steg.' )
->as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
->generera_resultat();
Detta öppnar dörren för plugins som genererar innehåll som går utöver ren text.
Funktionsdetektering: gör inga antaganden
Inte alla WordPress-installationer kommer att ha en AI-leverantör konfigurerad. Och inte alla leverantörer stöder alla modaliteter. API:et erbjuder deterministiska kontroller:
$builder = wp_ai_client_prompt( 'test' )
->använda_temperatur( 0.7 );
// Inget API-anrop - rent logisk kontroll mot tillgängliga leverantörer
if ( $builder->is_supported_for_text_generation() ) {
// Visa användargränssnitt för textgenerering
}
if ( $builder->is_supported_for_image_generation() ) {
// Visa knapp för bildgenerering
}
Det här är en snygg lösning. Kontrollerna kostar ingenting - inga API-anrop, ingen latens. Plugin-utvecklare kan ladda sitt användargränssnitt villkorligt och visa en användbar ledtråd om ingen AI är tillgänglig. Regeln: Anta aldrig att AI-funktioner fungerar bara för att WordPress 7.0 är installerad.
Tillgängliga 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().
Modellera preferenser i stället för krav
Här blir designfilosofin tydlig:
$result = wp_ai_client_prompt( 'Förklara tryckningens historia.' )
->använda_temperatur( 0.1 )
->använda_modell_preferens(
'claude-sonnet-4-6',
'gemini-3.1-pro-preview',
'gpt-5.4'
)
->generera_text_resultat();
using_model_preference() är en preferens, inte ett krav. AI-klienten tar den första tillgängliga modellen från listan - eller någon kompatibel modell om ingen är konfigurerad. Plugin-koden fungerar alltid, oavsett leverantör.
Detta är rätt beslut. Plugin-utvecklare bör aldrig vara beroende av att en viss modell är tillgänglig. Den officiella rekommendationen är att sortera dina modeller så att nyare kommer före äldre. De tre officiella leverantörspluginsen för lanseringen gör redan detta.
Strukturerade svar med JSON-schema
Detta är en höjdpunkt för plugins som kräver strukturerade data - och det finns många sådana:
$schema = array(
'type' => 'array',
'items' => matris(
'typ' => 'objekt',
'properties' => array(
'plugin_name' => array( 'type' => 'string' ),
'category' => array( 'type' => 'string' ),
),
'required' => array( 'plugin_name', 'category' ),
),
);
$json = wp_ai_client_prompt( 'Lista 5 populära WordPress-insticksprogram med kategori.' )
->as_json_response( $schema )
->generera_text();
// Strukturerad data direkt som en array - ingen manuell parsning krävs
$data = json_decode( $json, true );
Detta är guld värt för SEO-plugins, formulärplugins och verktyg för innehållsanalys. I stället för att analysera ostrukturerad text får du direkt användbara data.
Arkitekturen med två lager
Under motorhuven består AI Client av två lager:
PHP AI Client (wordpress/php-ai-client) - en leverantörs-agnostisk PHP SDK, buntad som ett externt bibliotek i Core. CamelCase-metoder, undantag, tekniskt WordPress-oberoende.
WordPress Wrapper - WP_AI_Client_Prompt_Builder förpackar SDK i WordPress-konventioner: snake_case-metoder, WP_Error istället för undantag, integration med WordPress HTTP Transport, Abilities API, Connectors-infrastruktur och hook-systemet.
Detta är en elegant separation. PHP SDK kan teoretiskt sett också användas utanför WordPress. WordPress wrapper gör det idiomatiskt. Och GenerativeAiResult-objektet är serialisierbart och kan skickas direkt till rest_ensure_response() - REST API-integration direkt från start:
function my_rest_callback( WP_REST_Request $request ) {
$result = wp_ai_client_prompt( $request->get_param( 'prompt' ) )
->genererar_text_resultat();
// WP_Error eller GenerativeAiResult - båda fungerar
return rest_ensure_response( $result );
}
Granulär kontroll: Filtret
För säkerhet och efterlevnad finns wp_ai_client_prevent_prompt:
add_filter(
'wp_ai_client_prevent_prompt',
function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
// Exempel: AI endast för administratörer
if ( ! current_user_can( 'manage_options' ) ) {
return true;
}
return $prevent;
},
10,
2
);
Om en prompt blockeras: inget API-anrop, is_supported_*() returnerar false, generate_*() returnerar WP_Error. Ren, förutsägbar, inga tävlingsförhållanden.
Styrkor och svagheter
Vad som är väl löst:
Abstraktionen av leverantören. Plugin-utvecklare behöver aldrig hantera API-nycklar, prisgränser eller leverantörens egenheter.
Funktionsdetektering utan API-anrop. Inget gissande om något fungerar.
WordPress-konventionerna. WP_Error, hooks, REST-kompatibilitet - det känns naturligt.
Stöd för JSON-schema. Strukturerade svar stöds i första klass.
Arkitektur med två nivåer. Ren separation mellan SDK och WordPress-integration.
Vad jag observerar kritiskt:
Konfigurationen av anslutningen ligger hos webbplatsägaren. Plugins har inget inflytande på om en provider är konfigurerad. Feature Detection fångar upp detta, men UX-utmaningen kvarstår.
Modelleringslandskapet rör sig snabbt. Hur väl preferenslistan åldras när nya modeller dyker upp var tredje månad återstår att se.
Konsekvenserna för prestandan är fortfarande oklara. Hur beter sig systemet under belastning när 10 plug-ins skickar meddelanden samtidigt?
Vad detta innebär för befintliga plugins
Varje plugin som för närvarande har sina egna AI-integrationer står inför ett beslut: Behåll din egen API-anslutning eller migrera till AI-klienten?
För SEO-plugins är svaret tydligt - strukturerad data, innehållsanalys och generering av metabeskrivningar körs mycket renare via AI-klienten. För formulärplugins öppnas möjligheter till intelligent fältvalidering och automatisk ifyllnad. För e-handelsplugins blir AI-genererade produktbeskrivningar plötsligt triviala.
För ett plugin som citelayer® - AI Visibility for WordPress, som arbetar i gränssnittet mellan WordPress och AI-system, är AI-klienten en naturlig förlängning. Citelayer gör innehållet läsbart för AI - genom llms.txt, schema injection, bot tracking och protokoll som UCP och WebMCP. AI-klienten skulle kunna komplettera dessa analyslager med mer intelligenta, AI-stödda analyser. Jag har förklarat mer i detalj vad detta innebär för AI Visibility i Citelayers blogg.
Inte en pryl utan infrastruktur
WordPress 7.0 AI Client är inte en pryl. Det är en infrastruktur. Väl genomtänkt, WordPress-idiomatisk och med en tydlig designfilosofi: utvecklaren beskriver avsikten, systemet tar hand om utförandet.
Alla som utvecklar WordPress-plugins idag bör bekanta sig med detta API. Inte för att du måste, utan för att det är grunden för nästa generation av WordPress-plugins.
Den fullständiga API-dokumentationen finns tillgänglig på WordPress Make-bloggen.
';
För variationer finns det generate_images( 4 ) och generate_texts( 4 ). Det finns också convert_text_to_speech_result(), generate_speech_result() och generate_video_result(). WordPress täcker därmed alla vanliga modaliteter.
Särskilt spännande: multimodal utdata i en enda begäran:
använd WordPress\AiClient\Messages\Enums\ModalityEnum;
// Text och bilder i ett svar - resultatet innehåller båda
$result = wp_ai_client_prompt( 'Skapa ett recept med foton för varje steg.' )
->as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
->generera_resultat();
Detta öppnar dörren för plugins som genererar innehåll som går utöver ren text.
Funktionsdetektering: gör inga antaganden
Inte alla WordPress-installationer kommer att ha en AI-leverantör konfigurerad. Och inte alla leverantörer stöder alla modaliteter. API:et erbjuder deterministiska kontroller:
$builder = wp_ai_client_prompt( 'test' )
->använda_temperatur( 0.7 );
// Inget API-anrop - rent logisk kontroll mot tillgängliga leverantörer
if ( $builder->is_supported_for_text_generation() ) {
// Visa användargränssnitt för textgenerering
}
if ( $builder->is_supported_for_image_generation() ) {
// Visa knapp för bildgenerering
}
Det här är en snygg lösning. Kontrollerna kostar ingenting - inga API-anrop, ingen latens. Plugin-utvecklare kan ladda sitt användargränssnitt villkorligt och visa en användbar ledtråd om ingen AI är tillgänglig. Regeln: Anta aldrig att AI-funktioner fungerar bara för att WordPress 7.0 är installerad.
Tillgängliga 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().
Modellera preferenser i stället för krav
Här blir designfilosofin tydlig:
$result = wp_ai_client_prompt( 'Förklara tryckningens historia.' )
->använda_temperatur( 0.1 )
->använda_modell_preferens(
'claude-sonnet-4-6',
'gemini-3.1-pro-preview',
'gpt-5.4'
)
->generera_text_resultat();
using_model_preference() är en preferens, inte ett krav. AI-klienten tar den första tillgängliga modellen från listan - eller någon kompatibel modell om ingen är konfigurerad. Plugin-koden fungerar alltid, oavsett leverantör.
Detta är rätt beslut. Plugin-utvecklare bör aldrig vara beroende av att en viss modell är tillgänglig. Den officiella rekommendationen är att sortera dina modeller så att nyare kommer före äldre. De tre officiella leverantörspluginsen för lanseringen gör redan detta.
Strukturerade svar med JSON-schema
Detta är en höjdpunkt för plugins som kräver strukturerade data - och det finns många sådana:
$schema = array(
'type' => 'array',
'items' => matris(
'typ' => 'objekt',
'properties' => array(
'plugin_name' => array( 'type' => 'string' ),
'category' => array( 'type' => 'string' ),
),
'required' => array( 'plugin_name', 'category' ),
),
);
$json = wp_ai_client_prompt( 'Lista 5 populära WordPress-insticksprogram med kategori.' )
->as_json_response( $schema )
->generera_text();
// Strukturerad data direkt som en array - ingen manuell parsning krävs
$data = json_decode( $json, true );
Detta är guld värt för SEO-plugins, formulärplugins och verktyg för innehållsanalys. I stället för att analysera ostrukturerad text får du direkt användbara data.
Arkitekturen med två lager
Under motorhuven består AI Client av två lager:
PHP AI Client (wordpress/php-ai-client) - en leverantörs-agnostisk PHP SDK, buntad som ett externt bibliotek i Core. CamelCase-metoder, undantag, tekniskt WordPress-oberoende.
WordPress Wrapper - WP_AI_Client_Prompt_Builder förpackar SDK i WordPress-konventioner: snake_case-metoder, WP_Error istället för undantag, integration med WordPress HTTP Transport, Abilities API, Connectors-infrastruktur och hook-systemet.
Detta är en elegant separation. PHP SDK kan teoretiskt sett också användas utanför WordPress. WordPress wrapper gör det idiomatiskt. Och GenerativeAiResult-objektet är serialisierbart och kan skickas direkt till rest_ensure_response() - REST API-integration direkt från start:
function my_rest_callback( WP_REST_Request $request ) {
$result = wp_ai_client_prompt( $request->get_param( 'prompt' ) )
->genererar_text_resultat();
// WP_Error eller GenerativeAiResult - båda fungerar
return rest_ensure_response( $result );
}
Granulär kontroll: Filtret
För säkerhet och efterlevnad finns wp_ai_client_prevent_prompt:
add_filter(
'wp_ai_client_prevent_prompt',
function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
// Exempel: AI endast för administratörer
if ( ! current_user_can( 'manage_options' ) ) {
return true;
}
return $prevent;
},
10,
2
);
Om en prompt blockeras: inget API-anrop, is_supported_*() returnerar false, generate_*() returnerar WP_Error. Ren, förutsägbar, inga tävlingsförhållanden.
Styrkor och svagheter
Vad som är väl löst:
Abstraktionen av leverantören. Plugin-utvecklare behöver aldrig hantera API-nycklar, prisgränser eller leverantörens egenheter.
Funktionsdetektering utan API-anrop. Inget gissande om något fungerar.
WordPress-konventionerna. WP_Error, hooks, REST-kompatibilitet - det känns naturligt.
Stöd för JSON-schema. Strukturerade svar stöds i första klass.
Arkitektur med två nivåer. Ren separation mellan SDK och WordPress-integration.
Vad jag observerar kritiskt:
Konfigurationen av anslutningen ligger hos webbplatsägaren. Plugins har inget inflytande på om en provider är konfigurerad. Feature Detection fångar upp detta, men UX-utmaningen kvarstår.
Modelleringslandskapet rör sig snabbt. Hur väl preferenslistan åldras när nya modeller dyker upp var tredje månad återstår att se.
Konsekvenserna för prestandan är fortfarande oklara. Hur beter sig systemet under belastning när 10 plug-ins skickar meddelanden samtidigt?
Vad detta innebär för befintliga plugins
Varje plugin som för närvarande har sina egna AI-integrationer står inför ett beslut: Behåll din egen API-anslutning eller migrera till AI-klienten?
För SEO-plugins är svaret tydligt - strukturerad data, innehållsanalys och generering av metabeskrivningar körs mycket renare via AI-klienten. För formulärplugins öppnas möjligheter till intelligent fältvalidering och automatisk ifyllnad. För e-handelsplugins blir AI-genererade produktbeskrivningar plötsligt triviala.
För ett plugin som citelayer® - AI Visibility for WordPress, som arbetar i gränssnittet mellan WordPress och AI-system, är AI-klienten en naturlig förlängning. Citelayer gör innehållet läsbart för AI - genom llms.txt, schema injection, bot tracking och protokoll som UCP och WebMCP. AI-klienten skulle kunna komplettera dessa analyslager med mer intelligenta, AI-stödda analyser. Jag har förklarat mer i detalj vad detta innebär för AI Visibility i Citelayers blogg.
Inte en pryl utan infrastruktur
WordPress 7.0 AI Client är inte en pryl. Det är en infrastruktur. Väl genomtänkt, WordPress-idiomatisk och med en tydlig designfilosofi: utvecklaren beskriver avsikten, systemet tar hand om utförandet.
Alla som utvecklar WordPress-plugins idag bör bekanta sig med detta API. Inte för att du måste, utan för att det är grunden för nästa generation av WordPress-plugins.
Den fullständiga API-dokumentationen finns tillgänglig på WordPress Make-bloggen.