WordPress 7.1, llamado “Mary Lou”, está disponible desde el 19 de agosto de 2026. La versión mejora significativamente la edición, los medios y varias API, pero también modifica comportamientos que pueden afectar extensiones, bloques e interfaces de administración personalizadas. Este es el método a seguir para actualizar sin transformar una nueva característica funcional en un incidente de producción.
1. Qué contiene realmente WordPress 7.1
WordPress 7.1 no es sólo una versión de mantenimiento. La publicación oficial destaca una barra de administración persistente en las interfaces de edición, nuevas configuraciones responsivas en el editor del sitio, una revisión de la edición de medios, notas colaborativas enriquecidas y nuevos bloques como pestañas y listas de lectura.
La guía técnica de la versión también menciona más de 180 correcciones en el núcleo, más de 630 correcciones de Gutenberg, alrededor de un centenar de mejoras y varios desarrollos API. Esta densidad justifica unas pruebas de aceptación estructuradas, incluso cuando el sitio rara vez utiliza el editor de bloques frontal.
Sin embargo, ciertas funciones esperadas no se integraron en la versión final. React 19 y la colaboración en tiempo real se retrasaron notablemente. Por lo tanto, es importante trabajar a partir de las notas finales de la versión y no de los artículos publicados durante el ciclo beta.
2. Mejoras editoriales inmediatamente visibles
Los equipos de contenido verán rápidamente varios cambios útiles. Los estilos responsivos se pueden ajustar desde el editor del sitio, sin agregar CSS específico sistemáticamente. La funcionalidad de Notas obtiene texto enriquecido y menciones, mientras que los bloques Lista de reproducción y Pestañas ofrecen nuevas posibilidades de estructuración.
Estas características reducen potencialmente la cantidad de componentes personalizados. Sin embargo, no se deben activar sin comprobar su comportamiento con el tema, las plantillas y las reglas editoriales existentes. Un bloque nativo más reciente no es automáticamente preferible a un componente que ya ha sido industrializado, traducido y probado.
Para un sitio administrado por varios perfiles, también debes verificar los derechos. Una nueva capacidad visible para un administrador no necesariamente tiene que estar abierta para un colaborador o cliente. Por tanto, las pruebas de aceptación deben realizarse con los roles realmente utilizados y no sólo con una cuenta de administrador.
3. Nuevo procesamiento de imágenes en el lado del navegador
Uno de los cambios más interesantes se refiere a los medios de comunicación. WordPress 7.1 puede realizar parte de la compresión, el cambio de tamaño y la generación de miniaturas en el navegador antes de enviarlas al servidor. El objetivo es reducir la carga de PHP y evitar ciertos fallos relacionados con la memoria o retrasos en la carga.
El beneficio puede ser significativo para el alojamiento limitado o para los contribuyentes que importan directamente fotografías muy pesadas. Sin embargo, hay que comprobar tres puntos: la calidad visual obtenida, la conservación de metadatos útiles y la compatibilidad con las extensiones de optimización ya instaladas.
Un canal de medios que cambia el tamaño de una imagen en el navegador, luego nuevamente en WordPress y finalmente en una CDN puede producir una degradación innecesaria. Por lo tanto, la actualización es una oportunidad para documentar todo el proceso: archivo fuente, transformación local, tamaños de WordPress, conversión WebP o AVIF, almacenamiento en caché y distribución.
4. Cambios técnicos a tener en cuenta
WordPress 7.1 ahora ejecuta consistentemente el lienzo del editor de contenido en un iframe, para todos los temas. Las extensiones que manipulan directamente el documento principal, inyectan estilos en el nivel incorrecto o asumen que el lienzo comparte el mismo contexto DOM pueden experimentar regresiones.
El lanzamiento también actualiza jQuery UI y evoluciona varios elementos del editor, incluidos DataViews, DataForm, estilos globales y la API de registro de íconos públicos. Este último es útil para armonizar extensiones, pero impone una lista conservadora de atributos SVG permitidos. Por lo tanto, un icono personalizado que utilice propiedades no autorizadas puede estar dañado.
Las pruebas deben cubrir errores de JavaScript de la consola, pantallas de administración personalizadas, campos avanzados, bloques de casas, vistas previas y guardado de contenido. Una página que “parece funcionar” puede ocultar un error que sólo se hace evidente después de varios cambios.
5. Puntos de vigilancia para YOOtheme y creadores de páginas
En un sitio YOOtheme, Elementor, Divi o equivalente, sería tentador considerar las nuevas funciones de Gutenberg como secundarias. Esto es un error: el núcleo de WordPress, la biblioteca multimedia, las funciones, las API y muchas extensiones siguen siendo comunes a todo el sitio.
Para YOOtheme, debes al menos probar abrir y guardar una página, campos dinámicos, modelos de artículos, imágenes responsivas, la biblioteca multimedia, posibles códigos cortos e interacciones con ACF. También es necesario comprobar que un artículo modificado desde el editor nativo no pierde ningún parámetro utilizado por el constructor.
Los sitios multilingües requieren pruebas de aceptación adicionales: duplicación o traducción de contenidos, sincronización de medios, enlaces entre idiomas, vista previa y actualización de metadatos SEO.
6. La lista de comprobación antes de producción
Una actualización seria comienza con un clon de producción reciente, con las mismas versiones de PHP, base de datos, caché y extensiones. Las pruebas de aceptación deben cubrir las siguientes rutas:
- inicio de sesión, restablecimiento de contraseña y gestión de roles;
- creación, modificación, vista previa y publicación de una página y un artículo;
- importar, recortar, reemplazar y eliminar una imagen;
- editar contenido extenso que contenga bloques, tablas, botones y medios;
- operación de formularios, búsquedas, filtros, espacios privados y llamadas API;
- plantillas de renderizado en dispositivos móviles, tabletas y computadoras de escritorio;
- ausencia de PHP, errores de JavaScript, tareas programadas o solicitudes anormalmente lentas;
- Controle las páginas estratégicas con una herramienta de comparación visual.
También debe ejecutar las pruebas de no regresión disponibles y verificar si hay extensiones que hayan sido abandonadas o no declaradas compatibles. La ausencia de un mensaje de alerta no es prueba de compatibilidad.
7. El plan de implementación recomendado
El despliegue debe realizarse dentro de una ventana controlada. Antes de intervenir, haga una copia de seguridad de los archivos, la base de datos, la configuración de la caché y, si es posible, una instantánea completa del entorno. Pruebe la restauración antes de que la necesite.
Luego aplique la actualización en preproducción, solucione las incompatibilidades y luego repita las pruebas de aceptación con una muestra de contenido real. En producción, active un modo de mantenimiento breve, implemente las mismas versiones validadas, borre cachés y realice un monitoreo inmediato de las rutas críticas.
Se deben monitorear las primeras horas: tasas de error, registros de PHP, tiempos de respuesta, colas de tareas, envíos de correo electrónico y comentarios de los equipos editoriales. El plan de reversión debe especificar quién decide, qué umbral desencadena la reversión y cómo se maneja el contenido capturado mientras tanto.
8. ¿Deberías actualizar inmediatamente?
Una versión importante trae mejoras y correcciones útiles que no deben ignorarse. Sin embargo, no exige que se ponga en producción el día de su lanzamiento. Para un sitio de exhibición simple, unos días de validación pueden ser suficientes. Para una extranet, un negocio online o una plataforma altamente personalizada, es preferible una campaña específica de pruebas de aceptación.
El indicador correcto no es el número de días desde la publicación, sino el nivel de control de su canal de actualización. Un sitio con puesta en escena, pruebas y reversión fieles puede adoptar rápidamente WordPress 7.1. Un sitio sin respaldo probado o inventario de extensiones debe primero asegurar su funcionamiento.
Este enfoque es consistente con nuestro método de recuperación de mantenimiento de una aplicación empresarial : observar, reproducir, probar y sólo después modificar la producción.
Conclusión
WordPress 7.1 mejora significativamente la experiencia editorial y el procesamiento de medios. Sin embargo, su valor depende de la calidad del despliegue. Unas pruebas de aceptación centradas en el editor, las imágenes, las extensiones y los roles le permite aprovechar las nuevas funciones sin debilitar las rutas existentes.
Partitech apoya a las empresas en la auditoría, actualización y mantenimiento de sitios WordPress y YOOtheme, con preproducción, pruebas sin regresión, optimización del rendimiento y plan de reversión.