cache.lat
WordPress 7.2 ya tiene calendario propuesto: según la convocatoria de voluntarios publicada en make.wordpress.org, la Beta 1 llegaría entre el 20 y el 22 de octubre y la versión final entre el 8 y el 10 de diciembre de 2026. Es un cronograma flexible, pero alcanza para organizarse. Si tu sitio vive de la velocidad, conviene preparar el terreno ahora y no el día del lanzamiento.
El calendario propuesto, en limpio
- Beta 1: 20-22 de octubre
- Beta 2: 27-29 de octubre
- Beta 3: 3-5 de noviembre
- Beta 4: 10-12 de noviembre
- Release Candidate 1, 2 y 3: del 17 de noviembre al 3 de diciembre
- Versión final: 8-10 de diciembre
Son fechas propuestas, así que verificá siempre el calendario vigente antes de actuar. Lo importante: tenés unas siete semanas entre la primera beta y la versión estable. Es tiempo de sobra para probar con calma.
Por qué importa si usás caché de página
Cada versión mayor de WordPress puede tocar cosas que afectan a un sitio cacheado: cambios en el editor de bloques, en la forma en que el tema genera estilos, en scripts que se cargan en el front o en cabeceras. Una caché que sirve HTML estático es muy rápida justamente porque no ejecuta PHP en cada visita; por eso, si algo cambia en cómo se genera la página, el archivo estático guardado sigue mostrando la versión anterior hasta que se regenere.
Si querés entender ese mecanismo, está explicado en cómo funciona cache.lat.
Plan de preparación en cinco pasos
1. Armá un entorno de pruebas (staging)
Clonar el sitio a un subdominio o a un entorno de staging es lo más seguro. Nunca pruebes una beta en producción. Las betas existen para que la comunidad encuentre fallos, y esos fallos pueden ser tuyos si tu sitio es el conejillo de indias.
2. Probá la beta con tu combinación real de tema y plugins
Lo que importa no es WordPress solo, sino tu tema, tu constructor visual, tu plugin de formularios, tu tienda. Revisá especialmente:
- La página de inicio y las páginas que más tráfico reciben.
- Formularios, carrito y checkout si tenés comercio electrónico.
- Menús, buscador y contenido dinámico.
- El panel de administración y el editor de bloques con tus plantillas habituales.
3. Revisá los avisos de compatibilidad de tus plugins
Antes de actualizar, mirá si los autores de tus plugins críticos declaran compatibilidad con la nueva versión. Un plugin abandonado es el principal riesgo de cualquier actualización mayor. Si alguno no se actualiza hace meses, es buen momento de buscar alternativa.
4. Chequeá la versión de PHP del hosting
Una actualización de WordPress es una buena excusa para revisar PHP. Verificá en el panel de tu hosting qué versión corrés y qué requisitos mínimos declara la versión nueva de WordPress. Si estás en una rama de PHP que ya no recibe soporte, planificá la migración con tiempo y probala también en staging. Los datos técnicos de lo que necesita el plugin los tenés en datos técnicos de cache.lat.
5. Definí cómo vas a purgar la caché tras actualizar
El día que actualices a la versión final, el procedimiento sensato es: backup, actualizar core, actualizar plugins y tema, y recién después regenerar las páginas cacheadas y navegar el sitio en una ventana privada para confirmar que lo que se sirve es lo nuevo. Si no purgás, podés quedarte mirando HTML viejo y creer que "la actualización no hizo nada", o peor, mezclar HTML antiguo con recursos nuevos. La documentación de cache.lat explica cómo manejar la regeneración.
Qué NO hacer
- No actualices el mismo día del lanzamiento un sitio que factura. Esperá a la primera versión de mantenimiento si el negocio depende del sitio.
- No desactives la caché "para que no moleste" durante la actualización y la olvides así. Es un error común que termina en un sitio lento durante semanas.
- No pruebes solo logueado como administrador: el visitante anónimo es quien recibe la versión cacheada, así que probá también sin sesión.
Una nota sobre las betas
Las versiones beta y release candidate son para pruebas, no para producción. Si tenés conocimientos técnicos, reportar un fallo encontrado en staging ayuda a toda la comunidad, y el equipo de WordPress.org busca voluntarios para pruebas en cada ciclo, como se ve en la propia convocatoria enlazada arriba.
Resumen práctico
- Anotá octubre-diciembre en el calendario y verificá las fechas oficiales.
- Clonar a staging y probar con tu combinación real de plugins.
- Revisar PHP y compatibilidad de plugins antes del lanzamiento final.
- Tener listo el procedimiento de purga/regeneración de caché.
- Probar siempre como visitante anónimo.
Si tenés dudas sobre cómo encaja la caché estática en tu sitio, podés consultar los planes de cache.lat o escribir al equipo de TuNegocioEnLinea.net.