WordPress 7.0 dejará de soportar PHP 7.2 y 7.3

Actualizado el 17/04/2026: El boletín oficial de abril para desarrolladores confirma que WordPress 7.0 incorporará un cliente IA nativo en core, con la función wp_ai_client_prompt(), una pantalla centralizada de Connectors para gestionar proveedores (OpenAI, Anthropic, Google y más), y la contraparte JavaScript de la Abilities API vía los paquetes @wordpress/abilities y @wordpress/core-abilities.

En 30 segundos: qué cambia con WordPress 7.0

Cliente IA nativo: wp_ai_client_prompt() disponible para cualquier plugin sin instalar SDKs externos.
Connectors API: pantalla en Ajustes para configurar una sola vez el proveedor de IA (OpenAI, Anthropic, Google, OpenRouter, Ollama, Mistral).
Abilities API en JS: los paquetes @wordpress/abilities y @wordpress/core-abilities llevan el sistema de permisos granulares al frontend.
PHP mínimo: 7.4. PHP 7.2 y 7.3 quedan fuera.

WordPress 7.0 y el cliente IA nativo: por qué importa

Hasta ahora, cada plugin que quería usar IA tenía que resolver su propia integración: traer el SDK de OpenAI, manejar sus propias claves API, reinventar el manejo de errores. El resultado era una proliferación de configuraciones dispersas y, lo más problemático, que cada plugin pedía al usuario sus propias credenciales. WordPress 7.0 resuelve eso con un cliente IA centralizado que forma parte del core.

WordPress es un sistema de gestión de contenidos de código abierto para crear y administrar sitios web, desarrollado por la comunidad WordPress desde 2003. Su código fuente está disponible públicamente y puede ser modificado y redistribuido por cualquier usuario.

El enfoque es provider-agnostic: el core no apuesta a un solo proveedor. Soporta OpenAI, Google y Anthropic desde el primer día, con soporte comunitario para OpenRouter, Ollama y Mistral. Eso significa que si un sitio migra de ChatGPT a Gemini, la configuración cambia en un solo lugar y todos los plugins se adaptan automáticamente.

Lo interesante es que esta decisión llega después de años donde el ecosistema creció de forma caótica en torno a IA. Plugins de generación de contenido, asistentes de escritura, chatbots: cada uno con su propia clave, su propio modelo, su propia pantalla de configuración. La unificación tiene sentido, aunque habría que ver cuántos plugins legacy optan por migrar y cuántos siguen con su integración propia.

wp_ai_client_prompt(): la función PHP central

La función wp_ai_client_prompt() es el punto de entrada principal para interactuar con el proveedor de IA configurado. Su firma básica recibe un string de prompt y un array de opciones, y retorna el texto generado o un objeto WP_Error en caso de falla. Eso es estándar WordPress: nada nuevo que aprender si ya desarrollás plugins.

$result = wp_ai_client_prompt(
 'Resumí este artículo en tres oraciones: ' . $content,
 array(
 'model' => 'gpt-4o',
 'max_tokens' => 300,
 'temperature' => 0.7,
 )
);

if ( is_wp_error( $result ) ) {
 // Manejar error
 error_log( $result->get_error_message() );
} else {
 echo esc_html( $result );
}

Los parámetros de modelo y temperatura son opcionales: si no los especificás, el cliente usa los defaults del proveedor configurado en Ajustes. Eso tiene una ventaja clara para plugins que quieren ser agnósticos al modelo, pero implica que el developer pierde control fino sobre qué modelo específico se usa en producción. Conviene documentarlo en el README del plugin.

El manejo de errores sigue las convenciones de WordPress. Los códigos de error incluyen situaciones como proveedor no configurado, cuota de API agotada o timeout. Lo que no hay, al menos en esta iteración, es un sistema de budget o límite de gasto integrado en core. Cualquier plugin puede llamar a la función sin restricciones de costo, lo cual es un vector de abuso que vale considerar antes de publicar en el directorio oficial. Más contexto en crear landing pages optimizadas.

Connectors API: gestión centralizada de proveedores

La pantalla de Connectors aparece en Ajustes y permite configurar el proveedor de IA una sola vez para todo el sitio. Desde ahí el administrador ingresa la clave API, selecciona el proveedor y, opcionalmente, elige el modelo por defecto. Los plugins que usan wp_ai_client_prompt() heredan esa configuración automáticamente.

Los proveedores soportados en el lanzamiento son OpenAI, Google (Gemini) y Anthropic (Claude). Además, la comunidad ya aportó integraciones para OpenRouter, Ollama y Mistral. OpenRouter es particularmente útil porque actúa como intermediario y da acceso a decenas de modelos con una sola clave, lo que facilita la evaluación de alternativas sin cambiar código.

