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



Para variaciones, existen generate_images( 4 ) y generate_texts( 4 ). También existen convert_text_to_speech_result(), generate_speech_result() y generate_video_result(). WordPress cubre así todas las modalidades habituales.



Especialmente interesante: salida multimodal en una sola petición:



use WordPress\AiClient\Messages\Enums\ModalityEnum;

// Texto e imágenes en una respuesta - el resultado contiene ambos
$result = wp_ai_client_prompt( 'Crear una receta con fotos para cada paso.' )
    -&gt;as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
    -&gt;generate_result();



Esto abre la puerta a plugins que generan contenido que va más allá del texto puro.



Detección de características: no hagas suposiciones



No todas las instalaciones de WordPress tendrán configurado un proveedor de AI. Y no todos los proveedores admiten todas las modalidades. La API ofrece comprobaciones deterministas:



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

// No hay llamada a la API - comprobación puramente lógica con los proveedores disponibles
if ( $builder-&gt;is_supported_for_text_generation() ) {
    // Mostrar UI para generación de texto
}

if ( $builder-&gt;is_supported_for_image_generation() ) {
    // Mostrar botón de generación de imagen
}



Esta es una buena solución. Las comprobaciones no cuestan nada: no hay llamadas a la API ni latencia. Los desarrolladores de plugins pueden cargar su interfaz de usuario condicionalmente y mostrar una sugerencia útil si no hay IA disponible. La regla: Nunca asumas que las funciones de IA funcionarán sólo porque WordPress 7.0 esté instalado.



Comprobaciones disponibles: 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().



Preferencias del modelo en lugar de requisitos



La filosofía de diseño queda clara aquí:



$result = wp_ai_client_prompt( 'Explique la historia de la imprenta.' )
    -&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() es una preferencia, no un requisito. El cliente AI toma el primer modelo disponible de la lista - o cualquiera compatible si no hay ninguno configurado. El código del complemento siempre funciona, independientemente del proveedor.



Esta es la decisión correcta. Los desarrolladores de plugins nunca deben depender de que un modelo específico esté disponible. La recomendación oficial es ordenar los modelos de modo que los más recientes vayan antes que los más antiguos. Los tres plugins proveedores oficiales para el lanzamiento ya lo hacen.



Respuestas estructuradas con esquema JSON



Este es un punto destacado para los plugins que requieren datos estructurados - y hay muchos de ellos:



$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( 'Enumera 5 plugins populares de WordPress con categoría.' )
    -&gt;as_json_response( $schema )
    -&gt;generate_text();

// Estructurar los datos directamente como un array - no requiere análisis manual
$data = json_decode( $json, true );



Esto vale su peso en oro para plugins SEO, plugins de formularios y herramientas de análisis de contenido. En lugar de analizar texto no estructurado, se obtienen datos directamente utilizables.



La arquitectura de dos capas



Bajo el capó, el Cliente AI consta de dos capas:




PHP AI Client (wordpress/php-ai-client) - un SDK PHP agnóstico del proveedor, incluido como una biblioteca externa en Core. Métodos CamelCase, excepciones, técnicamente independiente de WordPress.



WordPress Wrapper - WP_AI_Client_Prompt_Builder envuelve el SDK en las convenciones de WordPress: métodos snake_case, WP_Error en lugar de excepciones, integración con WordPress HTTP Transport, Abilities API, infraestructura de conectores y el sistema de ganchos.




Esta es una separación elegante. En teoría, el SDK de PHP también puede utilizarse fuera de WordPress. La envoltura de WordPress lo hace idiomático. Y el objeto GenerativeAiResult es serializable y se puede pasar directamente a rest_ensure_response() - integración API REST fuera de la caja:



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

    // WP_Error o GenerativeAiResult - ambos funcionan
    return rest_ensure_response( $result );
}



Control granular: El filtro



Para la seguridad y el cumplimiento, existe wp_ai_client_prevent_prompt:



add_filter(
    'wp_ai_client_prevent_prompt',
    function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
        // Ejemplo: AI sólo para administradores
        if ( ! current_user_can( 'manage_options' ) ) {
            return true;
        }
        return $prevent;
    },
    10,
    2
);



Si se bloquea una consulta: no hay llamada a la API, is_supported_*() devuelve false, generate_*() devuelve WP_Error. Limpio, predecible, sin race conditions.



Puntos fuertes y débiles



Lo que está bien resuelto:




La abstracción del proveedor. Los desarrolladores de plug-ins nunca tienen que lidiar con claves API, límites de tarifa o peculiaridades de los proveedores.



Detección de funciones sin llamadas a la API. Nada de adivinar si algo funciona.



Las convenciones de WordPress. WP_Error, ganchos, compatibilidad REST - se siente nativo.



Soporte de esquema JSON. Las respuestas estructuradas son compatibles de primera clase.



Arquitectura de dos niveles. Separación limpia entre el SDK y la integración de WordPress.




Lo que observo críticamente:




La configuración del conector recae en el propietario del sitio. Los plugins no influyen en la configuración de un proveedor. La detección de funciones lo detecta, pero el problema de la experiencia del usuario persiste.



El panorama de los modelos evoluciona rápidamente. Queda por ver cómo envejece la lista de preferencias cuando aparecen nuevos modelos cada tres meses.



Aún no están claras las implicaciones para el rendimiento. ¿Cómo se comporta el sistema bajo carga cuando 10 plug-ins envían avisos al mismo tiempo?




¿Qué significa esto para los plug-ins existentes?



Todos los plugins que actualmente tienen sus propias integraciones de IA se enfrentan a una decisión: ¿Mantener su propia conexión API o migrar al cliente de IA?



Para los plugins SEO, la respuesta es clara: los datos estructurados, el análisis de contenido y la generación de meta descripciones se ejecutan de forma mucho más limpia a través del cliente AI. Para los plugins de formularios, la validación inteligente de campos y el autocompletado se abren paso. Para los plugins de comercio electrónico, las descripciones de productos generadas por IA se convierten de repente en algo trivial.



Para un plugin como citelayer® - AI Visibility for WordPress, que trabaja en la interfaz entre WordPress y los sistemas de IA, el cliente de IA es una extensión natural. Citelayer hace que el contenido sea legible para la IA mediante llms.txt, inyección de esquemas, seguimiento de bots y protocolos como UCP y WebMCP. El cliente de IA podría complementar estas capas de análisis con análisis más inteligentes y asistidos por IA. He explicado con más detalle lo que esto significa para AI Visibility en el blog de Citelayer.



No un gadget, sino infraestructura



El cliente AI de WordPress 7.0 no es un gadget. Es una infraestructura. Bien pensada, WordPress-idiomática y con una filosofía de diseño clara: el desarrollador describe la intención, el sistema se encarga de la ejecución.



Cualquiera que desarrolle plugins para WordPress hoy en día debería familiarizarse con esta API. No porque sea necesario, sino porque es la base sobre la que se construirá la próxima generación de plugins de WordPress.



La documentación completa de la API está disponible en el blog WordPress Make.