La hoja de ruta de WordPress 7.1

#Introducción

El 19 de junio de 2026, Anne McCarthy, de Automattic, publicó la hoja de ruta de WordPress 7.1 en el blog Make WordPress Core, su primer ciclo como líder de lanzamiento. Su mensaje en LinkedIn fue, como es habitual en ella, muy cercano: “I am so excited about what’s taking shape.” (Estoy muy entusiasmada con lo que está tomando forma.) La hoja de ruta está realmente repleta, y la palabra protagonista es colaboración, planteada como el hilo conductor que mantiene unido el lanzamiento.

Hay una tensión que conviene nombrar desde el principio. El lanzamiento se vendió con la colaboración como reclamo, pero la función de colaboración estrella, la colaboración en tiempo real, es precisamente lo que se sigue aplazando. Fue retirada de WordPress 7.0 unas dos semanas antes de aquel lanzamiento. Regresó en la hoja de ruta de 7.1 envuelta en “big, open strategy questions” (grandes preguntas estratégicas abiertas) en lugar de una fecha de lanzamiento. Y en la WordCamp Europe 2026, los core committers cuestionaron abiertamente si la función completa pertenece siquiera al núcleo. Así que la lectura honesta de 7.1 son dos lanzamientos en uno: un conjunto sólido de mejoras de estilización, media y plataforma que salió de verdad el 19 de agosto, y una historia de colaboración sobre la que aún se discute en abierto.

Actualización, 20 de agosto de 2026: WordPress 7.1 Mary Lou salió el 19 de agosto, en la fecha. La actualización de React 18 a React 19, el correo en Unicode, Guidelines / wp_knowledge, la colaboración en tiempo real y la retirada del bloque Classic salieron todos del lanzamiento. Lo que aterrizó es la estilización responsiva, los media del lado del cliente, una barra de administración persistente, el editor de entradas siempre en iframe, Playlist y Tabs, y un Notes más rico. La nota del 28 de julio sobre la Beta 3 sigue valiendo para los dos elementos que cayeron primero.

#En resumen

• Anne McCarthy lideró 7.1 por primera vez. WordPress 7.1 Mary Lou salió el 19 de agosto de 2026, el día de cierre de la WordCamp US en Phoenix.
• El lanzamiento estaba estructurado en torno a la colaboración, pero la colaboración en tiempo real (RTC) se aplazó otra vez después de haber sido recortada de 7.0.
• Lo que aterrizó de verdad: estilización responsiva, media del lado del cliente, barra de administración persistente, editor de entradas siempre en iframe, Playlist y Tabs. Guidelines y la descontinuación del bloque Classic no salieron. React 19 se fue más allá de 7.1.
• El soporte para direcciones de correo en Unicode fue retirado del lanzamiento por decisión de Matt Mullenweg, por motivos de seguridad, seis semanas después de integrarse en el núcleo.
• Los core committers plantearon un modelo de canary deployment al estilo de Chrome, una señal de que creen que el propio proceso de pruebas y feedback necesita replantearse.
• La ventana corta de estabilización hizo lo de siempre: la lista de junio era intención. El zip del 19 de agosto es la entrega.

#Qué salió realmente, ordenado por a quién afecta

La hoja de ruta enumera mucho. Para un propietario de sitio o una agencia, la pregunta útil no es “qué hay en la lista”, sino “qué cambia mi trabajo”. Esta es la división.

El patrón es claro. Lo que aterrizó es infraestructural o está orientado a los constructores. La historia de la colaboración, aquella que da nombre al lanzamiento, se quedó en la franja media a baja y fuera del zip.

Quien cerró la parte media de esa tabla fue Gutenberg 23.6, la última versión de funciones antes de 7.1. Pasa los bloques Playlist y Tabs de experimentales a estables, añade notas en línea sobre la selección de texto con autocompletado de @menciones, una variación Dynamic Gallery que muestra todos los medios adjuntos a una entrada, una API de registro de iconos para plugins y temas, y anchos de viewport configurables en theme.json, es decir, la estilización responsiva deja de estar clavada a tres breakpoints elegidos por otra persona.