El tema es que la pantalla no incluye controles de uso por plugin. Si un sitio tiene diez plugins que consumen IA, todos comparten la misma clave sin cuotas individuales. Para un blog personal eso no importa, pero para una agencia que maneja sitios de clientes esto puede generar sorpresas en la factura. La documentación no menciona soporte para múltiples perfiles de Connectors por rol de usuario tampoco, al menos en la versión inicial.

Abilities API en JavaScript: @wordpress/abilities y @wordpress/core-abilities

La Abilities API llegó al lado PHP con WordPress 6.9. WordPress 7.0 completa el cuadro con su contraparte en JavaScript, distribuida en dos paquetes separados con responsabilidades distintas.

@wordpress/abilities es la capa de gestión de estado: expone un store de Zustand-compatible que contiene las abilities del usuario actual. No tiene dependencia de WordPress en sí; podría usarse en otro contexto de React. @wordpress/core-abilities, en cambio, es la integración con WordPress: conecta ese store al REST API de WordPress, hidrata las abilities al cargar el editor, y expone selectores y acciones que ya hablan el lenguaje de @wordpress/data.

Para un bloque o plugin, el flujo es: importar @wordpress/core-abilities, usar el selector getAbility( 'mi-plugin/publicar-en-redes' ) y condicionar la UI según el resultado. El REST endpoint devuelve las abilities con su estado actual, incluyendo si están activas, si el usuario tiene permiso para ejecutarlas y los metadatos registrados. Eso permite UIs más granulares que el sistema de capabilities binario que tenía WordPress hasta ahora.

Ahora bien, la adopción depende de que los plugins registren sus abilities correctamente en PHP. Si la base de plugins existentes no migra, el sistema JS queda subutilizado. Habrá que ver con qué velocidad el ecosistema abraza este patrón.

Registrar habilidades en plugins con wp_register_ability()

Del lado PHP, el registro de una ability sigue un patrón que va a resultar familiar para cualquiera que haya trabajado con REST endpoints en WordPress. Se llama dentro del hook wp_abilities_api_init y recibe un identificador con namespace, un array de configuración y callbacks opcionales. Tema relacionado: probar cambios en un entorno seguro.

add_action( 'wp_abilities_api_init', function() {
 wp_register_ability(
 'mi-plugin/generar-resumen',
 array(
 'label' => __( 'Generar resumen con IA', 'mi-plugin' ),
 'schema' => array(
 'input' => array( 'type' => 'string' ),
 'output' => array( 'type' => 'string' ),
 ),
 'show_in_rest' => true,
 'permission' => function( $user_id ) {
 return user_can( $user_id, 'edit_posts' );
 },
 'execute' => function( $args ) {
 return wp_ai_client_prompt( 'Resumí: ' . $args['input'] );
 },
 )
 );
} );

El parámetro show_in_rest es lo que expone la ability al endpoint REST y, por lo tanto, la hace consumible desde JavaScript. Sin ese flag, la ability existe solo en el lado del servidor. El callback permission controla quién puede ejecutarla: podés usar cualquier capability de WordPress o lógica custom.

El schema JSON define qué espera la ability como input y qué devuelve. No es obligatorio pero es una buena práctica, especialmente si el plugin va al directorio oficial: facilita la validación automática y la documentación generada por herramientas.

PHP 7.4 mínimo: qué significa en la práctica

Este punto ya estaba en el artículo original, pero vale una actualización de contexto. La decisión está confirmada: PHP 7.2 y 7.3 quedan fuera con WordPress 7.0. El mínimo pasa a ser PHP 7.4, y la versión recomendada es 8.3 o superior.

Para la mayoría de los sitios en hosting administrado moderno, esto no cambia nada: los paneles como cPanel o Plesk llevan años ofreciendo PHP 8.x. El impacto real está en dos escenarios: servidores VPS con configuraciones antiguas que nadie tocó desde 2020, y algunos planes de hosting compartido de bajo costo que siguen ofreciendo PHP 7.x como opción predeterminada.

Más importante: plugins que usan funciones deprecadas en PHP 8.x (como create_function() o el operador de concatenación en interpolaciones) pueden generar warnings o errores fatales al actualizar. El checklist antes de migrar incluye revisar el log de PHP del sitio, actualizar en staging primero, y auditar plugins con PHP_CodeSniffer con el estándar PHPCompatibility.

Antes y ahora: integrar IA en un plugin de WordPress

