Beta 4 es para pruebas, no para actualizar producción
WordPress.org publicó Beta 4 el 3 de noviembre. El proyecto indica que la compilación es solo para desarrollo y pruebas y no debe instalarse en sitios de producción o críticos. La versión final de WordPress 7.2 está programada para el 8 de diciembre de 2026, aunque el calendario es un objetivo, no una garantía. El proyecto explica que no hubo anuncio separado de Beta 3 porque WordPress 7.1.4 incluyó la compilación de desarrollo Beta 3.
Esta es una actualización específica que complementa la guía anterior de CherTra News sobre la preparación para WordPress 7.2. La guía cubre el ciclo general y la planificación; este artículo se centra en lo comunicado para Beta 4 y en cómo probarla con seguridad. La versión beta no elimina las comprobaciones de compatibilidad ya recomendadas.
Ajustes de accesibilidad, editor y API
La nota de Beta 4 describe avances en accesibilidad, fiabilidad del editor y API para desarrolladores, además de correcciones de errores y compatibilidad. Incluye una mayor visibilidad del foco de teclado en el modo Windows High Contrast, ajustes de administración y correcciones de alineación RTL de bloques y espaciado personalizado. El trabajo para desarrolladores abarca Abilities API, extensibilidad de DataViews y comportamiento de REST API.
La nota también destaca la gestión de actualizaciones de traducción: los administradores pueden revisar actualizaciones disponibles de forma individual en la pantalla Updates e instalarlas selectivamente, de manera similar a plugins y temas. Las notas beta no garantizan que cada cambio sea definitivo o que todos los plugins sean compatibles. Consultar los tickets Trac y commits de Gutenberg enlazados y revisar posteriores notas de versión.
Probar un sitio representativo sin arriesgar producción
Usar una copia de staging o un entorno local aislado, con una copia de seguridad reciente y un proceso de restauración comprobado. Anotar las versiones de WordPress, PHP, base de datos, tema y plugins y probar los flujos reales: edición y publicación, plantillas, formularios, contenido RTL si corresponde, traducciones, tareas programadas e integraciones. Si es relevante, probar tanto una instalación nueva como la actualización.
No conectar una beta a datos reales de clientes ni usarla en un sitio crítico. No instalarla en una copia de producción solo para ver el panel. Comunicar fallos reproducibles mediante los canales de pruebas y Trac de WordPress con detalles del entorno y volver a probar versiones beta o candidatas posteriores. Mantener el sitio público en una versión estable compatible hasta disponer de la versión final y completar las pruebas.
Qué deben vigilar los equipos antes de diciembre
El anuncio de Beta 4 ofrece una instantánea útil, no un contrato final de funciones. Los autores de temas y plugins deben seguir las API pertinentes; los responsables de sitios pueden identificar bloques personalizados, flujos de traducción y necesidades de accesibilidad administrativa para probar. Revisar el calendario al acercarse diciembre, ya que fechas y alcance pueden cambiar.
La guía anterior resume el ciclo 7.2 más amplio. La distinción operativa es sencilla: las betas ayudan a encontrar problemas y los sitios productivos necesitan versiones estables y un plan de recuperación probado. No actualizar un sitio activo a Beta 4.
Fuentes y lecturas adicionales
¿Quieres señalar un error factual o sugerir una fuente? Contactar con la redacción.
