Actualización, 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 colaboración en tiempo real se retiró durante las pruebas RC y no forma parte de la 7.0. Esta guía es el resumen post-lanzamiento; las secciones antiguas de la hoja de ruta a continuación se conservan como contexto histórico, no como descripción de lo que está activo en una instalación 7.0 hoy.
WordPress 7.0 "Armstrong" se lanzó en mayo de 2026 tras un ciclo release candidate más largo de lo habitual. El lanzamiento fue construido por más de 900 contribuidores. El cambio principal es la infraestructura de IA en el núcleo: la superficie Abilities API para operaciones seguras de admin, el AI Services Registry para integración de modelos alojados y el WordPress AI Client en torno al cual los plugins de terceros se están 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 también se entregaron. La colaboración en tiempo real se retiró de este lanzamiento durante las pruebas RC y no forma parte de la actualización.
Para una polémica más afilada sobre lo que la superficie de IA del 7.0 significa concretamente para los autores de plugins, lee nuestro texto sobre por qué un servidor MCP en tu plugin WordPress es el movimiento de IA que sobrevive. Para la implicación de seguridad post-lanzamiento, lee nuestra lectura del informe GuardingWP State of WordPress Security 2026, que sitúa 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 más 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 lanzó en mayo de 2026 tras un ciclo release candidate inusualmente largo (RC4 salió el 14 de mayo de 2026, el lanzamiento final siguió poco después). El nombre “Armstrong” continúa la tradición de WordPress de bautizar las versiones mayores con nombres de músicos de jazz.
Si planificas una actualización en producción, la ventana más 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.
Qué se entregó realmente en la 7.0 Armstrong
Esta es la lista confirmada de funciones del anuncio de lanzamiento de wordpress.org, no la intención anterior de la hoja de ruta. Cualquier cosa de la hoja de ruta antigua que no aparezca aquí no se entregó en la 7.0.
- Infraestructura de IA en el núcleo. La Abilities API para operaciones seguras de admin a través 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 están 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 razón 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 mínimo. Los sitios aun en PHP más antiguo deben actualizar su entorno de servidor antes de actualizar a la 7.0.
- Más de 900 contribuidores. El Product Manager de WP Charitable, David Bisset, agradeció públicamente a los contribuidores y “a sus cónyuges, parejas, familias, mascotas, mecanismos de afrontamiento y consejeros que los apoyaron” - que es la línea más honesta escrita sobre una versión mayor de WordPress en años.
Lo que no se entregó y ya no se espera en la línea 7.0:
- La colaboración en tiempo real se retiró de este lanzamiento tras las pruebas release candidate. La descripción anterior de la hoja de ruta más abajo en esta guía se preserva como contexto histórico.
Seguridad: proteger las claves API de los proveedores de IA desde el primer día
El fundador de Patchstack, Oliver Sild, publicó públicamente 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 instalación 7.0 ya no solo permite a un atacante cambiar contenido; también 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 señaló por separado que el WP AI Client no tiene throttle integrado y varios plugins compartiendo una clave pueden agotar el límite 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 aplicaría a cualquier credencial facturable recién 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), configúralos lo suficientemente bajos para que un consumo anómalo sea visible contra un ciclo de facturación.
- Alertar sobre gasto anómalo de tokens dentro del ciclo, no a final de mes. La mayoría de proveedores expone una API de facturación diaria; conéctala con tu monitorización.
- Registrar en audit log el uso de los conectores en el lado WordPress. La Abilities API expone IDs de operación; regístralos en un flujo separado del audit log normal de wp-admin.
En España, INCIBE-CERT establece umbrales de notificación 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 artículo 21 párrafo 2 letra d de NIS2 para entidades en el ámbito. Trata la nueva superficie de IA como una nueva clase de acuerdo TIC con terceros y regístrala 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, navegación | Completada |
| Fase 3 | Colaboración, flujos de trabajo, integración de IA | WordPress 7.0 |
| Fase 4 | Multilingüismo | Planificada (2027+) |
La Fase 4 traerá capacidades multilingües nativas, lo que significa que WordPress finalmente gestionará la traducción de contenido a nivel del núcleo en lugar de depender de plugins como WPML o Polylang. Para agencias que gestionan sitios multilingües hoy, esta es la función a vigilar en la hoja de ruta post-7.0.
IA en WordPress ahora que la 7.0 se ha lanzado
La versión 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 producción:
- Yoast y Rank Math ambos incluyen asistentes de escritura asistidos por IA (títulos, meta descripciones, sugerencias de enlaces internos) construidos sobre APIs de modelos de terceros.
- Jetpack AI Assistant ofrece generación en el editor, resumen y traducción. La calidad varía según el idioma y el prompt.
- Plugins independientes de generación de contenido existen en un amplio rango de calidad; útiles para borradores, peligrosos cuando se conectan directamente a la publicación sin revisión humana.
- Automattic y los equipos de contribuidores ejecutan experimentos de Fase 3, incluyendo edición colaborativa y llamadas de IA del lado del editor, en el plugin Gutenberg antes de cualquier merge al core.
Una arquitectura pragmática para añadir IA a un sitio WordPress hoy, que probablemente sobrevivirá a lo que sea que 7.0 entregue:
- Expón un pequeño endpoint REST API por proveedor (OpenAI, Anthropic, Google, o un modelo auto-alojado). Mantén el código específico del proveedor detrás de una interfaz para que cambiar de modelo sea un cambio de configuración, no una reescritura.
- Ejecuta cualquier cosa que tarde más de unos segundos a través de Action Scheduler, no una solicitud síncrona. Este es el mismo patrón que usa WooCommerce; escala.
- Almacena las claves de API como constantes de
wp-config.phpo vía un almacén 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 más la versión del modelo. Las llamadas de IA son caras y se repiten con frecuencia.
Modos de fallo que vale la pena diseñar contra desde el primer día:
- 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 tráfico, que silenciosamente degradan la experiencia del editor si no hay fallback.
- Hechos, citas o especificaciones de producto alucinados publicados sin un paso de revisión humana. El coste de una página mala en búsqueda es mayor que el coste de cualquier flujo de revisión.
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 ética y enmarque editorial, ve la guía de ética de contenido de IA para editores.
Cómo prepararse sin adivinar la migración
Lo que puedes hacer ahora es reducir el coste futuro de migración independientemente de cómo sea 7.0. El trabajo es ingrato y se paga en cada release, no solo en este.
Audita las partes del stack más propensas a romperse en una actualización 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 última estable. - Page builders con su propia capa de renderizado. Estas son la causa más común de deuda “no podemos actualizar”.
- Endpoints REST personalizados sin versionado. Añade namespacing
/v1/ahora para que un futuro incremento no sea disruptivo.
Configura la infraestructura aburrida que te permite actualizar rápido:
- Un entorno de staging que refleje la versión de PHP, conjunto de plugins y volumen de contenido de producción. La paridad de base de datos importa más de lo que la gente espera.
- Backups automatizados con un camino de restauración 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 están atascados porque nadie actualizó 6.1 a 6.8.
- Una lista corta de autores de plugins en los que confías, con contactos de email. Querrás saber dentro de una semana cuáles de tus plugins están probados contra la 7.0.
La ruta de actualización 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 producción para sitios de clientes, y lee la publicación oficial de field guide en Make WordPress antes de asumir que cualquier guía de terceros (esta incluida) refleja lo que realmente se entregó.
Qué hacer en la semana de lanzamiento de la 7.0
Con la 7.0 entregada, el trabajo útil es operacional: actualización en staging, comprobaciones de compatibilidad de plugins, pruebas de flujos WooCommerce y LMS, y un plan de rollback antes de producción.
Sigue el blog Make WordPress core, las notas de release de Gutenberg y el milestone de trac para cambios de última hora en el field guide. Para un proyecto existente en 6.x, mantén block themes, theme.json y la REST API como la baseline compatible con el futuro.
Si quieres ayuda para auditar un stack para preparación de actualización, nuestro equipo de desarrollo WordPress hace ese trabajo para sitios en producción en cada ciclo de release.
