---
title: Der WordPress 7.0 AI Client aus Entwickler-Perspektive — isla Studio
url: https://isla-stud.io/sv/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 '<img src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" data-src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" decoding="async" class="lazyload" data-no-translation="" data-no-auto-translation=""><noscript><img src="' . esc_url( $image-&gt;getDataUri() ) . '" data-eio="l" data-no-translation="" data-no-auto-translation=""></noscript>';



For variations, there are generate_images( 4 ) and generate_texts( 4 ). There are also convert_text_to_speech_result(), generate_speech_result() and generate_video_result(). WordPress thus covers all common modalities.



Particularly exciting: multimodal output in a single request:



use WordPress\AiClient\Messages\Enums\ModalityEnum;

// Text and images in one response - the result contains both
$result = wp_ai_client_prompt( 'Create a recipe with photos for each step.' )
    -&gt;as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
    -&gt;generate_result();



This opens the door for plugins that generate content that goes beyond pure text.



Feature detection: make no assumptions



Not every WordPress installation will have an AI provider configured. And not every provider supports every modality. The API offers deterministic checks:



$builder = wp_ai_client_prompt( 'test' )
    -&gt;using_temperature( 0.7 );

// No API call - purely logical check against available providers
if ( $builder-&gt;is_supported_for_text_generation() ) {
    // Display UI for text generation
}

if ( $builder-&gt;is_supported_for_image_generation() ) {
    // Show image generation button
}



This is a clean solution. The checks cost nothing - no API calls, no latency. Plugin developers can load their UI conditionally and show a helpful hint if no AI is available. The rule: Never assume that AI features will work just because WordPress 7.0 is installed.



Available checks: 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().



Model preferences instead of requirements



The design philosophy becomes clear here:



$result = wp_ai_client_prompt( 'Explain the history of letterpress printing.' )
    -&gt;using_temperature( 0.1 )
    -&gt;using_model_preference(
        'claude-sonnet-4-6',
        'gemini-3.1-pro-preview',
        'gpt-5.4'
    )
    -&gt;generate_text_result();



using_model_preference() is a preference, not a requirement. The AI client takes the first available model from the list - or any compatible one if none is configured. The plugin code always works, regardless of the provider.



This is the right decision. Plugin developers should never depend on a specific model being available. The official recommendation is to sort your models so that newer ones come before older ones. The three official provider plugins for the launch already do this.



Structured responses with JSON schema



This is a highlight for plugins that require structured data - and there are many of them:



$schema = array(
    'type' =&gt; 'array',
    'items' =&gt; array(
        'type' =&gt; 'object',
        'properties' =&gt; array(
            'plugin_name' =&gt; array( 'type' =&gt; 'string' ),
            'category' =&gt; array( 'type' =&gt; 'string' ),
        ),
        'required' =&gt; array( 'plugin_name', 'category' ),
    ),
);

$json = wp_ai_client_prompt( 'List 5 popular WordPress plugins with category.' )
    -&gt;as_json_response( $schema )
    -&gt;generate_text();

// Structured data directly as an array - no manual parsing required
$data = json_decode( $json, true );



This is worth its weight in gold for SEO plugins, form plugins and content analysis tools. Instead of parsing unstructured text, you get directly usable data.



The two-layer architecture



Under the hood, the AI Client consists of two layers:




PHP AI Client (wordpress/php-ai-client) - a provider-agnostic PHP SDK, bundled as an external library in Core. CamelCase methods, exceptions, technically WordPress-independent.



WordPress Wrapper - WP_AI_Client_Prompt_Builder wraps the SDK in WordPress conventions: snake_case methods, WP_Error instead of exceptions, integration with WordPress HTTP Transport, Abilities API, Connectors infrastructure and the hook system.




This is an elegant separation. The PHP SDK can theoretically also be used outside of WordPress. The WordPress wrapper makes it idiomatic. And the GenerativeAiResult object is serializable and can be passed directly to rest_ensure_response() - REST API integration out of the box:



function my_rest_callback( WP_REST_Request $request ) {
    $result = wp_ai_client_prompt( $request-&gt;get_param( 'prompt' ) )
        -&gt;generate_text_result();

    // WP_Error or GenerativeAiResult - both work
    return rest_ensure_response( $result );
}



Granular control: The filter



For security and compliance, there is wp_ai_client_prevent_prompt:



add_filter(
    'wp_ai_client_prevent_prompt',
    function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
        // Example: AI for admins only
        if ( ! current_user_can( 'manage_options' ) ) {
            return true;
        }
        return $prevent;
    },
    10,
    2
);



If a prompt is blocked: no API call, is_supported_*() returns false, generate_*() returns WP_Error. Clean, predictable, no race conditions.



Strengths and weaknesses



What is well solved:




The provider abstraction. Plug-in developers never have to deal with API keys, rate limits or provider peculiarities.



Feature detection without API calls. No guessing whether something works.



The WordPress conventions. WP_Error, hooks, REST compatibility - it feels native.



JSON schema support. Structured responses are supported first class.



The two-tier architecture. Clean separation between SDK and WordPress integration.




What I observe critically:




The connector configuration lies with the site owner. Plugins have no influence on whether a provider is configured. Feature Detection catches this, but the UX challenge remains.



The model landscape is moving fast. How well the preference list ages when new models appear every three months remains to be seen.



Performance implications are still unclear. How does the system behave under load when 10 plug-ins send prompts at the same time?




What this means for existing plugins



Every plugin that currently has its own AI integrations is faced with a decision: Keep your own API connection or migrate to the AI client?



For SEO plugins, the answer is clear - structured data, content analysis and meta description generation run much more cleanly via the AI client. For form plugins, intelligent field validation and auto-fill are opening up. For e-commerce plugins, AI-generated product descriptions suddenly become trivial.



For a plugin like citelayer® - AI Visibility for WordPress, which works at the interface between WordPress and AI systems, the AI client is a natural extension. Citelayer makes content readable for AI - through llms.txt, schema injection, bot tracking and protocols such as UCP and WebMCP. The AI Client could supplement these analysis layers with more intelligent, AI-supported evaluations. I have explained in more detail what this means for AI Visibility in the Citelayer blog.



Not a gadget but infrastructure



The WordPress 7.0 AI Client is not a gadget. It is infrastructure. Well thought-out, WordPress-idiomatic, and with a clear design philosophy: the developer describes the intention, the system takes care of the execution.



Anyone developing WordPress plugins today should familiarize themselves with this API. Not because you have to - but because it is the foundation on which the next generation of WordPress plugins will be built.



The complete API documentation is available on the WordPress Make blog.