Actualizacion, 23 de mayo de 2026: WordPress 7.0 con el nombre en clave Armstrong ha sido lanzado. El lanzamiento cierra la Fase 3 de la hoja de ruta Gutenberg con infraestructura fundamental de IA (Abilities API + AI Services Registry + AI Client), un panel modernizado, Command Palette en todas partes, CSS personalizado a nivel de bloque y el bloque Icons. La colaboracion en tiempo real se retiro durante las pruebas RC y no forma parte de la 7.0. Esta guia es el resumen post-lanzamiento; las secciones antiguas de la hoja de ruta a continuacion se conservan como contexto historico, no como descripcion de lo que esta activo en una instalacion 7.0 hoy.
WordPress 7.0 "Armstrong" se lanzo en mayo de 2026 tras un ciclo release candidate mas largo de lo habitual. El lanzamiento fue construido por mas de 900 contribuidores. El cambio principal es la infraestructura de IA en el nucleo: la superficie Abilities API para operaciones seguras de admin, el AI Services Registry para integracion de modelos alojados y el WordPress AI Client en torno al cual los plugins de terceros se estan estandarizando ahora. El panel admin modernizado, Command Palette disponible en todas partes en wp-admin, CSS personalizado a nivel de bloque y el bloque Icons tambien se entregaron. La colaboracion en tiempo real se retiro de este lanzamiento durante las pruebas RC y no forma parte de la actualizacion.
Para una polemica mas afilada sobre lo que la superficie de IA del 7.0 significa concretamente para los autores de plugins, lee nuestro texto sobre por que un servidor MCP en tu plugin WordPress es el movimiento de IA que sobrevive. Para la implicacion de seguridad post-lanzamiento, lee nuestra lectura del informe GuardingWP State of WordPress Security 2026, que situa la nueva superficie de claves de IA en contexto con la baseline del 53 por ciento de CVE sin parchear.
Sigue make.wordpress.org/core y el feed oficial wordpress.org/news para lanzamientos de parches posteriores.
Descubre mas sobre desarrollo profesional de WordPress en WPPoland.
Fecha de lanzamiento y nombre en clave de WordPress 7.0
WordPress 7.0 con el nombre en clave Armstrong se lanzo en mayo de 2026 tras un ciclo release candidate inusualmente largo (RC4 salio el 14 de mayo de 2026, el lanzamiento final siguio poco despues). El nombre “Armstrong” continua la tradicion de WordPress de bautizar las versiones mayores con nombres de musicos de jazz.
Si planificas una actualizacion en produccion, la ventana mas segura sigue siendo de dos a cuatro semanas tras el lanzamiento final, cuando el primer ciclo de parches captura los problemas de compatibilidad reportados por early adopters.
Que se entrego realmente en la 7.0 Armstrong
Esta es la lista confirmada de funciones del anuncio de lanzamiento de wordpress.org, no la intencion anterior de la hoja de ruta. Cualquier cosa de la hoja de ruta antigua que no aparezca aqui no se entrego en la 7.0.
- Infraestructura de IA en el nucleo. La Abilities API para operaciones seguras de admin a traves de intents estructurados, el AI Services Registry para conectar proveedores de modelos alojados (Anthropic, OpenAI, Vercel AI Gateway, auto-alojados) y el WordPress AI Client contra el cual los plugins de terceros estan construyendo ahora. Este es el cambio de plataforma que define el lanzamiento.
- Command Palette en todas partes. Cmd-K / Ctrl-K abre la Command Palette en cada pantalla de wp-admin, no solo en el editor de bloques. La superficie de atajos para usuarios avanzados es ahora de primera clase.
- CSS personalizado a nivel de bloque. Cada bloque puede llevar su propio CSS, acotado a ese bloque. Elimina una razon de larga data para bajar a un tema personalizado.
- Bloque Icons. Un bloque nativo para incorporar iconos SVG desde una biblioteca curada, con tokens de color conscientes del tema.
- Panel modernizado. Superficies de aterrizaje del admin renovadas, con los experimentos de IA agente visibles tras una feature flag.
- PHP 7.4 como runtime minimo. Los sitios aun en PHP mas antiguo deben actualizar su entorno de servidor antes de actualizar a la 7.0.
- Mas de 900 contribuidores. El Product Manager de WP Charitable, David Bisset, agradecio publicamente a los contribuidores y “a sus conyuges, parejas, familias, mascotas, mecanismos de afrontamiento y consejeros que los apoyaron” - que es la linea mas honesta escrita sobre una version mayor de WordPress en anos.
Lo que no se entrego y ya no se espera en la linea 7.0:
- La colaboracion en tiempo real se retiro de este lanzamiento tras las pruebas release candidate. La descripcion anterior de la hoja de ruta mas abajo en esta guia se preserva como contexto historico.
Seguridad: proteger las claves API de los proveedores de IA desde el primer dia
El fundador de Patchstack, Oliver Sild, publico publicamente en X en torno al lanzamiento: “there will be an absolute rush by hackers to steal API keys.” El riesgo es concreto. Una credencial wp-admin comprometida en una instalacion 7.0 ya no solo permite a un atacante cambiar contenido; tambien le permite drenar una factura mensual de tokens de cuatro o cinco cifras contra tu proveedor de IA antes de que la factura lo capture. Justin Nealey senalo por separado que el WP AI Client no tiene throttle integrado y varios plugins compartiendo una clave pueden agotar el limite de tokens en menos de un minuto.
La superficie de control a aplicar es directa y es la misma superficie de control que un equipo financiero aplicaria a cualquier credencial facturable recien emitida:
- Acotar las claves API por conector, no por sitio. Una clave por proveedor por conector. Rotar en una cadencia publicada.
- Aplicar rate limits en el gateway, no en el plugin. Si tu proveedor soporta rate limits por clave (Anthropic, OpenAI, Vercel AI Gateway todos lo soportan), configuralos lo suficientemente bajos para que un consumo anomalo sea visible contra un ciclo de facturacion.
- Alertar sobre gasto anomalo de tokens dentro del ciclo, no a final de mes. La mayoria de proveedores expone una API de facturacion diaria; conectala con tu monitorizacion.
- Registrar en audit log el uso de los conectores en el lado WordPress. La Abilities API expone IDs de operacion; registralos en un flujo separado del audit log normal de wp-admin.
En Espana, INCIBE-CERT establece umbrales de notificacion de incidentes para entidades obligadas; trata el abuso de claves de IA almacenadas en wp-admin como un incidente reportable y prepara el primer informe dentro del plazo regulatorio aplicable. Estos controles se mapean directamente con los controles de cadena de suministro ya exigidos por el articulo 21 parrafo 2 letra d de NIS2 para entidades en el ambito. Trata la nueva superficie de IA como una nueva clase de acuerdo TIC con terceros y registrala en consecuencia.
Hoja de ruta de WordPress 7.0
WordPress 7.0 se situa al final de la Fase 3 del plan de cuatro fases del proyecto Gutenberg:
| Fase | Foco | Estado |
|---|---|---|
| Fase 1 | Editor de bloques (Gutenberg) | Completada |
| Fase 2 | Full Site Editing, patrones, navegacion | Completada |
| Fase 3 | Colaboracion, flujos de trabajo, integracion de IA | WordPress 7.0 |
| Fase 4 | Multilinguismo | Planificada (2027+) |
La Fase 4 traera capacidades multilingues nativas, lo que significa que WordPress finalmente gestionara la traduccion de contenido a nivel del nucleo en lugar de depender de plugins como WPML o Polylang. Para agencias que gestionan sitios multilingues hoy, esta es la funcion a vigilar en la hoja de ruta post-7.0.
IA en WordPress ahora que la 7.0 se ha lanzado
La version honesta de “funciones de IA en WordPress 7.0” comienza con lo que ya funciona en 6.x, porque eso es lo que ejecutan sitios reales.
Disponible hoy, en WordPress de produccion:
- Yoast y Rank Math ambos incluyen asistentes de escritura asistidos por IA (titulos, meta descripciones, sugerencias de enlaces internos) construidos sobre APIs de modelos de terceros.
- Jetpack AI Assistant ofrece generacion en el editor, resumen y traduccion. La calidad varia segun el idioma y el prompt.
- Plugins independientes de generacion de contenido existen en un amplio rango de calidad; utiles para borradores, peligrosos cuando se conectan directamente a la publicacion sin revision humana.
- Automattic y los equipos de contribuidores ejecutan experimentos de Fase 3, incluyendo edicion colaborativa y llamadas de IA del lado del editor, en el plugin Gutenberg antes de cualquier merge al core.
Una arquitectura pragmatica para anadir IA a un sitio WordPress hoy, que probablemente sobrevivira a lo que sea que 7.0 entregue:
- Expon un pequeno endpoint REST API por proveedor (OpenAI, Anthropic, Google, o un modelo auto-alojado). Manten el codigo especifico del proveedor detras de una interfaz para que cambiar de modelo sea un cambio de configuracion, no una reescritura.
- Ejecuta cualquier cosa que tarde mas de unos segundos a traves de Action Scheduler, no una solicitud sincrona. Este es el mismo patron que usa WooCommerce; escala.
- Almacena las claves de API como constantes de
wp-config.phpo via un almacen de secretos gestionado cargado en el arranque. Nunca pongas claves vivas en opciones de plugins ni en archivos.envcommiteados a un repositorio. - Cachea las respuestas con clave en un hash del prompt mas la version del modelo. Las llamadas de IA son caras y se repiten con frecuencia.
Modos de fallo que vale la pena disenar contra desde el primer dia:
- Fuga de claves de API mediante auto-actualizaciones de plugins o backups que incluyen volcados de
wp-content. - Fallos de rate-limit durante picos de trafico, que silenciosamente degradan la experiencia del editor si no hay fallback.
- Hechos, citas o especificaciones de producto alucinados publicados sin un paso de revision humana. El coste de una pagina mala en busqueda es mayor que el coste de cualquier flujo de revision.
Si 7.0 introduce una capa de abilities o connectors en el core, se aplican las mismas fronteras: la superficie de la API cambia, los modos de fallo no. Para etica y enmarque editorial, ve la guia de etica de contenido de IA para editores.
Como prepararse sin adivinar la migracion
Lo que puedes hacer ahora es reducir el coste futuro de migracion independientemente de como sea 7.0. El trabajo es ingrato y se paga en cada release, no solo en este.
Audita las partes del stack mas propensas a romperse en una actualizacion mayor:
- Temas que aun usan template tags en
functions.phpen vez de block themes. Convierte a block themes o planifica el trabajo. - Bloques Gutenberg personalizados construidos contra versiones tempranas de
@wordpress/scripts. Fija y prueba contra la ultima estable. - Page builders con su propia capa de renderizado. Estas son la causa mas comun de deuda “no podemos actualizar”.
- Endpoints REST personalizados sin versionado. Anade namespacing
/v1/ahora para que un futuro incremento no sea disruptivo.
Configura la infraestructura aburrida que te permite actualizar rapido:
- Un entorno de staging que refleje la version de PHP, conjunto de plugins y volumen de contenido de produccion. La paridad de base de datos importa mas de lo que la gente espera.
- Backups automatizados con un camino de restauracion probado. Un backup no probado es teatro.
- Actualizaciones de plugins y temas corriendo a un ritmo regular, no aplazadas hasta el siguiente release mayor. Los sitios atascados en 6.0 estan atascados porque nadie actualizo 6.1 a 6.8.
- Una lista corta de autores de plugins en los que confias, con contactos de email. Querras saber dentro de una semana cuales de tus plugins estan probados contra la 7.0.
La ruta de actualizacion es la misma que ha funcionado para cada release mayor de WordPress: ejecuta primero en staging, observa el log de errores, espera dos a cuatro semanas tras la disponibilidad general antes de tocar produccion para sitios de clientes, y lee la publicacion oficial de field guide en Make WordPress antes de asumir que cualquier guia de terceros (esta incluida) refleja lo que realmente se entrego.
Que hacer en la semana de lanzamiento de la 7.0
Con la 7.0 entregada, el trabajo util es operacional: actualizacion en staging, comprobaciones de compatibilidad de plugins, pruebas de flujos WooCommerce y LMS, y un plan de rollback antes de produccion.
Sigue el blog Make WordPress core, las notas de release de Gutenberg y el milestone de trac para cambios de ultima hora en el field guide. Para un proyecto existente en 6.x, manten block themes, theme.json y la REST API como la baseline compatible con el futuro.
Si quieres ayuda para auditar un stack para preparacion de actualizacion, nuestro equipo de desarrollo WordPress hace ese trabajo para sitios en produccion en cada ciclo de release.
