WordPress 7.0 para developers: Connectors API y AI Client, IA bien hecha

La integración de IA nativa es el titular del release. Pero detrás del titular hay una infraestructura técnica concreta que cambia cómo deberíamos integrar funciones de IA en plugins y proyectos personalizados a partir de ahora. Esta entrega va de eso: por qué consumir el AI Client del core sustituye —y mejora— los envoltorios artesanales que llevamos años escribiendo.

El problema antes de 7.0

Si has metido IA en un proyecto WordPress en los últimos dos años, probablemente has hecho alguna versión de esto:

• Pedir al cliente una API key de OpenAI o Anthropic.
• Guardarla en wp_options con tu propia capa de cifrado o sin ella.
• Envolver wp_remote_post() para llamar al endpoint del proveedor.
• Implementar tu propio manejo de errores, rate limits, retries y timeouts.
• Resignarte a que, si otro plugin del mismo sitio hace lo mismo, hay dos claves distintas, dos sistemas de cifrado distintos y dos formas de fallar.

Multiplica eso por dos o tres proyectos al año y tienes un mantenimiento que se acumula: cada breaking change del proveedor te toca a ti, cada migración de modelo te toca a ti, cada auditoría de seguridad te encuentra una clave en claro que olvidaste hace seis meses.

Lo que aporta 7.0

WordPress 7.0 introduce tres piezas que resuelven la fragmentación:

Connectors API. Un hub central en Ajustes > Connectors donde el administrador del sitio configura credenciales una vez por proveedor —OpenAI, Anthropic Claude, Google Gemini de fábrica— con métodos de autenticación estandarizados (api_key, none). Las claves viven en un único sitio, con interfaz nativa y permisos controlados por capacidades.

WP AI Client. Una interfaz provider-agnostic que cualquier plugin o tema puede consumir para hablar con modelos generativos sin saber de qué proveedor se trata. Si el usuario cambia de OpenAI a Anthropic en Connectors, tu plugin sigue funcionando sin tocar una línea.

Abilities API y Client-Side Abilities API. El modelo de «capacidades» que el sitio expone a la IA. En lugar de pedirle al modelo «haz X» y rezar, declaras las acciones disponibles (publicar un draft, etiquetar un post, generar alt text) y la IA elige cuál ejecutar. Es la pieza que permite asistentes con superficie controlada.

Cómo se ve en código

El cambio de paradigma es claro. Pasamos de esto:

$response = wp_remote_post( 'https://api.openai.com/v1/chat/completions', array(
    'headers' => array(
        'Authorization' => 'Bearer ' . MYPLUGIN_OPENAI_KEY,
        'Content-Type'  => 'application/json',
    ),
    'body'    => wp_json_encode( array(
        'model'    => 'gpt-4',
        'messages' => array( /* ... */ ),
    ) ),
    'timeout' => 30,
) );
// + parseo del JSON, manejo de errores específicos del proveedor, retries...

A consumir el cliente del core:

$ai = wp_ai_client();

$result = $ai->generate( array(
    'prompt'  => 'Resume este post en 280 caracteres: ' . $post_content,
    'purpose' => 'summary',
) );

if ( is_wp_error( $result ) ) {
    return $result;
}

return $result->get_text();

El plugin deja de saber qué proveedor está detrás. Si el sitio tiene OpenAI configurado, va por ahí. Si tiene Claude, va por ahí. Las credenciales no las toca tu código. Los errores vienen como WP_Error normalizados.

Casos de uso típicos en proyectos cliente

Tres patrones que vas a montar pronto si trabajas con clientes:

Generación automática de alt text en imágenes. Al subir una imagen, una ability registrada llama al AI Client con la imagen y rellena el campo alt. El cliente no pega claves en ningún sitio: se ha configurado una vez en Connectors.

Resumen de posts largos para meta description o redes sociales. Un metabox en la edición del post con un botón «sugerir resumen» que consume el AI Client. Compatible con cualquier proveedor configurado.

Sugerencia de categorías o etiquetas según contenido. En autosave o al pulsar un botón, una ability analiza el contenido y propone taxonomías existentes. El editor acepta o descarta.

En los tres casos, el código del plugin no menciona a OpenAI ni a Anthropic. Solo consume wp_ai_client().

Cuándo no usarlo

El AI Client cubre el caso general: generación de texto, embeddings, clasificación. Si necesitas algo muy específico de un proveedor —streaming en tiempo real con un protocolo concreto, function calling con un esquema propietario, modelos fine-tuned privados— sigue siendo razonable mantener una integración directa para esa pieza. El AI Client no pretende cubrir el 100% de la API de cada proveedor, sino el 80% común.

La regla práctica: si tu feature puede describirse como «pídele esto al modelo y devuélveme el resultado», AI Client. Si necesitas tocar la API del proveedor con detalle, integración directa.

Resumen accionable

1. En el próximo proyecto que requiera IA, no propongas «integro OpenAI». Propón «consumo el AI Client de WordPress 7.0».
2. Si mantienes un plugin con integración directa a un proveedor, planifica una versión que ofrezca el AI Client como vía recomendada y la integración directa como fallback.
3. Estudia la Abilities API. Es la diferencia entre «un plugin que llama a la IA» y «un plugin que expone capacidades a un asistente».
4. Documenta a tus clientes que las claves van en Ajustes > Connectors, no en cada plugin.

En el próximo post: los cambios en bloques, theme.json y editor que afectan a quienes hacemos temas. Mejoras en Tabs, Imagen, Búsqueda, pseudo-elementos en core/button, Cover con vídeo, Gallery con lightbox, y los dos bloques nuevos del release.