WordPress 7.1.1 ya tiene un cronograma público, pero todavía no cuenta con una lista final de correcciones cerrada. La versión de mantenimiento se programó después del lanzamiento de WordPress 7.1 el 19 de agosto de 2026, y el plan publicado por el equipo de Core el 2 de septiembre sitúa la primera Release Candidate (RC1) el 10 de septiembre y la versión general el 17 de septiembre.
Para quienes administran sitios en producción, la lectura más útil es esta: el 10 de septiembre es un hito para probar; el 17 de septiembre es el hito previsto para actualizar la versión estable. Hasta entonces, el conjunto de tickets todavía puede cambiar y el propio cronograma advierte que los horarios exactos son estimaciones, según la publicación oficial del calendario de WordPress 7.1.1.
Cronograma oficial de WordPress 7.1.1 hasta el 17 de septiembre
El calendario publicado por Make WordPress Core incluye sesiones de revisión de bugs antes y después de la RC1. La tabla siguiente convierte los horarios a la hora de Brasilia (UTC-3) y conserva también la hora oficial en UTC.
| Fecha | Evento | UTC | Hora de Brasilia |
|---|---|---|---|
| 3/9 | Bug scrub | 14:00 | 11:00 |
| 4/9 | Bug scrub | 14:00 | 11:00 |
| 8/9 | Bug scrub; apertura del milestone 7.1.2 y posible traslado de tickets | 20:00 | 17:00 |
| 9/9 | Bug scrub | 10:00 | 07:00 |
| 10/9 | WordPress 7.1.1 RC1 | 17:30 | 14:30 |
| 15/9 | Bug scrub | 14:00 | 11:00 |
| 17/9 | Lanzamiento general de WordPress 7.1.1 | 15:00 | 12:00 |
Hay dos salvedades importantes. Primero, la publicación oficial dice que los horarios son estimaciones y dependen de la disponibilidad de las personas que participan en el lanzamiento. Segundo, el 8 de septiembre está previsto abrir el milestone de WordPress 7.1.2 y algunos tickets pueden trasladarse allí. Por eso, una corrección que esté en discusión ahora no debe considerarse confirmada para 7.1.1 hasta que quede cerrada la composición final de la versión.
Qué ya está confirmado sobre 7.1.1
El alcance declarado es una versión de mantenimiento dedicada a corregir bugs. El equipo de Core indica que los tickets pueden entrar en 7.1.1 cuando tratan problemas introducidos durante el ciclo de WordPress 7.1 o elementos que se aplazaron intencionalmente al final de ese ciclo.
Esto también define lo que no conviene prometer antes de las notas oficiales: todavía no hay base para anunciar una lista final de correcciones, mejoras de rendimiento específicas, cambios de funcionalidades o una corrección de seguridad solo porque un ticket esté en discusión. El conjunto definitivo debe comprobarse cuando se publique la RC1 y, después, la versión estable.
Qué significa en la práctica la RC1 del 10 de septiembre
RC significa Release Candidate: una compilación candidata a convertirse en la versión pública si no aparecen problemas importantes. El handbook del ciclo de lanzamientos de WordPress describe esta fase como una etapa centrada en regresiones y estabilización. El mismo handbook contempla más de una RC cuando los bugs detectados necesitan corregirse antes del lanzamiento.
Para quien administra un sitio, eso no convierte la RC1 en una actualización de producción. En los anuncios de RC, el propio WordPress recomienda probar versiones previas al lanzamiento en un servidor o sitio de pruebas, no en instalaciones de producción o críticas. El objetivo de la RC1 es validar la compilación en entornos realistas sin exponer innecesariamente el sitio activo.
Quién debería probar la RC1 y quién puede esperar
| Perfil del sitio | Conducta más prudente | Qué validar |
|---|---|---|
| Desarrollador de plugin, tema o integración | Probar la RC1 en cuanto estén disponibles el paquete y las instrucciones oficiales | Compatibilidad, avisos PHP, editor, APIs y flujos propios del producto |
| Agencia con muchos sitios en WordPress 7.1 | Usar un staging representativo antes del 17/9 | Stacks recurrentes, plugins comunes, caché, formularios, autenticación y despliegue |
| WooCommerce, membership, LMS o sitio con flujos críticos | Probar en un clon de staging; evitar la RC en producción | Checkout, login, webhooks, tareas programadas, correos, pagos e integraciones |
| Sitio institucional simple y estable | Puede esperar la versión final del 17/9 | Backup, editor, formularios, caché y páginas principales después de actualizar |
| Sitio sin staging ni equipo técnico | Esperar la versión estable y revisar la estrategia de copias de seguridad | Capacidad de restauración antes de actualizar |
Esta división es una recomendación de gestión de riesgo, no una regla del proyecto WordPress. Cuantos más ingresos, autenticación, automatización o integraciones externas dependan del sitio, más valor tiene reproducir el entorno real en staging antes de permitir la actualización en producción.
Checklist de staging antes de actualizar producción
- Crea una copia de seguridad restaurable de archivos y base de datos antes de cualquier actualización relevante. La documentación oficial de actualización de WordPress recomienda el backup como paso inicial.
- Usa un clon representativo con tema, plugins, versión de PHP y configuraciones similares a producción.
- Registra el estado inicial: WordPress, plugins, tema, PHP, caché e integraciones. Esto facilita aislar lo que cambió.
- Prueba wp-admin y el editor: creación y edición de páginas y entradas, medios, patrones, navegación y permisos utilizados por el equipo.
- Prueba los flujos que sostienen el negocio: formularios, login, checkout, suscripciones, áreas de miembros, LMS, búsqueda interna o integraciones por API.
- Revisa logs y errores: errores PHP, fallos JavaScript, tareas programadas y comportamiento de caché pueden revelar incompatibilidades que una navegación superficial no muestra.
- Define el rollback: saber restaurar una copia es tan importante como disponer del archivo de backup.
Para probar versiones previas al lanzamiento, la guía de Beta Testing de WordPress documenta el plugin WordPress Beta Tester y los canales Beta/RC. Cuando se publique WordPress 7.1.1 RC1, conviene seguir las instrucciones específicas de esa compilación, porque el anuncio puede detallar un método o un foco de pruebas concreto.
¿Conviene esperar hasta el 17 de septiembre para actualizar?
Para la mayoría de los sitios que solo necesitan software estable, sí: esperar el lanzamiento general previsto para el 17 de septiembre evita poner una RC en producción. Los sitios más complejos pueden aprovechar la ventana del 10 al 17 de septiembre para validar la candidata en staging y preparar un plan de actualización.
También conviene comprobar cómo recibe el sitio las actualizaciones automáticas. La documentación de actualización de WordPress explica que las actualizaciones menores del Core, incluidas las versiones de mantenimiento y seguridad, están habilitadas automáticamente por defecto en muchos escenarios, aunque constantes, filtros, decisiones del administrador, detección de control de versiones y políticas del hosting pueden modificar ese comportamiento. En entornos administrados, confirma además si el proveedor aplica actualizaciones en una ventana propia.
Qué todavía puede cambiar antes del lanzamiento
Tres elementos siguen abiertos hasta la publicación final: el conjunto de tickets, porque algunos pueden pasar a 7.1.2; la necesidad de una RC adicional, si las pruebas encuentran problemas que requieran otra candidata; y el horario exacto de los hitos, que el cronograma clasifica como estimaciones.
Las fechas objetivo del 10 de septiembre para la RC1 y del 17 de septiembre para la versión general, en cambio, son el plan oficial vigente el 4 de septiembre de 2026. Si el cronograma cambia, la referencia primaria continúa siendo Make WordPress Core.
Cómo seguir el lanzamiento sin confundir propuestas con correcciones confirmadas
Usa la publicación del cronograma como punto de partida y sigue los enlaces de tickets y tareas del editor indicados por el equipo de Core. Antes de la RC1, trata los tickets como candidatos. Después de la RC1, comprueba el paquete y las notas de esa compilación. Para producción, la decisión final debe combinar las notas de la versión estable, tus resultados en staging y una vía realista de rollback.
En resumen: marca el 10 de septiembre como fecha para probar y el 17 de septiembre como fecha prevista para actualizar la versión estable. Quienes mantienen plugins, temas, tiendas, portales con autenticación o sitios con integraciones críticas tienen más que ganar probando la RC1 en staging; quienes administran un sitio simple y estable pueden esperar la versión general, preparar una copia de seguridad y validar después los flujos esenciales antes de completar la actualización.
