Finales de octubre
Empezar las pruebas en un entorno aislado desde la primera beta y seguir las primeras notas técnicas.
Procesando…
Evolución del CMS
WordPress 7.2 debería cerrar el ciclo de las versiones principales del CMS en 2026. Su hoja de ruta combina evoluciones editoriales, nuevas API, seguridad y la llegada del tema Ipsum, pero varios elementos aún deben confirmarse.
A 24 de septiembre de 2026, WordPress 7.2 sigue en desarrollo. La primera beta se espera entre el 20 y el 22 de octubre, antes de una versión final actualmente prevista entre el 8 y el 10 de diciembre.
La hoja de ruta publicada el 18 de septiembre anuncia el tema Ipsum, cambios en el editor, nuevas API y varios trabajos de seguridad. Sin embargo, su presencia en la versión final no está garantizada: el objetivo inmediato consiste en identificar las dependencias del sitio y organizar las pruebas en preproducción.
WordPress 7.2 debería ser la última versión principal del CMS publicada en 2026. Su calendario prevé cuatro betas, tres Release Candidates y después una versión final en diciembre. Estas fechas pueden evolucionar en función de las pruebas y de las decisiones del equipo responsable de la versión.
| Etapa | Fecha prevista |
|---|---|
| Beta 1 | Del 20 al 22 de octubre de 2026 |
| Beta 2 | Del 27 al 29 de octubre de 2026 |
| Beta 3 | Del 3 al 5 de noviembre de 2026 |
| Beta 4 | Del 10 al 12 de noviembre de 2026 |
| Release Candidate 1 | Del 17 al 19 de noviembre de 2026 |
| Release Candidate 2 | Del 24 al 26 de noviembre de 2026 |
| Release Candidate 3 | Del 1 al 3 de diciembre de 2026 |
| Versión final | Del 8 al 10 de diciembre de 2026 |
La Beta 1 marcará un paso importante: a partir de entonces, los esfuerzos deberán centrarse principalmente en las pruebas y la corrección de errores, más que en añadir funcionalidades. También empezarán a publicarse las primeras Dev Notes destinadas a los desarrolladores.
Empezar las pruebas en un entorno aislado desde la primera beta y seguir las primeras notas técnicas.
Comprobar las extensiones, los temas, los flujos editoriales y las integraciones a lo largo de las betas y las RC.
Validar los componentes críticos con una Release Candidate cercana a la versión prevista para producción.
Desplegar solo después de realizar una copia de seguridad, validar en preproducción y preparar una reversión.
Uno de los cambios más visibles debería ser la llegada de Ipsum, el tema propuesto para acompañar a WordPress 7.2. Concebido como un lienzo en blanco orientado al blogging, debe funcionar de inmediato y seguir siendo ampliamente personalizable en el Site Editor.
Esta elección rompe con la convención anual seguida por Twenty Twenty-Two, Twenty Twenty-Three, Twenty Twenty-Four y Twenty Twenty-Five. En adelante, los futuros temas predeterminados podrían recibir su propio nombre y evolucionar cuando un nuevo diseño lo justifique, en lugar de hacerlo únicamente al ritmo del calendario.
Ipsum apuesta por una presentación minimalista, varias variaciones de estilo y plantillas destinadas a transformarse desde el editor del sitio.
La presentación inicial indica que las combinaciones propuestas aspiran a cumplir WCAG AA. No obstante, la revisión técnica debe continuar antes del lanzamiento.
El aspecto y el funcionamiento actuales de Ipsum no deben considerarse definitivos. Los temas de bloques y el Full Site Editing sitúan ahora el tema predeterminado en el papel de base de diseño adaptable, más que en el de un diseño fijo.
WordPress precisa que las funcionalidades anunciadas están en desarrollo activo, sin garantizar que todas se integren en la versión final. Por tanto, cualquier decisión técnica debe reevaluarse a partir de las betas, las Dev Notes y las Release Candidates.
Las Notes, que permiten comentar directamente los bloques, deben seguir evolucionando. La hoja de ruta menciona propuestas de modificación que pueden aceptarse o rechazarse, reacciones mediante emoji y un acceso más directo desde la barra de herramientas de los bloques.
Para un equipo editorial, estos mecanismos pueden vincular las observaciones al contenido correspondiente y reducir ciertos intercambios que se realizan fuera del CMS. Sin embargo, no deben confundirse con la coedición simultánea.
La edición colaborativa en tiempo real no está prevista deliberadamente en la hoja de ruta de WordPress 7.2. Algunas decisiones arquitectónicas aún deben abordarse paralelamente al desarrollo de esta versión.
WordPress trabaja en reconstruir el panel de ajustes de las entradas y las páginas en torno a DataForm. La imagen destacada, el extracto, el estado, la fecha, el autor, la plantilla y las opciones añadidas por las extensiones deben representarse progresivamente con esta base común.
El objetivo es obtener una interfaz más coherente, especialmente entre el inspector y la edición rápida del Site Editor. Para los desarrolladores de plugins, esta evolución también puede revelar integraciones frágiles.
Una extensión basada en una API pública suele resistir mejor las evoluciones de la administración que una extensión que apunta directamente al DOM o a las clases CSS internas.
WordPress lanzó el 17 de septiembre un llamamiento específico a los desarrolladores. La mayoría de las principales API de extensión deberían seguir funcionando, pero la ubicación anterior PluginPostExcerpt está obsoleta y actualmente no se está trasladando al nuevo inspector. La migración recomendada pasa por PluginDocumentSettingPanel.
A 23 de septiembre, los filtros relacionados con el selector de medios y la imagen destacada también se habían integrado en la rama de desarrollo, con una llegada anunciada en Gutenberg 24.1. Las extensiones SEO, editoriales y de gestión de contenidos son especialmente relevantes.
El trabajo no se limita a la presentación de la administración. Se prevé una Fields API para WordPress 7.2, de modo que las extensiones puedan registrar sus campos y mostrarlos en distintas interfaces sin reconstruir cada pantalla por separado.
El Site Editor también debe ser extensible. WordPress prepara una base que permita a los plugins registrar sus propias pantallas y ajustes mediante una configuración del lado del servidor. Así, las extensiones relacionadas con SEO, contenidos estructurados, diseño o ajustes globales podrían integrarse mejor en las interfaces nativas.
El objetivo es reducir el código específico necesario y mejorar la coherencia entre las distintas interfaces de administración.
Las extensiones complejas podrían integrarse de forma más natural en el editor del sitio en lugar de construir sistemáticamente su propia página.
Habrá que esperar a la beta y a las Dev Notes para conocer las API que se hayan estabilizado realmente. Los desarrollos que utilicen funciones internas o dependan de la estructura HTML actual deberán examinarse con atención.
WordPress 7.2 debe ampliar las posibilidades adaptables introducidas en WordPress 7.1. La hoja de ruta prevé ampliar los controles disponibles según los estados adaptables y ofrecer una API pública para que los bloques de terceros puedan utilizar los mismos mecanismos.
La visualización de los estilos heredados también debería ser más clara. Cuando un color se define globalmente para los párrafos, el editor debería mostrar mejor ese valor y distinguirlo de un ajuste aplicado a un único bloque.
La interfaz debe facilitar la personalización de botones, campos de texto, listas de selección, etiquetas y algunos estados interactivos. Parte de la compatibilidad ya existe en theme.json, pero el objetivo es hacer accesibles estas posibilidades sin modificar directamente ese archivo ni añadir CSS.
El bloque Tabla de contenidos, experimental durante mucho tiempo, debe estabilizarse con un renderizado dinámico del lado del servidor para mantener la coherencia entre el editor y el sitio público. Un nuevo bloque Description List debe generar los elementos semánticos dl, dt y dd, adecuados especialmente para glosarios, definiciones y fichas técnicas.
WordPress continúa trabajando en el procesamiento de imágenes en el navegador, la ampliación de los formatos compatibles y la mejora del rendimiento. El selector de medios debe facilitar la navegación por grandes bibliotecas multimedia, mientras que las galerías deberían incorporar nuevas posibilidades de ordenación.
El editor de medios también debe seguir mejor las relaciones entre una imagen original y sus variantes recortadas. Estas evoluciones serán especialmente relevantes en sitios editoriales con muchos recursos.
La hoja de ruta menciona sustituir la concatenación de algunos scripts y hojas de estilo por mecanismos de prefetch, así como mejoras relacionadas con las imágenes adaptables. Sin embargo, no puede deducirse una mejora universal de estos trabajos.
Los resultados seguirán dependiendo del tema, las extensiones, el alojamiento, la caché, las imágenes, la base de datos, los scripts de terceros y la configuración del servidor. Las comparaciones deberán realizarse después de la estabilización y en condiciones reproducibles.
Se propone una Secrets API para proporcionar un mecanismo común de almacenamiento de claves de API y otra información sensible, con compatibilidad para WP-CLI. Su interfaz gráfica completa estaría prevista para una versión posterior.
WordPress también está explorando un «sudo mode», es decir, una nueva autenticación antes de determinadas acciones administrativas sensibles. Este trabajo se encuentra todavía en sus primeras fases y no debe anunciarse como confirmado para diciembre.
La propuesta pretende evitar que cada extensión desarrolle por separado su propio mecanismo para conservar identificadores externos o claves de API.
El principio del «sudo mode» consiste en solicitar una confirmación adicional antes de determinadas operaciones especialmente sensibles.
Las líneas de trabajo incluyen una mejor detección de entornos HTTPS o locales, notificaciones al añadir una contraseña de aplicación, protecciones adicionales según determinados roles y trabajo sobre el atributo SameSite de las cookies.
La presencia de una sección dedicada a la inteligencia artificial en la hoja de ruta no significa que se vaya a integrar un asistente generativo en WordPress 7.2. Antes de una posible integración en el Core, las funcionalidades deben demostrar su adopción y utilidad en el plugin AI.
Los experimentos mencionados se refieren especialmente a las «abilities», el adaptador MCP, WebMCP, los permisos de los agentes, los embeddings, la búsqueda semántica y el streaming. Estos trabajos no están garantizados en WordPress 7.2.
Una versión principal debe evaluarse en una copia representativa del sitio. Los procesos de negocio, los roles, las extensiones críticas y las integraciones externas importan más que una simple comprobación visual de la página de inicio.
Las extensiones SEO, de flujos de trabajo, publicación, gestión de campos o Custom Post Types deberán comprobarse con DataForm. WordPress ya propone un protocolo de pruebas con Gutenberg 24.0 o una versión de desarrollo más reciente.
theme.jsonGlobal Styles, los estados adaptables y los ajustes locales pueden interactuar con las personalizaciones existentes. Las pruebas deben cubrir las páginas principales y los componentes reutilizados, no solo una plantilla.
Un proceso correcto con una cuenta de administrador no garantiza que funcione para un editor, un autor, un rol personalizado o una integración externa. En los sitios con muchas imágenes, también habrá que comparar el peso de las páginas, los Core Web Vitals, las variantes generadas, la carga diferida, el tiempo de carga de la administración y la navegación por la biblioteca multimedia.
La preparación puede comenzar antes de la primera beta con un inventario de la versión de WordPress y PHP, el tema activo y su posible tema hijo, las extensiones, el código personalizado, las integraciones externas, las tareas CRON, la caché y las copias de seguridad disponibles.
También es el momento de retirar las extensiones que no se utilizan y comprobar que los componentes indispensables sigan manteniéndose.
Documentar las dependencias, comprobar las copias de seguridad y sanear la instalación existente.
Instalar WordPress 7.2 únicamente en desarrollo o preproducción, seguir las Dev Notes y analizar los errores de PHP y JavaScript.
Repetir los escenarios críticos y comprobar que los editores de las extensiones y temas indispensables anuncien su compatibilidad.
Prever una copia de seguridad verificada, un plan de reversión y una ventana de control después del despliegue.
No es necesario suspender la creación o el rediseño de un sitio hasta diciembre. Si se prevé ponerlo en producción en torno a ese periodo, sí resulta pertinente integrar WordPress 7.2 en el calendario de validación.
Elegir extensiones mantenidas, utilizar las API públicas, contar con un tema correctamente desarrollado, disponer de una preproducción fiel y aplicar un procedimiento de actualización reproducible siguen siendo las mejores protecciones frente a las futuras evoluciones del CMS.
WordPress 7.2 se presenta más como una etapa de maduración del editor y de sus bases técnicas que como una versión articulada en torno a una única funcionalidad espectacular. Ipsum será probablemente su novedad más visible, pero DataForm, las API destinadas a los plugins, la extensibilidad del Site Editor y los trabajos de seguridad pueden tener más efectos en los proyectos profesionales.
La estrategia más prudente consiste en seguir la estabilización de la versión, leer las Dev Notes y preparar pruebas representativas. La hoja de ruta no debe tratarse como la lista definitiva de lo que se entregará en diciembre.
Desarrollo web
Migración de PHP, actualización de un CMS o cambio de framework: identifique los problemas de compatibilidad y pruebe los recorridos esenciales antes de publicar.
Introduce al menos 2 caracteres para iniciar la búsqueda.