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?

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="' . esc_url( $image->getDataUri() ) . '">';

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:

1. 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.
2. 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.