#Estilización responsiva: el titular silencioso

Si construyes sitios para clientes, lo más útil de 7.1 no es la colaboración, es la estilización responsiva. Hasta ahora, controlar cómo se ve un bloque en distintos tamaños de pantalla suponía CSS personalizado, un plugin, o pelearse con el editor. 7.1 lleva la estilización de bloques por breakpoint al propio editor, junto con la estilización de estados interactivos para hover, foco y activo. Los autores de temas fijan sus propios breakpoints en theme.json. La Beta 4 añadió una opción de exclusión tras quejas de UX, así que esto no se impone en todos los sitios.

Esto es poco glamuroso e importa más que la mayoría de los elementos más llamativos. El control responsivo es un punto de fricción diario en el trabajo real con clientes, y trasladarlo al núcleo reduce el número de plugins y el CSS personalizado que, de otro modo, todo sitio acumula. Es ese tipo de madurez de plataforma que no genera titulares pero elimina en silencio toda una categoría de consultas de soporte.

#React 19 se aplaza, el bloque Classic se queda: por dentro

Dos elementos de la hoja de ruta son invisibles para los usuarios finales e importantes para los desarrolladores. Uno de ellos ha salido del lanzamiento. La actualización del editor de React 18 a React 19 no entra en 7.1: los problemas de compatibilidad con plugins resultaron más tercos de lo esperado, y el colaborador patrocinado por Automattic Jarda Snajdr dijo que la actualización necesita “un periodo de pruebas considerable” antes de poder salir.

Es la decisión correcta y a la vez incómoda. React 19 era uno de los pocos elementos de esta hoja de ruta con confianza alta y, al mismo tiempo, el que con más facilidad podía romper código de terceros. Aplazarlo convierte 7.1 en un lanzamiento más pequeño de lo que anunciaba la hoja de ruta y empuja el trabajo de compatibilidad a un ciclo posterior. Para los desarrolladores el efecto práctico es un aplazamiento, no una cancelación: la actualización sigue en camino, así que probar bloques personalizados e interfaces de editor con React 19 en el plugin Gutenberg sigue mereciendo la pena, solo que sin una fecha límite de agosto encima.

El bloque Classic es el caso más interesante, porque el plan cambió a mitad de ciclo. La idea original era ocultarlo del insertador de bloques en 7.1 y retirarlo gradualmente, porque arrastra TinyMCE, un editor pesado. La reacción de la comunidad fue inmediata: algunos, como Seth Rubenstein (Pew Research Center), lo zanjaron con un escueto “bien”, mientras que blogueros veteranos como Jeff Chandler veían venir la disrupción: “Santo cielo. No vi venir esto. Sé lo que esto va a hacer”.

Actualización: ese plan de ocultarlo del insertador se revirtió. El bloque Classic sigue apareciendo en el insertador en 7.1 exactamente como en 7.0, y el director de ingeniería de Automattic Marin Atanasov señaló que el enfoque original “tenía las cosas en buena medida al revés” y que forzar a los usuarios a abandonarlo sin una alternativa mejor empeora la experiencia sin ningún beneficio directo. El ángulo de rendimiento sigue en pie, porque cargar TinyMCE de forma diferida en páginas que nunca lo usan es una ganancia real para tiendas WooCommerce donde se mide cada kilobyte de peso del editor, pero el reloj de migración que algunos ya habían puesto en marcha nunca arrancó. Si mantienes contenido en bloque Classic, nada te obliga a moverte en 7.1.

