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 presenta 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 ese lanzamiento. Regresa 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 saldrá de verdad el 19 de agosto, y una historia de colaboración sobre la que aún se discute en abierto.

Actualización, 28 de julio de 2026: desde que se publicó la hoja de ruta, dos elementos han salido de este lanzamiento. La actualización de React 18 a React 19 se ha aplazado más allá de 7.1, y el soporte para direcciones de correo en Unicode ha sido retirado. La Beta 3 ya está fuera, con 71 correcciones. La fecha de lanzamiento del 19 de agosto no se ha movido. Las dos correcciones están desarrolladas en las secciones de abajo.

#En resumen

• Anne McCarthy lidera 7.1 por primera vez, con el lanzamiento fijado para el 19 de agosto de 2026, el día de cierre de la WordCamp US en Phoenix. La Beta 3 ya ha salido con 71 correcciones.
• El lanzamiento está estructurado en torno a la colaboración, pero la colaboración en tiempo real (RTC) sigue sin resolverse después de haber sido recortada de 7.0.
• Los logros realmente confirmados son la estilización responsiva, la descontinuación del bloque Classic, y las funciones de flujo de trabajo Guidelines e IA. React 19 estaba en esa lista y ahora se ha ido 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.
• Con una ventana de estabilización tan corta, hay que esperar que más elementos de la hoja de ruta se retrasen o salgan tras flags. Dos ya lo han hecho.

#Qué sale 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. Los elementos de alta confianza son infraestructurales o están orientados a los constructores. La historia de la colaboración, aquella que da nombre al lanzamiento, se sitúa en la franja media a baja.

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. La hoja de ruta lleva la estilización de bloques por breakpoint al propio editor, junto con la estilización de estados interactivos para hover, foco y activo, y una vista “display inherited styles” (mostrar estilos heredados) para que puedas ver de dónde proviene realmente un estilo.

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, la descontinuación del 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 ya 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ó. Según la discusión en el núcleo, el bloque Classic sigue apareciendo en el insertador en 7.1 exactamente como hoy, 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 está en pausa. 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

La hoja de ruta apuesta por la IA, pero de forma más disciplinada que “añadir una caja de chat”. 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, suponiendo que salga en un estado utilizable. Aquí se califica de confianza media precisamente porque la ambición de la función y una ventana de estabilización de cuatro semanas no siempre concuerdan.

#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 plantea 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 WordPress 7.1 real-time collaboration, y la hoja de ruta no resuelve tanto las preguntas allí planteadas como vuelve 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. Es una división significativa. Si se mantiene, 7.1 podría entregar la base técnica de la colaboración sin la función visible, lo que convertiría el planteamiento de la “colaboración como hilo conductor” en más aspiración que entrega para este ciclo.

#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 estaba prevista para el 15 de julio, el lanzamiento es el 19 de agosto, y la Beta 3 ya lleva 71 correcciones detrás. 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 son los dos primeros nombres de esa lista, y cayeron antes de la Beta 3, no después.

Para los propietarios de sitios, la lección práctica es tratar la hoja de ruta como una declaración de intenciones, no como una garantía. Planifica en torno a lo que ahora está realmente confirmado, la estilización responsiva y el trabajo de bloques de Gutenberg 23.6, y vigila los elementos de confianza media (Guidelines, la base de theming del rediseño del panel) en lugar de construir planes sobre ellos. No le prometas a un cliente una función que aún carga “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 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 antes del 19 de agosto

• Desarrolladores: React 19 no entra en 7.1, así que lo que se ha movido es el plazo, no el trabajo. Seguid probando bloques personalizados y extensiones de editor con él en el plugin Gutenberg, porque fue precisamente la compatibilidad con plugins la que provocó el aplazamiento.
• Sitios heredados: auditad dónde aún dependéis del bloque o editor Classic e iniciad un plan de migración, porque el reloj de la descontinuación ya ha arrancado formalmente.
• Proyectos sensibles al rendimiento: el cambio a la carga diferida de TinyMCE es rendimiento gratis en cuanto dejas el bloque Classic, conviene tenerlo en cuenta en una revisión de rendimiento WooCommerce.
• Equipos editoriales: vigilad Guidelines y las herramientas de IA, pero no rediseñéis vuestro flujo de trabajo en torno a una función de confianza media hasta que salga de verdad.
• Todos: probad con la Beta 3, que ya está fuera con 71 correcciones detrás. Una ventana de estabilización corta significa que las pruebas de la comunidad cuentan más de lo habitual en este ciclo.

#Conclusión

WordPress 7.1 es un lanzamiento sólido con un nombre ligeramente engañoso. El planteamiento de la colaboración es intención real, pero la función de colaboración sigue sin resolverse, y los committers debaten abiertamente si pertenece al núcleo y si todo el proceso de construcción necesita replantearse. Si dejamos a un lado ese planteamiento, lo que queda el 19 de agosto es un lanzamiento de plataforma más pequeño pero todavía útil: estilización responsiva que elimina fricción diaria, los bloques Playlist y Tabs llegando estables con Gutenberg 23.6, una descontinuación del bloque Classic que ayuda al rendimiento, y un primer paso disciplinado en IA a través de Guidelines. La modernización a React 19 y el soporte de correo en Unicode se han quedado los dos fuera de este ciclo, la prueba más clara hasta ahora de lo ancha que puede ser la distancia entre una hoja de ruta publicada y una versión lanzada.

La historia más profunda es 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 de WordPress mucho después de que salga 7.1. Por ahora, planifica en torno a lo confirmado, prueba pronto, y trata el resto de la hoja de ruta como una declaración de intenciones, no como una promesa de entrega.

Última actualización: 28 de julio de 2026.