La versión sigue en desarrollo
A 15 de octubre, el calendario oficial sitúa WordPress 7.2 Beta 1 el 20 de octubre a las 15:00 UTC y la versión final el 8 de diciembre. Son objetivos actuales del proyecto, no una garantía de que no cambien fechas o alcance. El equipo prevé que 7.2 sea la última versión principal de WordPress en 2026 y que incluya un nuevo tema predeterminado.
Para los responsables de sitios, ahora toca preparar un entorno de pruebas, no actualizar producción. Antes de Beta 1 todavía hay desarrollo; las betas y candidatas sirven para encontrar problemas, no para operar sitios públicos normales. Sigue la página de la versión y las notas de desarrollo antes de decidir sobre la actualización estable.
Ya hay un cambio de compatibilidad SQL documentado
Una nota de desarrollo concreta explica que WordPress 7.2 tratará el modo MySQL `NO_BACKSLASH_ESCAPES` como no compatible y lo eliminará de los modos de sesión al conectarse. WordPress usa la barra inversa para escapar caracteres especiales en SQL; con ese modo, la base de datos la interpreta de otra manera. El cambio afecta a la sesión de WordPress, no a la configuración global del servidor.
El equipo Core indica que la mayoría de sitios no notará diferencias, aunque advierte que WordPress puede no funcionar bien si el modo sigue activo. Si una instalación depende de él por decisión propia, necesita revisión técnica. El filtro documentado debe cargarse antes que los plugins normales porque la conexión se establece primero. No es motivo para modificar los ajustes SQL de todos los servidores.
Gutenberg no garantiza cambios en Core
Gutenberg mantiene su propio ritmo de versiones y sus notas pueden incluir trabajo que no llegue a una versión concreta del núcleo. La hoja de ruta de 7.2 menciona un nuevo tema predeterminado y dice que se considerarán funciones cuando estén suficientemente listas, pero no es una lista cerrada de cambios del editor. Las notas de beta y la guía final serán las referencias para temas y plugins.
La pregunta útil para una agencia es qué código aparece realmente en la beta y en la versión final de 7.2. Contrasta la compilación con los plugins, tema, bloques propios, versión de PHP, alojamiento y extensiones del editor de cada cliente. Prueba el sitio real en vez de confiar únicamente en una etiqueta de compatibilidad.
Una preparación segura, paso a paso
Crea una copia de staging con copias de seguridad recientes y una restauración probada. Registra las versiones de WordPress, PHP, base de datos y plugins, además del código que modifique SQL o el editor. Cuando llegue Beta 1, prueba un sitio representativo: edición, publicación, plantillas, tareas programadas, formularios, pagos o membresías y registros.
Mantén producción en una versión estable con soporte hasta que salga WordPress 7.2 final y pasen tus pruebas. Durante la beta, comunica errores reproducibles con los datos del entorno. Tras el lanzamiento, actualiza primero staging, confirma copias y recuperación y después planifica producción según riesgo y mantenimiento del sitio. No prometas compatibilidad sin probarla.
Fuentes y lecturas adicionales
¿Quieres señalar un error factual o sugerir una fuente? Contactar con la redacción.