Actualización: el soporte para direcciones de correo en Unicode también está fuera de 7.1. Se había integrado en el núcleo seis semanas antes, tras once años de desarrollo, y Matt Mullenweg decidió retirarlo por motivos de seguridad. Once años hasta la integración y seis semanas hasta la marcha atrás es un resultado duro para los colaboradores implicados, y conviene leerlo junto al debate del canary de más abajo: un cambio que supera la revisión, se integra y luego se retira tarde por una valoración de seguridad es exactamente el fallo del bucle de feedback que los committers intentan nombrar. Si contabas con direcciones de correo fuera de ASCII en 7.1, planifica con el comportamiento actual.

Dos cambios de cara a los desarrolladores llegaron como propuestas de merge después de la hoja de ruta y conviene seguirlos. El theming del sistema de diseño introduce una hoja de estilos wp-theme registrada en el núcleo más un ThemeProvider de React, la base del tan prometido rediseño del panel de administración, con los esquemas de color del usuario aplicados en el editor del sitio como primer resultado visible. Y la Abilities API sumó tres abilities de solo lectura propuestas (core/read-settings, core/read-content, core/read-users) que permiten a agentes y herramientas de IA leer datos básicos del sitio tras comprobaciones de permisos, aunque un mantenedor de Abilities ya ha objetado que no están listas para el núcleo. Ambos son el tipo de fontanería que decide si la historia de la IA y del panel sale limpia o se desliza a 7.2.

#Guidelines e IA: la apuesta por el flujo de trabajo

Lo destacado es Guidelines, una función que permite a un sitio definir reglas editoriales y voz de marca en un solo lugar, que luego alimenta las herramientas de IA del editor para que el contenido generado siga esas reglas. También hay una iteración del AI Client que añade streaming de generación y embeddings, y una iteración de los Connectors que lleva la autenticación más allá de las simples claves de API.

Esta función dio un paso concreto cuando el core committer patrocinado por Automattic, Greg Ziółkowski, publicó una propuesta formal de merge para integrar el nuevo custom post type wp_knowledge y las AI Guidelines en el núcleo. La acogida, sin embargo, ha estado muy dividida:

• George Stephanis (Bethink Studios) dio la bienvenida a la función, señalando que resuelve los desafíos de las directrices editoriales que los plugins han pasado años sorteando.
• Aaron Jorbin (core committer independiente) señaló que establece una buena base pero sigue estando incompleta en su estado actual.
• Jon Brown (9seeds) fue más directo, sugiriendo que “debería desarrollarse como un plugin del núcleo durante uno o dos años, y tal vez nunca integrarse en el núcleo”.
• Search Engine Journal se hizo eco del descontento de los desarrolladores, informando de que muchos consideran que la función está desconectada de las necesidades reales de los usuarios.

Es el enfoque correcto para la IA en un CMS. El riesgo de la asistencia de escritura por IA es un resultado uniforme y ajeno a la marca, exactamente el problema de contenido genérico contra el que lucha ahora todo equipo editorial. Una capa Guidelines que limita la generación a los estándares de un sitio es una protección frente a eso. No salió. Matt Mullenweg vetó la integración en julio, diciendo que las funciones de IA necesitan adopción real con un crecimiento semana a semana impresionante antes de aterrizar en el núcleo. El experimento se queda en Gutenberg y en Automattic. Trátalo como propuesta, no como capacidad de 7.1. Cubrimos el debate del merge en WordPress 7.1: directrices de IA y el nuevo tipo de contenido wp_knowledge.

#La saga de la RTC, y por qué sigue atascándose

La colaboración en tiempo real es la función que WordPress está siempre a punto de lanzar. Fue recortada de 7.0 dos semanas antes. En la hoja de ruta de 7.1, McCarthy la planteó con honestidad, con “big, open strategy questions” (grandes preguntas estratégicas abiertas) aún pendientes: qué lanzar realmente y qué mecanismo de almacenamiento usar. Abordamos los detalles de este segundo intento en nuestro artículo sobre colaboración en tiempo real en WordPress 7.1, y la hoja de ruta no resolvió tanto las preguntas allí planteadas como volvió a enunciarlas.

