WordPress 7.1: pruebas para el editor en iframe

WordPress 7.1, publicado el 19 de agosto de 2026, hace que el editor de entradas funcione siempre dentro de un iframe. Esto se aplica independientemente del tipo de tema, de la versión de la Block API utilizada por los bloques o de la presencia de metaboxes heredadas. Para quienes mantienen temas y plugins, la pregunta principal ya no es si el iframe se activará, sino si CSS y JavaScript apuntan al documento correcto y si las interfaces auxiliares siguen funcionando cuando el lienzo del editor está aislado.

El mayor riesgo de regresión está en extensiones que acceden al contenido del editor mediante document o window global, hojas de estilo que dependen del árbol DOM de la pantalla de administración y bibliotecas que posicionan popovers o escuchan eventos sin considerar que el contenido editable vive en otro documento. El cambio es deliberado: el aislamiento evita que los estilos de wp-admin se filtren al contenido, hace que las unidades de viewport y las media queries reflejen el tamaño real del lienzo y acerca la representación del editor al front-end.

Qué cambia en WordPress 7.1

Hasta WordPress 7.0, el editor de entradas todavía podía volver a un modo sin iframe en algunos escenarios de compatibilidad. En 7.1, ese fallback deja de ser la referencia: el lienzo de la entrada permanece dentro de un iframe incluso cuando el contenido usa bloques antiguos. Gutenberg 23.6 o posterior ya fuerza este comportamiento y puede utilizarse como entorno de prueba.

Los bloques heredados ya no impiden el iframe. La presencia de bloques con una versión de Block API anterior a la 3 ya no sirve para mantener el editor en el documento principal.
Las metaboxes ya no impiden el iframe. La compatibilidad con metaboxes ya se había adaptado en versiones anteriores y 7.1 mantiene el lienzo aislado aunque existan.
El editor y el contenido del editor son contextos distintos. Controles, sidebars y plugins de la interfaz viven en el contexto administrativo; el contenido editable vive en el documento del iframe.
CSS y JavaScript deben cargarse en el destino correcto. Un asset presente en la página de administración no está automáticamente en el mismo contexto DOM que el contenido del lienzo.

Matriz de pruebas antes de actualizar el sitio

Área	Qué probar	Señal de regresión	Acción probable
CSS del contenido	Tipografía, espacios, ancho, estados responsive, selectores de bloques y estilos del tema dentro del lienzo	Bloque sin estilo, regla que solo funciona en el front-end o layout diferente de lo esperado	Revisar dónde se encola el CSS y eliminar dependencias de ancestros de wp-admin
CSS de la interfaz	Inspector, toolbar, sidebar y componentes añadidos por el plugin	Controles desconfigurados o estilos que se filtran al contenido	Mantener los assets de interfaz en el hook del editor y separarlos del CSS del contenido
DOM y eventos	Selección de elementos, listeners de ratón/teclado, resize, scroll, drag-and-drop y mediciones de posición	querySelector no encuentra el bloque, un atajo no se activa o el listener se registra en el documento equivocado	Derivar ownerDocument y defaultView de un elemento del lienzo y limpiar listeners cuando cambia la referencia
Metaboxes	Campos, guardado, pestañas, dropdowns, calendarios, modales y popovers	Popover recortado, campo inaccesible o interacción que pierde el foco	Evitar UI que se salga del contenedor de la metabox o renderizar popovers fuera de él
Rich text	Formatos personalizados, enlaces, tooltips y UI anclada a la selección de texto	Popover que se abre lejos de la selección o foco que vuelve al lugar incorrecto	Usar APIs de anclaje compatibles con iframe, como useAnchor, en lugar de cálculos globales
Bibliotecas externas	Carruseles, masonry, editores, pickers y bibliotecas que leen window/document	Funciona en el front-end y falla solo en el editor	Inicializar desde una referencia al elemento y, si hace falta, corregir la biblioteca para aceptar el documento relativo
Bloques antiguos	Entradas reales con bloques API v1/v2, bloques dinámicos y extensiones de terceros	Error que no aparecía en 7.0 porque el editor salía del iframe	Corregir compatibilidad y migrar los bloques propios a apiVersion 3 después de probarlos

