Ya sabemos el roadmap para WordPress 7.2, lo que se plantea que llegue en esta versión, y lo que no debería llegar.
Transcripción del programa
Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.
En este episodio encontrarás la información del 14 al 20 de septiembre de 2026.
WordPress 7.2 está previsto para principios de diciembre de 2026, y el equipo ya ha publicado el roadmap oficial del ciclo. Como en cada roadmap, el propio equipo avisa de que todo lo que aparece aquí está en desarrollo activo, pero nada garantiza que llegue tal cual a la versión final: es la hoja de ruta de intenciones, no una lista cerrada de compromisos.
La novedad que más titulares se ha llevado esta semana es el propio tema por defecto: se llama Ipsum, y con él WordPress rompe una tradición de más de una década de bautizar sus temas con el año de lanzamiento. A partir de ahora, cada tema por defecto tendrá su propio nombre y cambiará cuando el diseño lo pida, no cuando lo marque el calendario. La historia detrás es interesante: el equipo llevaba meses trabajando en un tema mucho más ambicioso y expresivo, con nombre en clave Mētis, pensado para lucir todo lo que Gutenberg ya permite hacer. Tras revisar la dirección con Matt, el criterio cambió: el tema que se empaqueta con WordPress debe ser el punto de partida más simple posible, dejando que el diseño más elaborado exista aparte. Mētis sigue viva como proyecto independiente, pero no se incluirá en esta versión.
Ipsum, cuyo nombre viene del clásico «lorem ipsum», el texto de relleno que ocupa la página hasta que llega el contenido real, es un lienzo en blanco pensado para blogs, con líneas discontinuas simulando el trazo de un lápiz de editor, un puñado de combinaciones tipográficas y variaciones de estilo que retiñen toda la página, imágenes incluidas. Todas las combinaciones cumplen WCAG AA. Ya está disponible para descargar y probar desde GitHub, con la ventana de feedback muy ajustada antes del lanzamiento de la 7.2.
Las Notas, el sistema de comentarios internos del editor, dan el salto más ambicioso hasta la fecha: llega el modo de sugerencias, donde en lugar de simplemente comentar sobre un bloque se puede proponer directamente un cambio de texto concreto para que otra persona lo acepte o lo rechace, un paso de gigante hacia una colaboración mucho más directa entre quienes editan un mismo contenido. Se suman también reacciones con emoji sobre las propias notas y un atajo dedicado en la barra de herramientas del bloque para añadir una nota sin salir del flujo de escritura.
El apartado de seguridad trae tres piezas de peso. La más llamativa conceptualmente es el llamado «modo sudo»: una función en fase muy inicial que plantea exigir una reautenticación puntual para acciones administrativas especialmente sensibles, aunque ya haya sesión iniciada, algo habitual en sistemas operativos pero nuevo en WordPress; de momento solo se ha anunciado la intención, con propuesta detallada pendiente de publicarse. La segunda es la Secrets API ya comentada en su propuesta inicial: sigue avanzando camino de la 7.2, con soporte desde el primer día para WP-CLI y la interfaz de administración pospuesta a una versión posterior. La tercera es una ronda de mejoras y endurecimiento para Application Passwords, con mejor detección de entornos locales frente a HTTPS, notificaciones por correo cuando se añade una nueva contraseña de aplicación, y una gestión más segura del rol por defecto que se les asigna. A esto se suma trabajo continuado de refuerzo sobre la API de procesamiento de HTML, para que WordPress interprete el marcado de forma más segura y fiable en todo el núcleo.
El mensaje del equipo sobre la IA es muy claro y, siendo justos, un poco frenazo: el ciclo de la 7.1 dejó constancia de que las funciones de IA necesitan demostrar primero adopción real y valor práctico antes de plantearse su entrada en el núcleo, así que todo el trabajo de este apartado se sigue haciendo en el plugin de IA, sin ninguna garantía de aterrizar en la 7.2. Entre lo que se está cocinando: más abilities de WordPress, incluyendo las primeras de escritura y no solo de lectura; una actualización del adaptador MCP a la especificación más reciente, con planes de publicarlo como plugin normal en el directorio; activación de MCP con configuración mínima directamente desde el propio plugin de IA; experimentación con WebMCP en flujos de trabajo de agentes dentro del propio navegador; un modelo de identidad y delegación para que los agentes tengan una identidad auditable y permisos gestionables de forma independiente a las cuentas humanas; contexto de sitio y directrices editoriales reutilizables entre distintas funciones de IA; soporte de embeddings compartido para búsqueda semántica; y streaming de respuestas de IA en el cliente PHP.
El roadmap destaca cuatro frentes concretos de alto esfuerzo sobre accesibilidad: que los avisos del escritorio de administración se anuncien correctamente a tecnología de asistencia y sean más fáciles de descartar por teclado; introducir tests automatizados con axe-core para prevenir regresiones; permitir desactivar por completo el reordenamiento de metaboxes, que llevaba tiempo dando problemas de complejidad visual y cambios accidentales en móvil; y eliminar el modo de accesibilidad de widgets, para reducir el número de modos de gestión distintos que hay que mantener.
Llega un nuevo bloque de Lista de Descripción, formado por tres bloques estáticos que serializan a las etiquetas HTML <dl>, <dt> y <dd>, siguiendo el mismo patrón de bloque padre e hijos que ya usan Tabs o el bloque de Lista, pensado para glosarios, especificaciones técnicas y cualquier relación de término y definición. El bloque de Icono completa su búsqueda por palabra clave, de forma que buscar «hamburguesa» o «navegación» encuentre también el icono de menú. El bloque de Tabla de Contenidos, que llevaba mucho tiempo en fase experimental, pasa a renderizado dinámico en el servidor para hacerse por fin estable, con editor y frontend compartiendo una sola fuente de verdad sobre los encabezados del contenido. La Interactivity API gana una directiva data-wp-html para renderizar marcado desde el store dentro de una región interactiva, además de una forma más clara de que los bloques observen la navegación del lado del cliente. Y la actualización a React 19 sigue en marcha, aunque con pocas probabilidades de llegar a tiempo a la 7.2.
Uno de los cambios de fondo más importantes del ciclo: el Editor del Sitio extensible avanza hacia una base nueva, construida sobre el paquete de enrutado wordpress/boot, ya cerca de tener paridad de funciones con el editor actual. Lo relevante no es solo el rediseño técnico, sino que por primera vez se abre a terceros: un endpoint de configuración de vistas en el servidor permitirá que autores de plugins registren sus propias pantallas y ajustes dentro del propio Editor del Sitio, en lugar de tener que construirse su propia API desde cero cada vez. Otros proyectos en marcha, como la edición de navegación, ya se están apoyando en esta base en lugar de duplicar trabajo.
El sistema de DataViews y DataForms sigue puliendo su extensibilidad, con configuración de vistas y formularios registrada en el servidor y campos y acciones también registrables ahí; como parte de esto, el propio inspector de la publicación, es decir, la imagen destacada, extracto, estado, fecha, autor o plantilla, se está migrando a un DataForm, y ya se pide ayuda para probar esa pieza en concreto. La omnibar, que llegó en la 7.1, sigue iterando con la sustitución de dashicons por iconos SVG, mejoras al command palette y revisión continuada de accesibilidad. Y hay una nueva tanda de mejoras a los mensajes de error: más claros, más diagnosticables, y con un botón de copiar para poder buscarlos o compartirlos fácilmente, siguiendo los principios de diseño defensivo que planteó Matt hace unas semanas. Se retoma también el widget «Un día como hoy», que ya se había intentado meter en la 7.1 sin éxito.
Por fin se podrá estilar de forma consistente elementos de formulario, como botones, campos de texto, desplegables y la etiqueta que faltaba, directamente desde Estilos Globales, sin tocar theme.json a mano. El estilado responsivo que llegó en la 7.1 se amplía a más controles, con una API pública para que bloques de terceros con controles personalizados también puedan aprovecharlo. Se puede definir un estado personalizado «activo» para bloques interactivos, como el elemento de menú actual en una navegación, empezando por el bloque de Enlace de Navegación y el bloque Tabs. Y retorna, esta vez con más peso, el proyecto de mostrar los estilos heredados de Estilos Globales directamente en el inspector del bloque, la función que se aparcó en la 7.1 tras varios intentos fallidos de diseño; ahora se suma la incógnita de si mostrar de forma visible cuándo un valor global ha sido sobrescrito localmente y cómo ofrecer una forma clara de revertir ese cambio.
El procesamiento de medios en el cliente, que debutó en la 7.1, se centra ahora en madurar el sistema: reforzar el proceso de subida, ampliar formatos soportados y cerrar trabajo de rendimiento pendiente. El insertor de medios se rediseña pensando en bibliotecas de medios muy grandes, con más fuentes para la galería dinámica y opciones de ordenación para la galería estática. El modal de edición de medios de la 7.1 se centra en el seguimiento de la relación entre una imagen original y sus recortes, resolviendo un problema real: cada recorte crea hoy un adjunto independiente sin ningún vínculo registrado con el original, lo que puede acabar llenando la biblioteca de medios de duplicados sueltos. En rendimiento, el foco está en eliminar la concatenación de scripts y estilos a favor de precarga, y en imágenes responsivas mejoradas, con el plugin Enhanced Responsive Images del equipo de Performance disponible para quien quiera ayudar a probar. Y las revisiones visuales, que llegaron en la 7.0, siguen puliéndose para que comparar y restaurar cambios resulte más fluido.
Una ausencia deliberada y con razón: la edición colaborativa en tiempo real no está en el roadmap de la 7.2, aunque el trabajo sigue en paralelo al ciclo de la versión. El equipo reconoce que aún faltan decisiones arquitectónicas importantes por resolver, y en lugar de listarla aquí para tener que retirarla después, como pasó en ciclos anteriores, prefieren dejarla fuera del todo por ahora.
Mientras esperamos la llegada de la 7.2, ya está aquí WordPress 7.1.1, la primera versión de mantenimiento de la 7.1. Trae 17 correcciones en core, 19 en el editor de bloques, y once fallos de seguridad, así que es actualización recomendada de forma inmediata: el propio anuncio insiste en ello, como toca en cualquier versión de seguridad.
Entre los fallos corregidos destacan un XSS almacenado en wpautop() explotable por un visitante sin cuenta, con el comentario pendiente de aprobación; un problema en la HTML API que permitía escapar de un comentario HTML mediante secuencias de cierre abrupto; un XSS almacenado en temas con soporte de cabeceras personalizadas; URLs especialmente manipuladas que permitían instalar y previsualizar automáticamente un tema inactivo desde WordPress.org; y una travesía de rutas autenticada en el controlador REST de plantillas, reportada de nuevo por Anthropic.
La lista sigue con más fallos de peso: un administrador de sitio podía activar en red un plugin pensado solo para red que estuviera instalado sin estarlo; XML-RPC permitía publicar cambios de personalización saltándose la comprobación de permiso para editar CSS; una sobrescritura arbitraria de posts por parte de un Contributor, también reportada por Anthropic; una comprobación de permisos ausente que filtraba el título de un post padre privado a través de los metadatos del adjunto; una divulgación del slug de un post en borrador o pendiente por parte de un Contributor sin la autorización adecuada; y un fallo que permitía a cualquier usuario autenticado reasignar el padre de un comentario, notas incluidas. Como viene siendo costumbre, los parches se están retroportando a todas las ramas con soporte, desde la 4.7 hasta la 7.0.
Ya está disponible Gutenberg 24.0. La novedad más práctica es que las revisiones visuales por fin incluyen el título del artículo, que hasta ahora quedaba fuera: ver los cambios de título junto a los del cuerpo del texto evita tener que adivinar cuándo se renombró algo. La Galería estrena una variación de cuadrícula totalmente personalizable que sustituye al layout flexible no editable de siempre, y tanto el número de columnas como el recorte de imágenes se pueden configurar de forma distinta según el dispositivo, así que una galería puede mostrar cuatro columnas en escritorio y dos en tableta sin tocar una línea de CSS.
El Título del Sitio gana la opción «fit-text», que hace que el texto escale para ocupar todo el ancho disponible en lugar de quedarse fijo en un tamaño de punto y tener que saltar de línea o quedarse corto. Entre el resto de novedades destaca un rediseño de casi cien iconos hacia un lenguaje visual unificado basado en trazos, la posibilidad de indentar y desindentar con Tab un elemento de lista completo o varios seleccionados a la vez, imágenes de fondo que ya aceptan directamente una URL sin tener que pasar por la Biblioteca de medios, y que los espacios de no separación se vuelvan visibles mientras se edita, en lugar de quedar invisibles y cambiar el salto de línea sin que nadie se entere.
El equipo de Core que trabaja en la edición colaborativa en tiempo real ha explicado por qué la función sigue fuera del roadmap. El diseño actual mezcla los cambios solo en el navegador, sin que el servidor intervenga hasta que alguien guarda, y eso deja tres huecos serios: no sabe quién escribió cada cambio dentro de una sesión, lo que permitiría colar HTML no autorizado bajo los permisos de otra persona; no puede participar cuando la actualización llega por la API REST o WP-CLI; y no puede mediar si dos personas se dessincronizan, con riesgo real de perder trabajo.
La solución propuesta es que la colaboración pase a ser «consciente del servidor»: en lugar de intercambiar cambios directamente entre sí, cada persona se los envía a WordPress, que comprueba permisos, fusiona los cambios de todos y resuelve los conflictos, en vez de dejarlo todo en manos del navegador. El coste es más carga en el servidor, así que habrá que cuidar el rendimiento, sobre todo en hostings más modestos.
Hay tres motores de sincronización en fase de prueba, disponibles como plugin para quien quiera probar y dar feedback: uno basado en la biblioteca Yjs, otro con fusión a tres bandas que sincroniza solo al guardar, y un tercero que registra descripciones breves de cada cambio en lugar del contenido completo.
Ya está disponible en Learn WordPress el curso «AI-Powered WordPress», pensado para explicar de forma progresiva todo lo que ha ido llegando con el plugin canónico de IA desde la 7.0. Se estructura en cuatro módulos: los tres primeros van dirigidos a cualquiera que gestione o publique en un sitio WordPress, como propietarios, redactores, editores o administradores, sin necesidad de saber programar, y cubren desde conectar el primer proveedor de IA desde la pantalla de Connectors, hasta usar las herramientas editoriales para redactar, resumir y clasificar contenido, generar texto alternativo accesible de forma automática, moderar comentarios con análisis de sentimiento y toxicidad, y controlar qué está haciendo la IA en el sitio con el registro de peticiones y las aprobaciones de conectores.
El cuarto módulo da un salto hacia el desarrollo, sin asumir experiencia previa en PHP aunque ayuda haber tocado antes archivos de tema o plugin: cubre cómo conectar asistentes como Claude o ChatGPT a un sitio mediante el adaptador MCP, cómo registrar una Ability de WordPress para que las herramientas de IA descubran las funciones de un plugin propio, y cómo usar el WordPress AI Client para lanzar prompts desde plugins y temas propios. El curso completo se estima en unas nueve horas, requiere un sitio con WordPress 7.0 o superior y acceso de administrador, y cierra con un bloque sobre buenas prácticas responsables a la hora de publicar y construir con IA dentro de WordPress.
Anécdota curiosa: bbPress ya va por la 2.6.17, saltándose la 2.6.16, porque el propio John James Jacoby encontró un fallo de SQL justo después de etiquetar esa versión y prefirió sacar el arreglo sin esperar. Es otra actualización de seguridad y mantenimiento. Refuerza la visibilidad heredada de foros privados y ocultos, los límites de los foros de grupo de BuddyPress, las comprobaciones de acceso para suscriptores, la edición de perfil, las peticiones a la API REST y XML-RPC, los resultados de búsqueda, las redirecciones canónicas, las etiquetas de tema, mover respuestas, dividir temas, y el escapado de salida en general.
La otra pieza importante es una revisión a fondo de las herramientas de mantenimiento y reparación de contadores, como temas, respuestas, foros, subforos, participación, voces y contribuciones de usuario, que ahora se comportan mejor durante moderación, movimientos, fusiones, divisiones, borrado, restauración, reasignación y peticiones simultáneas. Además, los temas de bloques reciben ya soporte de primera clase mientras bbPress sigue usando sus propias plantillas PHP.
Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.
Un abrazo, y hasta el próximo programa.




Deja una respuesta