Toda gran versión de WordPress se convierte en el campo de dos exageraciones al mismo tiempo: por un lado, quien anuncia la revolución; por el otro, quien asegura que nada cambia. La verdad casi nunca está en el medio — está en el detalle. Y WordPress 7.0 “Armstrong”, lanzado el 20 de mayo de 2026, tiene detalles que importan de verdad para quien opera un sitio en producción, no solo para quien escribe changelogs.
Este texto es la referencia práctica de lo que el 7.0 cambia en tu operación. Sin capturas bonitas de una función que nunca vas a usar. La pregunta que guía cada sección es una sola: ¿esto cambia algo en mi día a día, en mi servidor, en mi costo de mantenimiento? Donde la respuesta sea “no”, decimos “no”. Donde sea “sí, y tienes que actuar”, decimos qué hacer.
WordPress 7.0 “Armstrong” es la versión que trajo las primeras fundaciones de IA al core, el primer rediseño del admin desde 2013 y una nueva forma de registrar bloques solo en PHP — además de descartar el soporte a PHP 7.2 y 7.3.
IA en el core: fundación, no asistente listo
El titular del 7.0 es la IA. Pero es aquí donde vive la mayor confusión. El 7.0 no puso un asistente de escritura dentro del editor. Lo que puso fue la tubería: un AI Client agnóstico de proveedor, una Abilities API ampliada y una nueva pantalla en Configuración llamada Conectores, que ya soporta Anthropic, Google y OpenAI como proveedores por defecto.
Traducido a la operación: WordPress ahora tiene una manera estandarizada de que los plugins expongan funcionalidades a agentes de IA — y a otros plugins. La cobertura de InfoQ sobre el release lo describe como “fundaciones de IA en el core”, y esa es la palabra correcta: fundación. Es la diferencia entre que la compañía eléctrica lleve el poste hasta tu calle y que tú tengas una ducha caliente. El 7.0 trajo el poste.
¿Por qué te importa esto aun sin usar IA hoy? Porque estandariza. Antes, cada plugin de IA hablaba con OpenAI a su manera, guardaba la clave de API a su manera, manejaba los errores a su manera. Con la Abilities API y el AI Client, ese contrato pasa a ser del core. El ecosistema deja de reinventar la rueda, y tú ganas previsibilidad de seguridad y mantenimiento. La ganancia real llega en los próximos meses, a medida que los plugins adopten la fundación — no el día de la actualización.
Qué hacer en la práctica
Si no usas IA en el sitio, no necesitas tocar nada: la pantalla de Conectores viene vacía e inerte. Si piensas usarla, el camino pasa a ser conectar un proveedor una vez, en Configuración > Conectores, y dejar que los plugins lo consuman desde ahí — en lugar de esparcir la clave de API por seis lugares. Es una ganancia de gobernanza que vale la pena adoptar con calma, y que se conecta directamente con la seguridad de WordPress: una clave de IA es una credencial, y una credencial centralizada es una credencial más fácil de auditar.
Admin rediseñado con DataViews
El 7.0 empezó el primer rediseño del panel administrativo desde 2013. El sistema detrás de esto se llama DataViews, y es el cambio visual y estructural más significativo en el back office en más de una década. En la práctica ves tipografía más limpia, espaciado consistente, filtros inline que no recargan la página y una alineación visual entre el editor de bloques y las pantallas clásicas del admin.
Súmale a eso el Command Palette, accesible con ⌘K en Mac o Ctrl+K en Windows, desde cualquier lugar del admin. Te deja saltar a cualquier pantalla, entrada o comando registrado al instante — el mismo patrón que ya conoces de VS Code, Notion y Linear.
Aquí toca honestidad: el rediseño del admin es el cambio que más genera quejas de usuarios, porque rompe la memoria muscular. Quien administra contenido todos los días tardará unos días en reacostumbrarse. No es un problema técnico, es un costo de adaptación — y debes avisar al equipo de contenido antes de actualizar, no después. La buena noticia es que el cambio es de apariencia y navegación, no de concepto: donde las cosas estaban, siguen existiendo.
Registro de bloque solo en PHP
Esta es la novedad que más entusiasma a quien desarrolla. El 7.0 introdujo el registro de bloque solo en PHP: registras un bloque usando PHP como fuente de la verdad de los metadatos, sin necesidad de block.json, sin edit.js, sin Webpack, sin pipeline de build. Mantienes registro, metadatos, assets y renderizado juntos, en el mismo lugar.
La propia propuesta en Make WordPress Core es clara sobre el alcance: esto sirve para bloques que solo necesitan renderizado en el servidor y no son altamente interactivos. No reemplaza el paradigma client-side existente, ni pretende ser tan completo como él. Es para el bloque dinámico, PHP-first — ese que trae un dato, arma un HTML y lo devuelve.
Por qué esto cambia el costo de un proyecto
Para agencias y software houses, esta es la novedad con efecto más directo en el presupuesto. Muchos bloques personalizados que entregamos son exactamente esto: dinámicos, server-side, poco interactivos — una tarjeta de producto, un listado de entradas filtrado, un bloque de CTA que trae datos de otro lugar. Antes, incluso ese bloque simple arrastraba toda una toolchain de JavaScript consigo: Node, build, block.json, un edit.js que solo existía para que el editor no se rompiera.
Cortar esa toolchain para la clase de bloques que no la necesita significa menos superficie de mantenimiento, menos dependencias que actualizar, menos cosas que puedan salir mal en el deploy. Menos JavaScript en el proyecto también suele significar un sitio más liviano — lo que conversa directo con rendimiento y conversión. No es bala de plata: un bloque interactivo sigue exigiendo el camino client-side. Pero para el pan de cada día de los bloques server-side, es un alivio real de complejidad.
Gutenberg Fase 3: roadmap vs. release
Ahora la parte en la que más gente se confunde — y donde muchos artículos se equivocan feo. La edición colaborativa en tiempo real, al estilo Google Docs, es la función de vitrina de la Fase 3 de Gutenberg. Mucha gente esperaba verla en el 7.0. No entró.
La colaboración en tiempo real fue retirada del release unos doce días antes del lanzamiento y aplazada a una versión futura. Esto está documentado en la cobertura del release, incluso en el análisis de DreamHost sobre lo que entró y lo que se cortó. O sea: es roadmap, no es entrega. Si leíste en algún lugar que WordPress 7.0 “ahora tiene edición colaborativa igual que Google Docs”, ese contenido está equivocado — o fue escrito antes del corte y nunca se actualizó.
¿Por qué insistir en este punto? Porque las decisiones de negocio se toman con base en lo que existe, no en lo que se prometió. Si la colaboración en tiempo real es un requisito para tu operación editorial, no está disponible en el 7.0. Lo que sí entró en la línea de colaboración fueron funciones menores: Visual Revisions, notificaciones por correo en las Notes y un modo de Sugerencias. Útiles, pero lejos del commit simultáneo en tiempo real. Planifica por lo que está en el changelog, no por lo que estaba en el roadmap.
El fin de PHP 7.2 y 7.3: el cambio que puede romper tu sitio
Si solo vas a leer una sección de este texto, lee esta. El cambio más capaz de romper tu sitio en el 7.0 no es la IA ni el admin nuevo — es PHP. WordPress 7.0 eleva la versión mínima soportada a PHP 7.4 y descarta el soporte a PHP 7.2 y 7.3.
Muchos sitios todavía corren en hosting compartido con PHP antiguo, a veces sin que el dueño lo sepa. Si tu servidor está en 7.2 o 7.3, actualizar a WordPress 7.0 sin antes subir PHP es receta de pantalla en blanco. Y lo inverso también vale: subir PHP sin probar puede romper un plugin viejo que dependía de un comportamiento antiguo.
Checklist de actualización segura
- Averiguar la versión de PHP actual del servidor (Herramientas > Salud del sitio, o panel del hosting)
- Si está por debajo de 7.4, planificar la subida de PHP antes de tocar WordPress
- Levantar la lista de plugins y temas y revisar la compatibilidad declarada con el 7.0 y con PHP 7.4+
- Clonar el sitio a un entorno de staging idéntico al de producción
- Hacer un backup completo (archivos + base de datos) y probar que el backup restaura
- Actualizar en staging, recorrer las pantallas críticas, probar formularios y checkout
- Solo entonces actualizar producción, en horario de bajo tráfico, con un backup fresco
- Monitorear errores y rendimiento en las 48 h siguientes
Nada en esa lista es opcional. Es exactamente ese proceso lo que separa “actualicé y ni lo sentí” de “el sitio se cayó el lunes por la mañana”. Un gran salto de versión no es momento de improvisar.
¿Vale la pena actualizar? Un resumen honesto
Depende de dónde estés. Aquí va el resumen sin rodeos:
| Tu escenario | Recomendación |
|---|---|
| Sitio ya en PHP 7.4+, plugins mantenidos | Actualiza, con staging y backup. La ganancia de admin y el futuro de IA valen la pena |
| Sitio en PHP 7.2/7.3 | No actualices todavía. Sube PHP primero, prueba, después actualiza |
| Muchos plugins antiguos y sin mantenimiento | Audita antes. El 7.0 puede exponer un plugin que ya estaba pendiendo de un hilo |
| Necesitas colaboración en tiempo real | El 7.0 no lo resuelve. Es roadmap, no release |
| Quieres construir con la nueva IA del core | Vale la pena empezar a experimentar con la Abilities API en staging |
El 7.0 es una versión importante — quizá la más significativa en una década, tanto por la fundación de IA como por el rediseño del admin. Pero “importante” no es sinónimo de “actualiza hoy a las apuradas”. Es sinónimo de “planifícalo bien, porque esta no la quieres hacer con el susto encima”.
Dónde entra Pixelize
Gran parte del estrago en las actualizaciones de WordPress viene de un sitio sin mantenimiento continuo: PHP olvidado en una versión antigua, un plugin que nadie revisa, ausencia de staging. Cuando eso está al día, una versión como la 7.0 se vuelve un evento tranquilo — la agendas, la pruebas, la subes. Cuando no lo está, se vuelve crisis. Es la diferencia que hace el mantenimiento continuo.
Si tu WordPress es institucional y estás evaluando arquitectura, vale también entender dónde hace — y dónde no hace — sentido ir hacia un enfoque desacoplado; escribimos sobre eso en ¿vale la pena WordPress headless?. Y si quieres que la actualización al 7.0 se conduzca con staging, backup y revisión de plugins de verdad, es lo que hacemos en WordPress: sacar el susto de la ecuación.
Preguntas frecuentes
¿Cuándo se lanzó WordPress 7.0?
El 20 de mayo de 2026, con el nombre en clave “Armstrong”, en homenaje a Louis Armstrong. Es la primera versión que trae fundaciones de IA en el core y el primer rediseño del admin desde 2013, según los anuncios oficiales y la cobertura técnica de la prensa especializada.
¿WordPress 7.0 ya viene con IA que escribe mis textos?
No. El 7.0 trae la fundación — el AI Client agnóstico de proveedor, la Abilities API y una pantalla de Conectores para Anthropic, Google y OpenAI. Es infraestructura para que la usen plugins y agentes, no un asistente de escritura listo en el editor. El valor viene de quien construya sobre ella.
¿Necesito actualizar al 7.0 de inmediato?
No hay que correr, pero sí hay que planificar. El punto crítico es PHP: el 7.0 exige como mínimo PHP 7.4 y descarta 7.2 y 7.3. Antes de actualizar, revisa la versión de PHP en el servidor y la compatibilidad de los plugins en un entorno de prueba, nunca directo en producción.
¿La edición colaborativa en tiempo real entró en el 7.0?
No. La colaboración en tiempo real era la función más esperada y fue removida unos doce días antes del lanzamiento, aplazada a una versión futura. Está en el roadmap de la Fase 3 de Gutenberg, no es algo ya entregado en el 7.0. Cuidado con el contenido que afirma lo contrario.
¿Qué es el registro de bloque solo en PHP?
Es una forma nueva de registrar un bloque usando PHP como fuente de la verdad, sin necesidad de block.json, edit.js ni pipeline de build. Sirve para bloques dinámicos y con renderizado en el servidor, no para bloques altamente interactivos. Simplifica mucho la vida de quien hace plugins PHP-first.
¿Mi sitio se va a romper cuando actualice?
Si te saltas la etapa de prueba, puede romperse — sobre todo por PHP desactualizado o un plugin incompatible. Con un entorno de staging, un backup y una revisión de plugins, la actualización suele ser tranquila. El mantenimiento continuo existe justamente para que los grandes saltos de versión no se vuelvan crisis.