WordPress 7.1 se publicó el 19 de agosto. Poco después, algunos sitios que utilizaban WP Rocket se encontraron con un error fatal.
El problema no se descubrió el día del lanzamiento. Ya había sido informado públicamente el 6 de julio, mientras WordPress 7.1 aún estaba en fase alfa.
El informe incluía pasos para reproducir el problema, identificaba el origen del error y proponía una solución de una sola línea. Después… pasaron más de seis semanas.
El plazo de 45 días
6 de julio de 2026
El error fatal se informó públicamente con pasos para reproducirlo, el origen del problema y una solución propuesta de una sola línea.
15 de julio de 2026
WordPress 7.1 Beta 1 se publicó, dando comienzo al periodo de pruebas beta públicas.
5 de agosto de 2026
WordPress 7.1 entró en la fase de pruebas de las versiones candidatas para lanzamiento. El problema de compatibilidad seguía sin resolverse.
19 de agosto de 2026
WordPress 7.1 se publicó. Los sitios con configuraciones afectadas de WP Rocket comenzaron a experimentar el error fatal.
20 de agosto de 2026
WP Rocket 3.23.2.2 publicó la solución, 45 días después del informe original.
Durante ese periodo, WordPress 7.1 pasó por cuatro versiones beta y cuatro candidatas para lanzamiento, según el calendario de lanzamientos. WP Rocket también publicó cuatro actualizaciones del plugin antes de que llegara la solución de compatibilidad.
Ese plazo plantea una pregunta razonable sobre qué deberían esperar los propietarios de sitios de WordPress de los plugins de los que dependen.
La compatibilidad forma parte del rendimiento
Los errores ocurren en todos los proyectos de software, incluido el nuestro. Los informes sobre una versión alfa pueden estar incompletos, limitarse a un entorno o verse afectados por cambios realizados antes del lanzamiento final. Los responsables de mantener los plugins tienen que investigarlos y priorizarlos con cuidado.
Este informe era inusualmente específico. Identificaba la función exacta que recibía el tipo de datos incorrecto, proporcionaba pasos para reproducir el error fatal e incluía una solución propuesta.
También hubo tiempo para probarlo. El ciclo de lanzamiento público de WordPress 7.1 incluía versiones beta a partir del 15 de julio y candidatas para lanzamiento a partir del 5 de agosto.
Los plugins de rendimiento funcionan en lo más profundo de WordPress. Cambian la forma en que se almacenan en caché las páginas, se cargan los scripts, se distribuye CSS y se sirven los recursos. Por eso el trabajo de compatibilidad es especialmente importante.
Un sitio más rápido no sirve de mucho si una actualización normal de WordPress puede dejarlo fuera de servicio.
No se trataba de una vulnerabilidad de seguridad divulgada. Era un fallo de compatibilidad que afectaba a la disponibilidad del sitio en determinadas configuraciones. La distinción es importante desde el punto de vista técnico, pero el resultado para el propietario de un sitio afectado seguía siendo grave.
Cómo gestiona Jetpack los informes de seguridad graves
El problema de WP Rocket no se informó como una vulnerabilidad de seguridad, por lo que no sería preciso compararlo directamente con un exploit. Nuestras políticas de seguridad siguen siendo un buen ejemplo del estándar que hemos establecido para gestionar informes graves.
Jetpack cuenta con una política pública de seguridad y participa con Automattic en el programa de recompensas por errores de HackerOne. Internamente, nuestro proceso abarca los informes recibidos a través de HackerOne, GitHub y nuestros propios equipos internos de Automattic.
- Clasificar el informe. Evaluamos si se puede explotar el problema, qué versiones están afectadas, cuántos sitios podrían estar expuestos y si WordPress.com está afectado.
- Involucra a los equipos adecuados. El equipo de Ingeniería de Jetpack coordina con el equipo de seguridad de Automattic, así como con soporte, comunicación, asuntos legales, proveedores de hosting o WordPress.org cuando la situación lo requiere.
- Adaptar el lanzamiento a la gravedad. Las vulnerabilidades críticas requieren una corrección urgente y backports para las versiones afectadas. Los problemas de gravedad alta reciben una versión menor. A los problemas de menor riesgo también se les asigna una ruta de lanzamiento clara.
- Revisar la solución. Los parches de seguridad reciben una revisión de seguridad. Las pruebas pueden acelerarse cuando el riesgo es urgente, pero no se omiten.
- Comunicar y aprender. Los incidentes graves tienen responsables claros de ingeniería, comunicación con los usuarios y soporte. Después, revisamos lo ocurrido y qué debería cambiar.
Ninguna política hace perfecto a un equipo de software. Sí deja claras las expectativas. Un informe creíble necesita un responsable, una decisión sobre su gravedad, una ruta de lanzamiento y un seguimiento adecuado.
Este es un buen momento para revisar la configuración de rendimiento
Las configuraciones de rendimiento de WordPress suelen crecer con el tiempo. Primero se añade un plugin de caché. Después llegan la optimización de imágenes, una CDN, la postergación de scripts, Critical CSS y otra herramienta para medir los resultados.
Con el tiempo, varios plugins pueden estar modificando las mismas partes de un sitio.
Si utilizas WP Rocket principalmente para la caché y la optimización del frontend, Jetpack Boost cubre muchas de esas mismas funciones:
- Caché de páginas
- CSS crítico CSS
- Postergar JavaScript no esencial
- Combinar y minimizar CSS y JavaScript
- Optimización de imágenes mediante la CDN global de Jetpack
- Puntuaciones de rendimiento integradas
Estas funciones se pueden activar de forma individual, lo que facilita entender qué hace cada cambio. La versión gratuita incluye caché de páginas, generación manual de CSS crítico CSS, aplazamiento de JavaScript, CDN de imágenes CDN, y concatenación de CSS y JavaScript.
¿No quieres todo lo que ofrece Jetpack? No hay problema. Jetpack Boost también es un plugin independiente. No necesitas instalar el plugin principal de Jetpack para utilizarlo.
Cómo cambiar de WP Rocket a Jetpack Boost
Antes de cambiar de plugin de rendimiento, haz una copia de seguridad de tu sitio o prueba el cambio en un sitio de pruebas.
Si tu sitio ya está afectado por el error fatal de WordPress 7.1, actualiza primero WP Rocket a la versión 3.23.2.2. Cuando el sitio vuelva a funcionar:
- Anota los resultados de rendimiento actuales para tener una referencia.
- Desactiva WP Rocket y vacía cualquier caché restante del servidor o de la CDN.
- Instala y activa Jetpack Boost.
- Activa los módulos de rendimiento de uno en uno.
- Prueba la página de inicio, las entradas, los formularios, la búsqueda, el inicio de sesión, el proceso de pago y otros flujos importantes después de cada cambio.
- Compara los resultados con tu referencia original.
Evita activar la misma optimización en varios plugins. Dos herramientas que intenten postergar el mismo JavaScript o gestionar la misma caché pueden crear nuevos problemas de compatibilidad.
Cada sitio de WordPress es diferente, así que mide el resultado en lugar de dar por hecho que todas las optimizaciones serán útiles.
Las actualizaciones de plugins requieren confianza
Los propietarios de sitios dependen de los equipos de plugins para seguir el desarrollo de WordPress, probar las próximas versiones e investigar informes creíbles de problemas de compatibilidad antes de que esas versiones lleguen a producción.
El problema de WP Rocket no tiene que ver con esperar que el software esté libre de errores. Tiene que ver con lo que ocurre después de que ya se ha informado de un problema grave y se conoce la solución propuesta.
Si este incidente te hace replantearte WP Rocket, Jetpack Boost te ofrece una forma práctica de simplificar la configuración de rendimiento sin renunciar a las optimizaciones que necesita tu sitio.
Jetpack 