---
title: Der WordPress 7.0 AI Client aus Entwickler-Perspektive — isla Studio
url: https://isla-stud.io/en/allgemein/wordpress-7-ai-client-developer/
date: 2026-03-28
---
# Der WordPress 7.0 AI Client aus Entwickler-Perspektive
WordPress 7.0 bringt einen eingebauten AI Client. Nicht als Plugin, nicht als experimentelles Feature-Flag sondern als Teil des Core. Das ist ein Statement.
Ich entwickle seit 2009 WordPress-Plugins und habe mit citelayer® selbst ein AI-Plugin gebaut, das direkt von dieser Architekturentscheidung betroffen ist. Hier ist meine technische Analyse: Was kann die API, wo liegen die Stärken, und was müssen Plugin-Entwickler wissen?
Inhaltverzeichnis
Der Entry Point: wp_ai_client_prompt()
Alles beginnt mit einer einzigen Funktion:
$builder = wp_ai_client_prompt();
Das gibt ein WP_AI_Client_Prompt_Builder-Objekt zurück – ein Fluent Builder, über den Prompt, Konfiguration und Generierungsmethode verkettet werden. Das Grundprinzip: Der Entwickler beschreibt, was er braucht. WordPress kümmert sich um das wie.
Ein einfaches Beispiel für Textgenerierung:
// Prompt direkt als Parameter — bequem für einfache Fälle
$text = wp_ai_client_prompt( 'Fasse die Vorteile von Caching in WordPress zusammen.' )
->using_temperature( 0.7 )
->generate_text();
// Fehlerbehandlung wie überall in WordPress: WP_Error prüfen
if ( is_wp_error( $text ) ) {
return;
}
echo wp_kses_post( $text );
Der Prompt-Text kann als Parameter oder über with_text() gesetzt werden — letzteres ist nützlich, wenn der Prompt dynamisch zusammengebaut wird.
Mehr als Text: Bild, Sprache, Video
Die API ist multimodal. Bildgenerierung funktioniert nach demselben Pattern:
use WordPress\AiClient\Files\DTO\File;
$image = wp_ai_client_prompt( 'Ein futuristisches WordPress-Logo im Neon-Stil' )
->generate_image();
if ( is_wp_error( $image ) ) {
return;
}
// File DTO mit Data URI — direkt verwendbar
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.