CSS: separa los estilos del contenido de los estilos de la interfaz

La primera revisión debe responder una pregunta simple: ¿la regla estiliza el contenido editable o la interfaz del editor? La documentación de WordPress recomienda enqueue_block_editor_assets para scripts y estilos de la interfaz del editor, como controles del inspector, toolbar, variaciones y plugins del editor. Para assets que deben llegar a los bloques del lienzo, enqueue_block_assets es la vía principal; desde WordPress 6.3 esos assets también se cargan en el editor con iframe y siguen disponibles en el front-end.

Presta especial atención a selectores que empiezan en el body de wp-admin, atraviesan wrappers administrativos o suponen que el bloque es descendiente directo de la página del editor. Con el iframe, el contenido no comparte ese árbol de ancestros. Las reglas que dependen de una cadena “body administrativo + wrapper del editor + bloque” probablemente dejarán de coincidir. Los selectores centrados en el propio bloque, junto con estilos declarados mediante theme.json o las APIs de estilos de bloques, encajan mejor con el modelo aislado.

Compara también breakpoints, vw/vh y layouts fluidos. Una ventaja del iframe es que las media queries y las unidades relativas al viewport responden a las dimensiones del lienzo y no al ancho total de la página administrativa. Una diferencia visual en esta zona puede ser una corrección de comportamiento y no un bug; la comparación adecuada es el front-end.

JavaScript y el riesgo de que document/window apunten al lugar equivocado

El principal punto técnico señalado por el equipo de WordPress es que el iframe tiene su propio document y window. Los scripts del editor normalmente se ejecutan en la página administrativa, por lo que usar los objetos globales para buscar un elemento del lienzo, medir la ventana o registrar eventos puede afectar al documento padre en lugar del documento donde vive el bloque.

Para código React de bloques, la recomendación es obtener una referencia a un elemento renderizado en el lienzo y usar ownerDocument desde ese elemento para llegar al documento correcto y defaultView para llegar a su ventana. Para listeners, WordPress recomienda useRefEffect porque permite instalar y retirar el listener cuando cambia la referencia del elemento, algo importante cuando el lienzo se vuelve a renderizar o montar.

Las pruebas deben cubrir eventos de teclado, ratón, pointer, scroll y resize; APIs de selección; mediciones de layout; drag-and-drop; portales; y cualquier búsqueda realizada con selectores globales. Si una función desaparece solo dentro del editor, abre la consola y confirma en qué document está buscando el código antes de asumir que el bloque está roto.

Metaboxes: el iframe no significa que desaparezcan

Las metaboxes clásicas siguen siendo un caso importante de compatibilidad. El cambio de 7.1 no exige eliminarlas para que el editor funcione, pero elimina la expectativa de que su presencia desactive el iframe. Por eso, plugins que nunca se probaron con esta combinación pueden revelar problemas ahora.

Hay dos áreas ya documentadas por el proyecto. La primera es el overflow: el contenedor de la metabox puede recortar elementos que se extienden más allá de sus límites, especialmente menús y popovers que se abren hacia arriba. Componentes de @wordpress/components como Popover y Dropdown evitan el problema al renderizar la capa en una región apropiada de la interfaz. Si el plugin usa una solución propia, prueba calendarios, autocompletados, selects avanzados y menús a distintas alturas de página.

La segunda es la UI anclada a una selección de rich text. Los plugins que añaden formatos de texto, tooltips o pequeños editores flotantes no deben calcular posiciones suponiendo un único documento. La API useAnchor de @wordpress/rich-text es la referencia recomendada para este tipo de anclaje.

Los plugins con bibliotecas de terceros merecen una ronda aparte

