---
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 '<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>';



Für Variationen gibt es generate_images( 4 ) und generate_texts( 4 ). Dazu kommen convert_text_to_speech_result(), generate_speech_result() und generate_video_result(). WordPress deckt damit alle gängigen Modalitäten ab.



Besonders spannend: Multimodaler Output in einer einzelnen Anfrage:



use WordPress\AiClient\Messages\Enums\ModalityEnum;

// Text und Bilder in einer Antwort — das Ergebnis enthält beides
$result = wp_ai_client_prompt( 'Erstelle ein Rezept mit Fotos für jeden Schritt.' )
    ->as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
    ->generate_result();



Das öffnet Tür und Tor für Plugins, die Inhalte generieren, die über reinen Text hinausgehen.



Feature Detection: Keine Annahmen treffen



Nicht jede WordPress-Installation wird einen AI Provider konfiguriert haben. Und nicht jeder Provider unterstützt jede Modalität. Die API bietet deterministische Checks:



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

// Kein API-Call — rein logische Prüfung gegen verfügbare Provider
if ( $builder->is_supported_for_text_generation() ) {
    // UI für Textgenerierung anzeigen
}

if ( $builder->is_supported_for_image_generation() ) {
    // Bildgenerierungs-Button einblenden
}



Das ist sauber gelöst. Die Checks kosten nichts – keine API-Calls, keine Latenz. Plugin-Entwickler können ihre UI bedingt laden und einen hilfreichen Hinweis zeigen, wenn keine AI verfügbar ist. Die Regel: Nie davon ausgehen, dass AI-Features funktionieren, nur weil WordPress 7.0 installiert ist.



Verfügbare 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 statt Requirements



Hier wird die Design-Philosophie deutlich:



$result = wp_ai_client_prompt( 'Erkläre die Geschichte des Buchdrucks.' )
    ->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() ist eine Präferenz, keine Anforderung. Der AI Client nimmt das erste verfügbare Modell aus der Liste — oder irgendein kompatibles, wenn keines davon konfiguriert ist. Der Plugin-Code funktioniert immer, unabhängig vom Provider.



Das ist die richtige Entscheidung. Plugin-Entwickler sollten nie davon abhängen, dass ein bestimmtes Modell verfügbar ist. Die offizielle Empfehlung: Sortiert eure Modelle so, dass neuere vor älteren stehen. Die drei offiziellen Provider-Plugins zum Launch machen das bereits.



Strukturierte Antworten mit JSON Schema



Für Plugins, die strukturierte Daten brauchen — und davon gibt es viele —, ist das ein Highlight:



$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 5 beliebte WordPress-Plugins mit Kategorie.' )
    ->as_json_response( $schema )
    ->generate_text();

// Strukturierte Daten direkt als Array — kein manuelles Parsen nötig
$data = json_decode( $json, true );



Das ist für SEO-Plugins, Form-Plugins, und Content-Analyse-Tools Gold wert. Statt unstrukturierten Text zu parsen, bekommt man direkt nutzbare Daten.



Die Zwei-Schichten-Architektur



Unter der Haube besteht der AI Client aus zwei Ebenen:




PHP AI Client (wordpress/php-ai-client) — ein provider-agnostisches PHP SDK, als externe Library in Core gebundelt. CamelCase-Methoden, Exceptions, technisch WordPress-unabhängig.



WordPress Wrapper — WP_AI_Client_Prompt_Builder wickelt das SDK in WordPress-Conventions: snake_case Methoden, WP_Error statt Exceptions, Integration mit WordPress HTTP Transport, Abilities API, Connectors-Infrastruktur und dem Hook-System.




Das ist eine elegante Trennung. Das PHP SDK kann theoretisch auch außerhalb von WordPress genutzt werden. Der WordPress-Wrapper macht es idiomatisch. Und das GenerativeAiResult-Objekt ist serialisierbar und kann direkt an rest_ensure_response() übergeben werden — REST-API-Integration 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 oder GenerativeAiResult — beides funktioniert
    return rest_ensure_response( $result );
}



Granulare Kontrolle: Der Filter



Für Sicherheit und Compliance gibt es wp_ai_client_prevent_prompt:



add_filter(
    'wp_ai_client_prevent_prompt',
    function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
        // Beispiel: AI nur für Admins
        if ( ! current_user_can( 'manage_options' ) ) {
            return true;
        }
        return $prevent;
    },
    10,
    2
);



Wenn ein Prompt blockiert wird: kein API-Call, is_supported_*() gibt false zurück, generate_*() liefert WP_Error. Sauber, vorhersehbar, keine Race Conditions.



Stärken und Schwächen



Was gut gelöst ist:




Die Provider-Abstraktion. Plugin-Entwickler müssen sich nie mit API-Keys, Rate Limits oder Provider-Eigenheiten beschäftigen.



Feature Detection ohne API-Calls. Kein Raten, ob etwas funktioniert.



Die WordPress-Conventions. WP_Error, Hooks, REST-Kompatibilität — das fühlt sich nativ an.



JSON Schema Support. Strukturierte Antworten sind erstklassig unterstützt.



Die Zwei-Schichten-Architektur. Saubere Trennung zwischen SDK und WordPress-Integration.




Was ich kritisch beobachte:




Die Connector-Konfiguration liegt beim Site-Owner. Plugins haben keinen Einfluss darauf, ob ein Provider konfiguriert ist. Feature Detection fängt das ab, aber die UX-Herausforderung bleibt.



Die Model-Landschaft bewegt sich schnell. Wie gut die Preference-Liste altert, wenn alle drei Monate neue Modelle erscheinen, wird sich zeigen.



Performance-Implikationen sind noch unklar. Wie verhält sich das System unter Last, wenn 10 Plugins gleichzeitig Prompts senden?




Was das für bestehende Plugins bedeutet



Jedes Plugin, das heute eigene AI-Integrationen mitbringt, steht vor einer Entscheidung: Eigene API-Anbindung beibehalten oder auf den AI Client migrieren?



Für SEO-Plugins ist die Antwort klar — strukturierte Daten, Content-Analyse, Meta-Description-Generierung laufen über den AI Client deutlich sauberer. Für Form-Plugins eröffnet sich intelligente Feldvalidierung und Auto-Fill. Für E-Commerce-Plugins werden AI-generierte Produktbeschreibungen plötzlich trivial.



Für ein Plugin wie citelayer® – AI Visibility für WordPress, das an der Schnittstelle zwischen WordPress und AI-Systemen arbeitet, ist der AI Client eine natürliche Erweiterung. Citelayer macht Content für AI lesbar — durch llms.txt, Schema-Injection, Bot-Tracking und Protokolle wie UCP und WebMCP. Der AI Client könnte diese Analyse-Layer um intelligentere, AI-gestützte Auswertungen ergänzen. Was das konkret für AI Visibility bedeutet, habe ich im Citelayer-Blog ausführlicher beleuchtet.



Kein Gadget sondern Infrastruktur



Der WordPress 7.0 AI Client ist kein Gadget. Es ist Infrastruktur. Durchdacht, WordPress-idiomatisch, und mit einer klaren Design-Philosophie: Der Entwickler beschreibt die Intention, das System kümmert sich um die Ausführung.



Wer heute WordPress-Plugins entwickelt, sollte sich mit dieser API vertraut machen. Nicht weil man muss — sondern weil sie das Fundament ist, auf dem die nächste Generation von WordPress-Plugins aufbauen wird.



Die vollständige API-Dokumentation gibt es auf dem WordPress Make Blog.