El desarrollo más revelador vino de los core committers. En su encuentro en la WordCamp Europe 2026 surgió una “strong opinion, loosely held” (opinión firme, sostenida con flexibilidad) de que el conjunto completo de funciones de la RTC no debería vivir en absoluto en el núcleo, solo la arquitectura subyacente, dejando la capa rica de funciones a los plugins o a los alojamientos. Esa división se mantuvo en este ciclo. 7.1 no entregó ni la fontanería ni la función visible. La colaboración como hilo conductor se quedó en aspiración. 7.2 está ahora mismo previsto para el 9 de diciembre de 2026. Tampoco vendas a un cliente edición multiusuario en vivo para esa fecha, hasta que un field guide diga que salió.

#El debate del canary: un problema de proceso disfrazado

Lo más interesante que los committers debatieron en la WordCamp Europe no fue una función en absoluto. Plantearon mover WordPress a un modelo de canary deployment al estilo de Chrome con feature flags, una forma fundamentalmente distinta de construir, probar y lanzar el núcleo. El propio grupo reconoció que probablemente era “a technical solution to a communications problem” (una solución técnica para un problema de comunicación), y planteó preguntas obvias, como en qué se diferenciarían los builds canary de lo que el plugin Gutenberg ya ofrece, y si siquiera debería seguir existiendo un plugin Gutenberg.

Está lejos de ocurrir. Pero que los committers lo planteen dice algo sobre dónde creen que el modelo actual se queda corto, sobre todo en torno a las pruebas y el feedback. Los repetidos fracasos de la RTC a última hora son el síntoma: que una función importante llegue a dos semanas del lanzamiento antes de ser retirada es un fallo del bucle de feedback, no solo una función que no estaba lista. La idea del canary es un intento de detectar eso antes. Salga adelante o no, el hecho de que esté sobre la mesa es la admisión más honesta de todo el ciclo de que el proceso de construcción, y no el backlog de funciones, es la verdadera restricción.

#El problema del calendario

Aquí está el número duro. La Beta 1 fue el 15 de julio, el lanzamiento el 19 de agosto, y la Beta 3 trajo 71 correcciones. Son menos de cuatro semanas para cerrar una hoja de ruta tan grande. McCarthy heredó una lista ambiciosa y muy poco margen de tiempo, y el resultado realista siempre fue que algunos elementos salen, algunos se retrasan a 7.2, y algunos llegan tras feature flags en un estado parcial. Esto no es una crítica a la líder de lanzamiento, es la realidad estructural de una fecha fija fijada para coincidir con la WordCamp US. React 19 y el correo en Unicode cayeron antes de la Beta 3. Guidelines, RTC y la retirada del bloque Classic cayeron alrededor. El zip que salió es la lista más corta.

Para los propietarios de sitios, la lección práctica no ha cambiado: tratar la hoja de ruta como una declaración de intenciones, no como una garantía. Planifica en torno a lo que realmente salió, la estilización responsiva, los media del lado del cliente, Playlist y Tabs, y el editor en iframe. No le prometas a un cliente una función que aún cargaba “big, open strategy questions” (grandes preguntas estratégicas abiertas) seis semanas antes del lanzamiento, y no des por lanzada una función solo porque ya está integrada. El correo en Unicode se integró y luego se retiró. Es la misma lección.

#El retraso de 24 horas en las actualizaciones: seguridad frente a velocidad

Paralelamente a los debates sobre el lanzamiento del núcleo, el equipo de plugins de WordPress.org implementó un cambio importante en la infraestructura: un período de enfriamiento (cooldown) de 24 horas para todas las actualizaciones de plugins y temas. Aunque el anuncio presentó esta medida en el contexto de las actualizaciones automáticas para prevenir ataques a la cadena de suministro, resultó que el retraso se aplica a todas las rutas de actualización, incluyendo las instalaciones manuales desde el panel de administración.