Una biblioteca puede recibir correctamente el elemento del bloque y aun así acceder internamente a window o document global. Esto es común en componentes antiguos de drag, zoom, masonry, pickers y widgets. La guía de migración de WordPress recomienda preferir bibliotecas que acepten un elemento objetivo y deriven de él el documento. Cuando la dependencia está fuera de tu control, la solución sostenible es parchear la biblioteca o enviar un cambio upstream; usar una copia de la biblioteca cargada dentro del iframe puede servir como transición, pero no es el enfoque preferido a largo plazo.

Con jQuery o plugins de jQuery, pasa el elemento del bloque a la inicialización en vez de volver a buscar el nodo desde el document global. Confirma también que el componente se destruya cuando el bloque se desmonta para no acumular listeners, observers o instancias huérfanas al cambiar de modo en el editor.

Block API v3 sigue siendo importante, pero ya no controla el iframe

Migrar los bloques propios a apiVersion 3 sigue siendo recomendable porque esta versión señala compatibilidad con el editor en iframe y es la referencia de la documentación actual. La diferencia es que, en WordPress 7.1, mantener apiVersion 1 o 2 no devuelve el editor al modo antiguo. “Funciona porque sigue en API v2” deja de ser una estrategia de compatibilidad.

En la práctica, trata API v3 como parte de la modernización del bloque y no como un interruptor del iframe. Primero reproduce el comportamiento en una copia del sitio, corrige dependencias de DOM y assets y solo entonces actualiza la declaración del bloque, validando edición, guardado, reapertura y representación en el front-end.

Plan de pruebas en staging

Clona una muestra realista. Incluye entradas antiguas, bloques personalizados, bloques de terceros, metaboxes, campos complejos y contenido con layouts responsive.
Prueba WordPress 7.1 con la misma pila de plugins que producción. Si necesitas reproducir el comportamiento en otra instalación, Gutenberg 23.6 o posterior fuerza el editor de entradas en iframe.
Abre la consola y el panel de red. Busca errores JavaScript, assets 404, estilos ausentes y avisos que aparecen solo durante la edición.
Inspecciona el iframe. Confirma que las hojas de estilo destinadas al contenido realmente se cargan dentro del documento del lienzo.
Ejercita las interacciones. Inserta, selecciona, duplica, mueve, arrastra, usa atajos, abre popovers, edita rich text, alterna sidebars y trabaja con metaboxes.
Guarda y vuelve a abrir. Una integración puede parecer correcta durante la sesión y fallar en la serialización, persistencia de meta o remontaje del bloque.
Compara con el front-end. Verifica tipografía, espacios, breakpoints, ancho y estados responsive para identificar divergencias reales.
Prueba de forma aislada los plugins más sensibles. Si algo falla, repite con los demás plugins desactivados para separar un conflicto de una incompatibilidad directa con iframe.

Checklist de publicación

El CSS del contenido llega al documento del iframe y no depende de ancestros de wp-admin.
El CSS y los scripts de la interfaz usan el contexto administrativo adecuado.
Ninguna función del bloque depende de document/window global para llegar al lienzo.
Listeners y observers se eliminan cuando los elementos se remontan o desmontan.
Los popovers y dropdowns de metaboxes no quedan recortados.
Los formatos de rich text conservan posición, foco y selección dentro del iframe.
Las bibliotecas externas reciben un elemento objetivo y funcionan sin suponer un único window/document global.
Las entradas con bloques antiguos se abren, editan, guardan y vuelven a abrir sin errores.
El editor mantiene coherencia visual con el front-end en distintos anchos.
Existe un backup y una ruta de rollback antes de actualizar producción.

Fuentes oficiales para consultar durante la migración

La regla práctica es sencilla: no tomes el hecho de que un plugin funcionara en el editor de entradas de WordPress 7.0 como prueba de compatibilidad. WordPress 7.1 elimina un fallback que todavía podía ocultar parte de los problemas. Si CSS, acceso al DOM, foco, metaboxes y bibliotecas se prueban en el documento correcto, la transición se vuelve mucho más predecible y el aislamiento del iframe puede mejorar la consistencia del editor en lugar de convertirse en una fuente de regresiones.