---
title: Der WordPress 7.0 AI Client aus Entwickler-Perspektive — isla Studio
url: https://isla-stud.io/no/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®](https://citelayer.ai) 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 '';
```
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](https://wordpress.org/plugins/citelayer/), 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](https://citelayer.ai/blog/wordpress-7-ai-client).
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](https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/).
';
```
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](https://wordpress.org/plugins/citelayer/), 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](https://citelayer.ai/blog/wordpress-7-ai-client).
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](https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/).