El cambio de paradigma es concreto. Vale verlo en perspectiva comparativa.

Aspecto	Antes de WordPress 7.0	Con WordPress 7.0
Integración de IA	Cada plugin instala su propio SDK (openai-php, google-cloud, etc.)	Una función nativa: `wp_ai_client_prompt()`
Configuración de credenciales	Pantalla de ajustes propia por plugin	Pantalla centralizada de Connectors en Ajustes
Proveedores soportados	Solo el que integró el plugin	OpenAI, Google, Anthropic + OpenRouter, Ollama, Mistral
Cambio de proveedor	Reemplazar SDK + reconfigurar cada plugin	Cambiar en Connectors, todos los plugins se adaptan
Abilities en frontend	Capabilities binarias de WordPress (can/cannot)	Sistema granular con schemas, callbacks y REST
Control de gasto de API	Por plugin (si lo implementó el developer)	No hay límite nativo en core (ver advertencia)

wordpress 7.0 cliente ia diagrama explicativo

La ganancia para site owners es clara: menos pantallas de configuración, menos claves API volando por distintos lugares, y posibilidad de cambiar de proveedor sin tocar cada plugin por separado. Para developers, la ganancia es poder distribuir un plugin con funcionalidades IA sin tener que incluir ni mantener un SDK de terceros.

Errores a evitar: seguridad, gasto sin control y fallback de modelos

El sistema centralizado de Connectors resuelve un problema de UX pero crea uno nuevo de seguridad. Cualquier plugin activo en el sitio puede llamar a wp_ai_client_prompt() y consumir créditos de la clave API configurada. No hay sandbox, no hay cuotas por plugin, no hay alerta de umbral de gasto. Para un sitio con muchos plugins activos, esto es un riesgo real. Cubrimos ese tema en detalle en evitar y reparar enlaces rotos.

La mejor práctica, hasta que core incorpore controles de budget, es usar una clave API con límite de gasto configurado directamente en el proveedor. OpenAI, Anthropic y Google permiten setear límites mensuales desde su panel. Eso no resuelve el problema a nivel plugin, pero sí evita sorpresas en la factura.

Otro punto: el fallback de modelos. Si el proveedor configurado no está disponible o el modelo solicitado no existe, wp_ai_client_prompt() devuelve un WP_Error. No hay fallback automático a un modelo alternativo. Si tu plugin necesita resiliencia, tenés que implementar la lógica de fallback manualmente: intentar con el modelo primario, capturar el error, reintentar con uno secundario. Es código extra pero necesario para funcionalidades críticas.

En cuanto al almacenamiento de claves, las Connectors API las guarda en la tabla wp_options con cifrado. No las almacena en texto plano, pero eso no reemplaza tener un servidor con filesystem restringido y sin acceso público a la base de datos.

Qué está confirmado y qué todavía no está confirmado

Confirmado para WordPress 7.0

wp_ai_client_prompt() en core PHP.
Pantalla de Connectors en Ajustes con soporte para OpenAI, Google, Anthropic, OpenRouter, Ollama, Mistral.
Paquetes npm @wordpress/abilities y @wordpress/core-abilities con soporte para REST.
PHP 7.4 como mínimo requerido; soporte beta para PHP 8.4 y 8.5.
wp_register_ability() con schemas JSON y expose via REST.

Todavía no confirmado o pendiente de definición

Sistema de cuotas o budget por plugin dentro de core.
Soporte para múltiples perfiles de Connectors (por rol o por entorno).
Fallback automático de modelo en wp_ai_client_prompt().
UI nativa en el editor de bloques (Gutenberg) que consuma abilities registradas por plugins de terceros.
Fecha exacta de lanzamiento de WordPress 7.0 (el boletín de abril lo sitúa como próxima versión mayor sin fecha definitiva pública).

Qué significa para equipos y agencias en Latinoamérica

Para agencias que desarrollan plugins o temas con funcionalidades IA, el cambio más inmediato es simplificación de distribución: ya no hace falta incluir ni versionar un SDK de IA como dependencia del plugin. Eso reduce el peso del paquete y elimina una categoría de conflictos de versiones con otros plugins.

Esto se conecta directamente con lo que cubrimos en el Developer Newsletter de abril: WP AI Client, Abilities API e.

Lo tocamos con detalle en el Developer Newsletter de abril: WP AI Client, Abilities API e.

Esto se conecta directamente con el Developer Newsletter de abril: WP AI Client, Abilities API e, donde ampliamos el detalle.

Cubrimos esto con más detalle en el Developer Newsletter de abril: WP AI Client, Abilities API e.