Esto ha provocado una intensa resistencia por parte de desarrolladores y agencias:

• Miriam Schwab (Elementor) señaló que esto crea una peligrosa “ventana de vulnerabilidad”. En el momento en que se publica una versión de seguridad, el código de la solución es público y los bots pueden analizarlo para crear exploits, pero los administradores de los sitios tienen bloqueada la aplicación de la actualización durante 24 horas.
• Pavel Ciorici (desarrollador de temas) advirtió que si un desarrollador lanza una corrección rápida de errores durante el cooldown, el temporizador de 24 horas se reinicia, lo que agrava el retraso.
• Steve Burge (PublishPress) aportó un contrapunto, destacando que el proceso detectó con éxito problemas de seguridad menores en su primera semana y lo calificó como un buen paso adelante.
• Francisco Torres (co-representante del equipo de plugins) reconoció la fricción, confirmando que el equipo está revisando activamente el feedback y que es probable que haya cambios en esta medida.

Para las agencias y los sitios WordPress orientados al rendimiento, este cambio de infraestructura altera el ritmo de los lanzamientos y la aplicación de parches de seguridad, reforzando la necesidad de utilizar despliegues externos al repositorio o probar las actualizaciones en entornos de desarrollo antes del lanzamiento público.

#Qué hacer ahora

• Desarrolladores: el editor de entradas está siempre en iframe. Los bloques en API v2 o inferior necesitan un paso a v3. Los detalles están en la nota sobre el editor de entradas en iframe. React 19 sigue sin estar en el núcleo. Seguid probándolo en el plugin Gutenberg.
• Sitios con WP Rocket: un error de tipo en el módulo de compatibilidad con Cloudflare está dejando sitios fuera de línea en 7.1 (wp-media/wp-rocket#8596). Primero staging, después producción. Si mantenéis tiendas, esto es una comprobación de rendimiento y fiabilidad WooCommerce, no un pase cosmético.
• Sitios heredados: el bloque Classic sigue en el insertador. No hay migración forzada en 7.1. Audítalo cuando toques el contenido de todos modos, no porque este lanzamiento haya puesto un reloj en marcha.
• Equipos editoriales: Guidelines no salió. No rediseñéis el flujo de trabajo en torno a un experimento de Gutenberg.
• Todos: las actualizaciones automáticas a 7.1 ya están rodando. Probad en staging, sobre todo si corréis object cache, un plugin de caché de páginas o JavaScript propio del editor.

#Conclusión

WordPress 7.1 Mary Lou es un lanzamiento de plataforma útil con un nombre ligeramente engañoso. El planteamiento de la colaboración era intención real. La función de colaboración no salió, por segundo ciclo consecutivo. Si dejamos a un lado ese planteamiento, lo que llegó el 19 de agosto es más pequeño y sigue mereciendo la pena: estilización responsiva que elimina fricción diaria, media del lado del cliente que deja de estrellar los envíos HEIC contra el límite de memoria de PHP, Playlist y Tabs como bloques estables, una barra de administración persistente, y el editor de entradas siempre en iframe. Guidelines no aterrizó. La descontinuación del bloque Classic no aterrizó. React 19 y el correo en Unicode se quedaron fuera. La distancia entre la hoja de ruta de junio y el zip de agosto ya está medida, no prevista.

La historia más profunda sigue siendo el debate del canary. Un proyecto dispuesto a cuestionar públicamente su propio modelo de deployment es un proyecto que sabe que sus bucles de feedback están bajo tensión, la misma inquietud que alimenta el debate recurrente sobre si WordPress está perdiendo cuota de mercado. Sigue esa conversación, porque dará forma a los lanzamientos mucho después de este. Planifica en torno a lo que salió. Prueba el staging. Trata la próxima hoja de ruta como esta merecía tratarse: intención, hasta que exista el zip.

Última actualización: 20 de agosto de 2026.