WordPress 7.1 “Mary Lou” ya está disponible y confirma varios cambios que afectan directamente a los plugins y temas. El editor de entradas se ejecuta siempre dentro de un iframe, el navegador puede encargarse de buena parte del procesamiento de imágenes y se amplían las APIs para iconos SVG, estilos responsive y herramientas del editor.
La versión llegó el 19 de agosto de 2026 y ya no tiene sentido hablar de ella como una futura actualización. Si mantienes una extensión, un tema o una integración con el editor de bloques, toca probarla con WordPress 7.1 y revisar la compatibilidad declarada.
Las claves de WordPress 7.1 en 20 segundos
iframe, con un documento y una ventana propios.WordPress.org recoge el lanzamiento y sus novedades en el anuncio oficial de WordPress 7.1. Para el trabajo de desarrollo, el Field Guide de WordPress 7.1 reúne las notas técnicas publicadas durante el ciclo.
Este es uno de los cambios que más puede afectar a las extensiones que modifican el editor. En versiones anteriores, la decisión de usar un iframe dependía del tema, de la versión de la Block API y de los bloques que hubiera dentro de la entrada. Desde WordPress 7.1 el editor de entradas se aísla siempre de la página de administración.
El contenido que aparece dentro del lienzo tiene su propio document y su propio window. Por eso, un script que utilice el document global para buscar un bloque o añadir un evento puede estar mirando el documento equivocado. El resultado puede ser un botón que desaparece, estilos que dejan de aplicarse o funciones que solo fallan en determinadas pantallas.
La nota técnica sobre el editor dentro de un iframe recomienda obtener el documento del lienzo a partir de un elemento que esté dentro de él, usando ownerDocument y defaultView. También aconseja gestionar los eventos con useRefEffect para que se registren y limpien en el lugar correcto.
La mayoría de los bloques que siguen las APIs oficiales deberían funcionar sin cambios. La revisión es más importante en plugins que inyectan CSS o JavaScript directamente, manipulan el DOM, añaden botones a la barra del editor o dependen de que la administración y el lienzo compartan el mismo documento.
WordPress 7.1 cambia el recorrido de algunas subidas de imágenes. En navegadores compatibles, la compresión, el redimensionamiento, el recorte, la conversión de formato y la generación de tamaños pueden ejecutarse en el dispositivo del usuario mediante WebAssembly y una compilación de libvips.
La nueva ruta también contempla imágenes HEIC y HEIF procedentes de iPhone, AVIF, WebP, rotación según los datos EXIF y conversión de GIF animados a vídeo cuando el navegador reúne los requisitos. El proyecto ha añadido una cola de subidas, indicadores de progreso y reintentos automáticos para que una conexión inestable no obligue a empezar todo el proceso desde cero.
Esto puede reducir el consumo de CPU, memoria y tiempo de ejecución del servidor, sobre todo al generar muchos tamaños de una imagen grande. No significa que PHP, GD o Imagick dejen de ser necesarios. Los navegadores que no soportan esta ruta vuelven automáticamente al procesamiento tradicional del servidor.
También conviene corregir una preocupación habitual: los plugins de marcas de agua, CDN o metadatos no pierden necesariamente sus puntos de integración. El hook wp_generate_attachment_metadata sigue ejecutándose, aunque puede hacerlo en dos momentos, durante la creación inicial y después de finalizar la generación de tamaños. La documentación recomienda que estos procesos soporten correctamente ambas pasadas.
La guía técnica sobre el procesamiento de imágenes en el lado del cliente explica además cómo probar tamaños personalizados, conversiones de formato y la ruta alternativa del servidor. Si un plugin transforma imágenes, añade marcas de agua o sincroniza archivos con una CDN, debería probar todos esos casos.
WordPress 7.1 incorpora controles responsive directamente en el Editor del sitio. El usuario puede definir cómo se muestra un bloque en distintos tamaños de pantalla y previsualizar el resultado sin escribir CSS para cada ajuste. El cambio afecta especialmente a los temas de bloques y a las extensiones que añaden controles propios de diseño.
La versión también añade los bloques Playlist y Tabs, junto con mejoras en galerías y en el editor de medios. El nuevo editor de medios concentra en una ventana modal el recorte, el giro, el volteo y la edición de ciertos datos de la imagen, en lugar de repartir esas acciones por distintas zonas de la interfaz.
La barra de herramientas de administración permanece visible mientras el usuario se mueve por el área de administración. Los plugins que añadan acciones o botones ahí deben comprobar su posición, su aspecto y su comportamiento con distintos anchos de pantalla.
WordPress 7.1 abre a plugins y temas la API pública de iconos SVG. Las extensiones pueden registrar colecciones propias y utilizar esos iconos en el bloque Icon, en el editor, en la API REST o desde PHP mediante wp_get_icon(). WordPress aplica una lista de elementos permitidos para evitar que el SVG registrado incluya contenido no deseado.
La versión también completa el cambio de los controles de formulario de @wordpress/components, que pasan a tener una altura predeterminada de 40 píxeles. El antiguo indicador __next40pxDefaultSize deja de tener efecto, por lo que los plugins que todavía lo utilicen deberían retirarlo y revisar sus pantallas.
Otro ajuste afecta a jQuery UI, que sube de la versión 1.13.3 a la 1.14.2. WordPress mantiene jQuery.uiBackCompat activado para facilitar la transición, pero se eliminan algunas funciones antiguas. La nota de compatibilidad de jQuery UI identifica los métodos retirados que conviene buscar en el código.
La Abilities API continúa ampliándose en esta versión con mejoras para descubrir, validar y exponer capacidades. Es un cambio especialmente relevante para plugins que conectan WordPress con servicios externos y herramientas de automatización.
document, window y eventos sobre el lienzo del editor.Tested up to del archivo readme.txt a 7.1.Para realizar las comprobaciones puedes utilizar WordPress Beta Tester y Plugin Check. El primero sirve para instalar versiones de prueba y el segundo ayuda a localizar problemas habituales en plugins. El resultado de esas herramientas no sustituye a las pruebas manuales, sobre todo cuando la extensión altera el editor o el tratamiento de archivos multimedia.
Antes de actualizar un sitio también conviene revisar los requisitos de PHP para WordPress 7.1 y probar la copia de seguridad y el proceso de restauración. La compatibilidad de una extensión no depende solo del núcleo: también influyen el tema activo, la versión de PHP y el resto de plugins instalados.
Fuente: notas de la versión WordPress 7.1 y documentación técnica de WordPress Core.
WordPress 7.1 “Mary Lou” se publicó el 19 de agosto de 2026. La versión está disponible desde el panel de actualizaciones y desde el archivo oficial de versiones de WordPress.org.
Los que modifican el editor con JavaScript o CSS, acceden directamente al DOM, añaden controles a la barra de herramientas, procesan imágenes o dependen de componentes antiguos de jQuery UI. Los bloques que usan las APIs oficiales parten de una situación más favorable, pero también deben probarse.
No. La ruta del navegador se usa cuando el dispositivo y el navegador cumplen los requisitos. En los demás casos WordPress utiliza el procesamiento del servidor sin que el usuario tenga que cambiar ninguna opción.
No necesariamente. El hook wp_generate_attachment_metadata continúa ejecutándose, aunque puede hacerlo durante la subida inicial y después de finalizar la generación de tamaños. El plugin debe estar preparado para gestionar correctamente esas dos pasadas.
Solo después de probar el plugin con WordPress 7.1. Actualizar ese campo informa de una compatibilidad que el desarrollador declara, pero no reemplaza las pruebas en el editor, las subidas de imágenes y las pantallas propias de la extensión.