Mirá nuestro Developer Newsletter de abril: WP AI Client, Abilities API e para más detalles.

El punto de friccción está en la adopción. Muchos clientes finales todavía tienen sitios en PHP 7.x con hosting compartido de hace cinco años. Si tu agencia mantiene esos sitios, WordPress 7.0 implica gestionar la migración de PHP antes de poder actualizar el core. Conviene empezar ahora: auditar la cartera de sitios, identificar cuáles están en PHP 7.2 o 7.3, y coordinar con el hosting la actualización.

Para productos SaaS construidos sobre WordPress, la Connectors API abre una oportunidad: si ya ofrecés integración con OpenAI o Anthropic como feature diferencial, evaluar si migrar a la abstracción nativa o mantener la integración propia. La respuesta depende de cuánto control fino necesitás sobre el modelo y los parámetros de la llamada. Ya lo cubrimos antes en cómo actualizar WordPress correctamente.

Preguntas frecuentes

¿Qué es el cliente IA nativo de WordPress 7.0?

Es una función PHP incluida en el core de WordPress, wp_ai_client_prompt(), que permite a cualquier plugin enviar prompts a un proveedor de IA (OpenAI, Google, Anthropic y otros) sin necesidad de instalar un SDK externo. El proveedor se configura una sola vez desde Ajustes y todos los plugins lo heredan automáticamente.

¿Cómo uso wp_ai_client_prompt() en mis plugins?

Llamás a la función con un string de prompt y un array de opciones (modelo, tokens, temperatura). Devuelve el texto generado si tiene éxito, o un objeto WP_Error si algo falla. No necesitás manejar autenticación con el proveedor: eso ya está resuelto por la Connectors API configurada en Ajustes. Sí conviene manejar los errores con is_wp_error() para dar feedback al usuario cuando el proveedor no está disponible.

¿Qué diferencia hay entre la Abilities API y la Connectors API?

Son sistemas con propósitos distintos. La Connectors API gestiona proveedores de IA: qué servicio usar, con qué credenciales, con qué modelo por defecto. La Abilities API, en cambio, es un sistema de permisos granulares: define qué acciones puede ejecutar cada usuario en un plugin, con schemas de input/output y lógica de autorización. Se pueden usar de forma independiente, aunque muchas abilities en WordPress 7.0 van a invocar wp_ai_client_prompt() internamente.

¿Qué proveedores de IA soporta WordPress 7.0?

En el lanzamiento: OpenAI, Google Gemini y Anthropic Claude de forma oficial. La comunidad ya aportó integraciones para OpenRouter, Ollama (para modelos locales) y Mistral. OpenRouter es útil porque actúa como intermediario y permite acceder a docenas de modelos con una sola clave API, lo que lo convierte en una opción práctica para entornos donde querés flexibilidad sin multiplicar credenciales.

¿Cuál es el mínimo de PHP requerido para WordPress 7.0?

PHP 7.4 es el mínimo. PHP 7.2 y 7.3 dejan de ser soportados. La versión recomendada es PHP 8.3 o superior. WordPress 7.0 también tiene compatibilidad beta con PHP 8.4 y 8.5. Si tu sitio aún corre en PHP 7.2 o 7.3, no vas a poder actualizar al core 7.0 sin antes actualizar PHP desde el panel de tu hosting.

Conclusión

WordPress 7.0 es una apuesta concreta a unificar la integración de IA dentro del core. El cliente nativo con wp_ai_client_prompt(), la pantalla de Connectors y la Abilities API en JavaScript cambian la forma en que los plugins van a consumir y exponer funcionalidades de IA. El enfoque provider-agnostic es inteligente: no obliga al ecosistema a apostar por un solo modelo.

Los puntos sin resolver son reales: no hay control de gasto por plugin, no hay fallback automático de modelo, y la adopción del ecosistema va a tardar. Plugins establecidos con sus propias integraciones de IA tienen pocos incentivos para migrar en el corto plazo. Pero para proyectos nuevos, la simplificación es considerable.

Si desarrollás plugins o mantenés sitios de clientes, el paso más urgente es el de siempre: revisar que ningún sitio corra PHP 7.2 o 7.3 antes de que llegue la actualización. Después, vale explorar la Abilities API: es la parte que más va a cambiar cómo se construyen interfaces granulares en WordPress en los próximos años.

En DonWeb, nuestros planes de hosting ya incluyen PHP 8.1 y superiores, así que los sitios alojados con nosotros están listos para WordPress 7.0 sin necesitar ningún cambio de configuración.

Fuentes

Volver a

Novedades