El martes 19 de agosto WordPress 7.1 sale en producción, coincidiendo con el cierre de WordCamp US. En la presentación hablarán de estilos responsive en el editor, del bloque Tabs y de la API de iconos SVG. Todo eso suena bien en un Keynote. Lo que no verás en pantalla grande es el cambio que más probabilidades tiene de romperte algo en silencio: a partir de 7.1, el editor de entradas queda siempre dentro de un iframe, igual que ya pasó con el editor de sitio en la 7.0.
Lo leí en la nota para desarrolladores de Justin Tadlock y lo confirmé en el Field Guide oficial. No es una opción ni un experimento: es la dirección que ha elegido el proyecto. Y si mantienes plugins de bloques, temas con lógica en el admin o agencias con decenas de sitios en hosting compartido, te toca probar ya, no cuando un cliente te llame el miércoles por la mañana.
En mi experiencia, los cambios de Gutenberg que no duelen de primeras son los que anuncian con titular grande. Los que te destrozan el flujo de maquetación suelen llegar como «mejoras de arquitectura del editor». El iframe encaja en esa segunda categoría.
Por qué el iframe no es un detalle técnico
Cuando el editor vive dentro de un iframe, el DOM de la página de administración deja de ser el mismo que ve tu bloque. Los estilos globales del admin no se heredan igual. Los scripts que asumían acceso directo al documento pueden quedarse fuera. Los plugins que inyectaban CSS en el editor con trucos de la época clásica — y siguen haciéndolo porque «funcionaba» — se encuentran de repente en otro contexto.
ByteIota lo resume sin rodeos: si no has testeado contra 7.1, este es el punto de partida antes que la Abilities API o los breakpoints en theme.json. Tiene sentido. La API de capacidades es opt-in y no te va a tumbar la maquetación de un landing mañana. Un editor aislado sí puede hacerlo.
Además, el Field Guide insiste en que los bloques deberían apuntar a la versión 3 de la API de bloques para compatibilidad plena. En la práctica, ¿cuántos plugins de terceros llevan esa etiqueta al día? Yo no pondría la mano en el fuego por la mitad del directorio oficial. Y en sitios de clientes con stacks de bloques premium apilados — Kadence, Spectra, lo que sea — la fricción se multiplica.
Lo que el marketing de la release no prioriza
WordCamp US va a celebrar la release en directo. Es buen teatro. Pero el calendario real para quien mantiene webs es otro: RC3 ya está fuera, el dry run es el 18 y el martes siguiente entra en miles de instalaciones con actualizaciones automáticas activadas.
Gutenberg Times recoge en su edición del 15 de agosto otro aviso fácil de pasar por alto: cambios en la cabecera de filas de la tabla de entradas. Suena menor hasta que un plugin de columnas personalizadas o un filtro de SEO deja de alinearse. Son dos avisos distintos, mismo patrón: compatibilidad de plugins que nadie promociona en el escenario principal.
Y mientras tanto, la 7.0.4 llegó el 12 de agosto con un parche de seguridad serio — ejecución remota autenticada vía subida de archivos con Imagick y Ghostscript — que ya comentamos por aquí. Si tu hosting no ha aplicado parches de la rama 7.0, estás acumulando deuda antes siquiera de abrir el iframe.
Qué haría yo antes del martes
No voy a venderte miedo gratuito. Pero sí orden de trabajo concreto:
- Clona un staging con RC3 o la última candidata disponible.
- Abre el editor de entradas en un tema de bloques y prueba los bloques que usáis de verdad, no solo el párrafo y la imagen.
- Revisa consola del navegador: errores de CORS, estilos que desaparecen, metaboxes que no cargan.
- Si dependéis de un plugin de maquetación, mirad su changelog por «7.1» o «iframe». Si no hay mención, asumid riesgo.
- Planificad ventana de actualización manual en sitios críticos, aunque tengáis auto-updates. El martes 19 a primera hora no es el momento de descubrir que el editor de un cliente en WooCommerce no abre.
La Abilities API, los pseudo-estados hover en botones y la biblioteca de iconos SVG son mejoras reales para equipos que desarrollan. Para la pyme que paga hosting y quiere editar una landing el jueves, el iframe es la noticia.
Lo que no me cuadra del relato oficial
WordPress empuja hacia un editor más predecible y aislado. Lo entiendo desde arquitectura. Pero el ecosistema sigue siendo un mosaico de extensiones comerciales con ciclos de actualización dispares. Anunciar la release en un evento masivo sin una campaña paralela de «compatibilidad de plugins verificada» me parece desalineado con la realidad de quien vive del mantenimiento.
Tampoco ayuda que React 19 vuelva a quedar fuera de esta ronda, según recogen varios resúmenes de la beta. Cada release aplaza dependencias y los plugins arrastran deuda. El iframe es la capa visible; debajo sigue habiendo fricción que no se resuelve con un bloque Tabs nuevo.
Si tu stack es headless y casi no tocáis el editor clásico, respiráis. Si facturáis por webs WordPress tradicionales con editores no técnicos, el martes no es festivo.
Fuentes
- What’s new for developers? (August 2026) — WordPress Developer Blog
- WordPress 7.1 Field Guide — Make WordPress Core
- WordPress 7.1 Ships August 19: New APIs and What to Fix Now — byteiota
- WordPress 7.1 arrives at WordCamp US — Gutenberg Times
Si mañana tu proveedor de hosting activara las actualizaciones automáticas de WordPress en todos tus sitios de clientes justo el 19 de agosto, ¿tendrías ya un staging probado o preferirías negociar una semana de margen a cambio de dormir tranquilo?