Error fatal WP Rocket WordPress 7.1: la polémica

Actualizado el 29/08/2026: WP Rocket publicó el post-mortem oficial del error fatal con WordPress 7.1 y estimó que el 10% de los sitios que usan el plugin fueron afectados. El informe detalla la causa técnica, reconoce la responsabilidad del equipo y anuncia cambios concretos en su proceso de testing.

En pocas palabras: La cuenta oficial de WordPress en X se ganó el rechazo de la comunidad por aprovechar el error fatal que WP Rocket provocó en sitios con WordPress 7.1 y Elementor Pro para promocionar Jetpack. Matt Mullenweg tuiteó primero y la cuenta oficial remató al día siguiente.

La cuenta oficial de WordPress en X quedó en el centro de la tormenta después de usar el error fatal que WP Rocket provocó en sitios con WordPress 7.1 para promocionar Jetpack y cuestionar al plugin de caché. Mullenweg abrió el fuego con su tuit, la cuenta oficial remató al día siguiente, y el escrache de la comunidad no tardó en llegar.

Para ubicarnos: el error fatal de WP Rocket con WordPress 7.1 es un fallo de compatibilidad que estalló a mediados de agosto de 2026, cuando un cambio interno del core en los callbacks de hooks rompió sitios que combinaban WP Rocket con Elementor Pro. WP Rocket publicó una corrección, pero el episodio terminó en una pelea pública entre la cuenta de X de WordPress (que controla Matt Mullenweg) y el plugin de caché premium.

WP Rocket es un plugin premium de caché y optimización para WordPress, desarrollado por WP Media, que se distribuye fuera del directorio oficial de plugins. WordPress 7.1 es la versión mayor más reciente del CMS.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto desarrollado por la comunidad WordPress, diseñado para crear y administrar sitios web y blogs.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto creado en 2003 por Matt Mullenweg y Mike Little, y desarrollado a agosto de 2026 por una comunidad global bajo la supervisión de la Fundación WordPress. Se utiliza para crear sitios web, blogs y tiendas en línea.

¿Por qué se rompió WP Rocket con WordPress 7.1?

WordPress 7.1 introdujo un cambio interno silencioso que rompió la retrocompatibilidad: pasó a identificar los callbacks de hooks con integers en lugar de strings. Cualquier código que asumiera que ese ID era texto y lo pasara a funciones de cadena se rompía. La implementación de WP Rocket cayó justo en esa trampa, y PHP respondió con un error fatal. Traducido: le pediste texto a PHP y le diste un número. Tema relacionado: nuestra guía completa sobre wp community.

El bug no se disparaba con solo tener WP Rocket activo. Necesitaba una tercera variable en la mezcla. Según el análisis del incidente, la combinación con Elementor Pro —u otro plugin que interactuara con los mismos hooks— era lo que gatillaba el fatal. Sin esa tercera pata, WP Rocket y WordPress 7.1 convivían sin problemas. Por eso hubo sitios que actualizaron sin enterarse y otros que amanecieron con pantalla blanca.

David Levine, Director de Growth Engineering en rtCamp, señaló que había una ruptura de retrocompatibilidad del core con ticket propio, abierto por el core committer Weston Ruter y con arreglo programado para 7.1.1. Aki Hamano, co-tech lead de 7.1, reconoció en Slack que el origen estaba en la implementación de WP Rocket, pero que era un punto que valía la pena tener en cuenta.

¿Cuántos sitios afectó realmente el error fatal?

El post-mortem que WP Rocket publicó el 28 de agosto de 2026 da una cifra concreta por primera vez: se estima que el 10% de los sitios que usaban el plugin fueron afectados por el error fatal, según reportó The Repository. No existe una cifra oficial consolidada más allá de esta estimación interna.

El número tiene sentido con lo que ya se sabía: el fallo exigía la combinación de WP Rocket con Elementor Pro u otro plugin similar. No todos los sitios usan Elementor. De hecho, Austin Ginder, fundador de Anchor Hosting, fue el primero en reportar los fatals y su diagnóstico ya anticipaba esta lógica: «Esto no fue un fallo de testing de WP Rocket. El bug estaba bien escondido. WP Rocket + WordPress 7.1 funcionaba bien. Agregá una tercera variable a la mezcla, como Elementor Pro, y PHP fatal».

Eso sí, un 10% sobre una base de usuarios grande es un número considerable. WP Rocket tiene cientos de miles de instalaciones activas. No es un plugin de nicho. Que uno de cada diez sitios se cayera después de una actualización del core explica por qué el incidente se sintió como catástrofe global para unos y tormenta en un vaso de agua para otros.

¿Cómo recuperar un sitio tras el error fatal de WP Rocket?

La solución definitiva es actualizar WP Rocket a la versión 3.23.2.2 o superior. Antes de tocar cualquier cosa, hacé backup de archivos y base de datos; si tu hosting no te da herramientas para eso, es buen momento para evaluar un hosting WordPress que sí las incluya. Los caminos según tu situación:

• Si podés entrar al admin de WordPress: andá a Plugins, actualizá WP Rocket a la última versión, vaciá la caché y verificá que el sitio responda bien.
• Si tenés pantalla blanca o error crítico: entrá por FTP o al file manager de tu hosting y renombrá la carpeta /wp-content/plugins/wp-rocket/ a wp-rocket-off. Con el plugin desactivado el sitio vuelve a levantar; actualizá WP Rocket desde el admin y devolvéle el nombre original a la carpeta.
• Si nada de lo anterior funciona: WP Rocket publica un plugin de recuperación (WP Rocket Update Recovery) pensado justo para estos casos; instalalo y seguí sus pasos hasta dejar la versión corregida en marcha.

Nunca borres la carpeta del plugin para «resolver rápido»: perdés la configuración y la licencia asociada. Renombrar desactiva sin destruir nada. El parche v3.23.2.2 también corrige un error de comunicación con Cloudflare que se reportó en paralelo, según detalló Sombraradio.

¿Quién tuvo la culpa: WordPress, WP Rocket o Elementor?

El cambio de core en WordPress 7.1 rompió la retrocompatibilidad, y eso es un hecho. El ticket de Weston Ruter lo reconoce y el arreglo viene en 7.1.1. Pero WP Rocket recibió el aviso 44 días antes del lanzamiento y no llegó con el parche a tiempo. La cuenta de WordPress en X se lo refregó en la cara con un hilo completo durante la crisis.

El tema es que el aviso temprano no se tradujo en un parche previo al release. WP Rocket reconoció en su post-mortem que hubo una falla en su proceso de testing de compatibilidad. No es que ignoraron el reporte, pero sus pruebas no cubrieron el caso específico de la tercera variable (Elementor Pro) interactuando con el cambio de callbacks.

Del lado del core, los committers independientes Adam Silverstein y Aaron Jorbin ya impulsaron una propuesta de tests automáticos con 200 plugins para detectar este tipo de roturas antes de un release. El ticket quedó con milestone para WordPress 7.2. Tarde para los que se cayeron, útil para la próxima. Más contexto en cómo crear una landing page en wordpress.

¿Qué aprendió WP Rocket y qué cambió tras el incidente?

El 28 de agosto de 2026, WP Rocket publicó el post-mortem que había prometido. El documento es extenso y no se anda con vueltas: reconoce la responsabilidad del equipo, detalla la secuencia de eventos y anuncia cambios concretos en su proceso de testing.

Según el informe, el error se originó en una función interna de WP Rocket que asumía que los identificadores de callbacks de WordPress eran siempre strings. Cuando WordPress 7.1 cambió ese comportamiento a integers, la función falló. Pero —y acá está el dato clave del post-mortem— la falla solo se manifestaba cuando un tercer plugin registraba hooks con prioridades específicas. Elementor Pro era el gatillo más común, pero no el único.

WP Rocket estimó que el 10% de sus sitios activos fueron afectados. El equipo de soporte atendió más de 3.000 tickets en las primeras 48 horas. La versión corregida (3.23.2.2) salió en menos de 24 horas desde la detección masiva del problema, pero el daño ya estaba hecho para los que actualizaron el core sin el parche.

Los cambios que WP Rocket prometió implementar

• Pruebas de compatibilidad ampliadas: van a incorporar tests automáticos que simulen combinaciones de WP Rocket con los plugins más usados (builders, ecommerce, formularios) sobre versiones beta del core.
• Monitoreo de cambios en el core: asignarán un equipo dedicado a revisar los changelogs de WordPress y los tickets de retrocompatibilidad durante el ciclo de desarrollo de cada release mayor.
• Respuesta temprana a reportes: el aviso de 44 días de anticipación existió, pero no escaló internamente como debía. WP Rocket ajustó su proceso de triage para que los reportes de compatibilidad con el core tengan prioridad máxima.
• Comunicación con la comunidad: admitieron que el aviso de «no actualizar» llegó tarde y que la comunicación de crisis fue reactiva. Van a publicar alertas de compatibilidad en redes y en el dashboard del plugin apenas detecten un riesgo.

Lo interesante es que el post-mortem no elude el bulto. WP Rocket puso el foco en su propio proceso y evitó señalar al core o a terceros. Un gesto que contrasta con el tono que usó la cuenta de WordPress en X durante el incidente.

¿Cómo evitar problemas similares con futuras actualizaciones de WordPress?

El incidente dejó un manual de supervivencia que conviene adoptar ya. No importa si usás WP Rocket u otro plugin: los cambios internos del core van a seguir ocurriendo, y la única defensa real es la prevención.

• Esperá una o dos semanas después de cada release mayor antes de actualizar producción. Que otros encuentren los bugs por vos.
• Probá en staging primero: cloná el sitio, actualizá ahí y recién entonces tocá el real. Es la diferencia entre un susto y una caída de ventas.
• Actualizá tus plugins críticos antes del core, sobre todo caché, SEO y builders, y revisá sus changelogs buscando menciones de compatibilidad con la nueva versión.
• Activá notificaciones para los plugins de los que depende tu ingreso: enterarte del parche tres días tarde sale caro.
• Hacé backup completo antes de cualquier actualización mayor. Si tu hosting no ofrece backups automáticos, considerá un proveedor que sí lo haga.

El incidente ya movió algo en el core: los tests automáticos con 200 plugins propuestos por Silverstein y Jorbin apuntan a WordPress 7.2. La lección para developers es clara: si tu código asume tipos en los callbacks de hooks, revisalo antes de que 7.1.1 te agarre dormido. En el uso de un staging en wordpress profundizamos sobre esto.

¿Qué está confirmado y qué todavía no está confirmado?

Confirmado	Pendiente
WP Rocket estima que el 10% de sus sitios fueron afectados por el error fatal, según su post-mortem del 28/08/2026.	No hay una auditoría externa que valide la cifra del 10%. Es un dato interno de WP Media.
El bug requería la combinación de WordPress 7.1 + WP Rocket + un tercer plugin (Elementor Pro u otro similar).	No se sabe cuántos otros plugins de caché o rendimiento podrían tener problemas similares con futuros cambios del core.
WP Rocket ya lanzó el parche (v3.23.2.2) que corrige el error de callbacks y el problema de integración con Cloudflare.	WordPress 7.1.1 promete un ajuste de retrocompatibilidad, pero no tiene fecha confirmada de lanzamiento.
WP Rocket anunció cambios en su proceso de testing: pruebas automáticas con plugins populares y monitoreo dedicado del core.	No está claro cuándo se implementarán estos cambios ni si serán suficientes para evitar otro incidente similar.
Los core committers propusieron tests automáticos con 200 plugins para WordPress 7.2.	La propuesta tiene milestone para 7.2, pero no está garantizada su implementación final.

¿Cuáles son las alternativas a WP Rocket para caché en WordPress?

Existen varias, algunas gratis. Pero seamos honestos: migrar de plugin de caché en plena crisis suele ser una reacción exagerada, porque implica reconfigurar reglas, purgar CDNs y volver a medir todo. Si tu licencia está vigente, actualizar es más simple. Dicho esto, estas son las opciones con sentido según tu setup:

Plugin	Licencia	Cuándo conviene
LiteSpeed Cache	Gratis	Solo si tu hosting corre LiteSpeed; preguntale a tu proveedor
Autoptimize	Gratis	Optimización de CSS/JS; combina bien con la caché del servidor
Breeze	Gratis	Setups simples que quieren algo liviano sin configuración fina
FlyingPress	Pago	Performance avanzada si buscás un reemplazo directo de WP Rocket
Jetpack Boost	Freemium	Si ya pagás Jetpack; fue la alternativa que Automattic empujó durante el incidente

Dato duro: Devin Walker, Artistic Director de Jetpack, publicó durante la semana una comparativa destacando los tiempos de respuesta de WP Rocket y promoviendo Jetpack Boost con instrucciones de migración incluidas. Tomalo con pinzas: es parte interesada, y su empresa es la misma que maneja la cuenta que inició la polémica.

¿Por qué la comunidad criticó a Matt Mullenweg y a la cuenta de WordPress?

Porque el tono recordó demasiado a 2024. Cuando la cuenta oficial citó el aviso de WP Rocket para afirmar que el problema «no fue un bug de 7.1», varios recordaron la racha de fines de 2024: seguidores bloqueados y respuestas despectivas como el ya famoso «Sorry, who are you?» («Perdón, ¿vos quién sos?»). La sensación de déjà vu fue generalizada. Para más detalles técnicos, mirá revisar si tenés enlaces rotos.

Las respuestas llegaron de todo el mapa. El consultor SEO Sören Lindhoff escribió que Mullenweg y su «fiesta de payasos» están matando la reputación que le queda a WordPress. El developer Paul Michael dijo que no le parecía una forma apropiada de interactuar con la comunidad y que pensaba que habían aprendido de la backlash anterior (al parecer, no). Scott Buscemi, Product Manager en Cloudflare, preguntó cómo se supone que se distribuyan plugins premium si no es fuera del directorio oficial; la cuenta le respondió con otra pregunta, y el developer Dave Loodts remató señalando que el proyecto nunca construyó un mecanismo serio de distribución comercial pese a años de pedidos.

En el Slack de Post Status, Joost de Valk (cofundador de Emilia Capital) preguntó cómo ayudaba al ecosistema amplificar una historia sobre fatals en plena batalla contra las soluciones SaaS, y Bowe Frankema (Dollie) se preguntó qué otra plataforma sale de «cruzada» contra las entidades comerciales más grandes de su propio ecosistema. Hubo defensas también: Kelley Muro, fundadora de North Commerce, dijo no discrepar con que Matt haga un ejemplo del caso. Y los hechos complicaron el relato oficial por su lado: el cambio de hooks era una ruptura de retrocompatibilidad reconocida por el propio core team, y el fatal necesitaba tres variables, no dos.

Errores comunes al manejar un error fatal de compatibilidad

• Buscar un único culpable. El fatal necesitó WordPress 7.1 + WP Rocket + Elementor Pro. Diagnosticá combinaciones, no piezas aisladas, o vas a «arreglar» algo que no estaba roto.
• Borrar en vez de renombrar. Con el sitio en blanco, la tentación de eliminar la carpeta del plugin es enorme; renombrar logra lo mismo sin perder configuración ni licencia.
• Actualizar todo el mismo día en producción. Core, theme y plugins juntos el día del release es la receta clásica del domingo con el teléfono al rojo vivo.
• Asumir que «a mí no me va a pasar». El 10% de los sitios de WP Rocket se cayó. No es un número marginal. Cualquier stack que combine tres o más plugins críticos está expuesto a este tipo de fallos en cadena.

Preguntas Frecuentes

¿Qué reveló el post-mortem de WP Rocket sobre el error fatal?

El informe confirmó que el error se originó en una función interna que asumía que los callbacks de hooks eran strings. Al cambiar WordPress 7.1 a integers, la función fallaba si un tercer plugin (como Elementor Pro) registraba hooks con prioridades específicas. WP Rocket estimó que el 10% de sus sitios activos fueron afectados y atendió más de 3.000 tickets en 48 horas.

¿WP Rocket ya lanzó una actualización compatible con WordPress 7.1?

Sí. WP Rocket publicó la versión 3.23.2.2, que corrige tanto el error de callbacks como un problema de integración con Cloudflare que se reportó en paralelo. Actualizá el plugin, vaciá la caché y confirmá en Plugins que estás en la última versión. Sobre eso hablamos en cómo arreglar enlaces rotos.

¿Cuántos sitios afectó el error fatal de WP Rocket con WordPress 7.1?

Según el post-mortem de WP Rocket publicado el 28 de agosto de 2026, se estima que el 10% de los sitios que usaban el plugin fueron afectados. El fallo requería la combinación con Elementor Pro u otro plugin similar, por lo que muchos sitios actualizaron sin problemas.

¿Qué cambios prometió WP Rocket tras el incidente?

WP Rocket anunció que reforzará sus pruebas de compatibilidad con tests automáticos que simulen combinaciones con los plugins más usados sobre betas del core. También asignará un equipo dedicado a monitorear los cambios de WordPress durante cada ciclo de desarrollo y ajustó su proceso de triage para priorizar reportes de compatibilidad con el core.

¿Quién maneja la cuenta de X de WordPress?

Matt Mullenweg, CEO de Automattic, controla la cuenta oficial. Por eso sus posts personales y los de la cuenta se leyeron como una sola voz durante el incidente, algo que buena parte de la comunidad criticó.

¿Conviene cambiar de plugin de caché después de este incidente?

En la mayoría de los casos, no de forma apresurada. Si actualizaste a la versión corregida y tu sitio funciona, migrar implica reconfigurar y retestear todo. Evaluá alternativas con calma, en staging, y decidí por datos de rendimiento propios, no por un tuit.

Conclusión

El post-mortem de WP Rocket cierra varias incógnitas y deja otras abiertas. Lo confirmado: el error afectó al 10% de sus sitios, la causa fue un cambio en los callbacks de WordPress 7.1 que el plugin no testeó con terceras variables, y el equipo atendió más de 3.000 tickets en dos días. WP Rocket reconoció su responsabilidad sin desviar culpas y anunció cambios concretos en su proceso de testing.

Lo que sigue abierto: WordPress 7.1.1 todavía no tiene fecha, los tests automáticos con 200 plugins recién apuntan a la 7.2, y la tensión entre el core y los plugins comerciales no se va a resolver con un post-mortem. La cuenta oficial de WordPress sigue bajo el control de Mullenweg, y el tono del incidente dejó cicatrices en la comunidad.

Qué hacer hoy: verificá que WP Rocket esté actualizado a la versión 3.23.2.2 o superior, montá un staging si no tenés (si tu hosting no te lo facilita, mirá proveedores como el hosting WordPress de Donweb), y adoptá la regla de esperar una o dos semanas antes de actualizar producción ante cada release mayor. Cuando salga 7.1.1 con el ajuste de retrocompatibilidad, actualizá también. Y guardá este caso en la cabeza: la próxima vez que un changelog diga «cambio interno», leelo dos veces.

¿Cómo sé si mi sitio está afectado por el error de WP Rocket y WordPress 7.1?

Fijate si tenés Elementor Pro (u otro plugin que registre hooks similares) activo junto con WP Rocket y si actualizaste a WordPress 7.1 hace poco. Si además ves pantalla blanca o error crítico al entrar al sitio, entrás en el grupo del 10% de sitios que WP Rocket reportó como afectados en su post-mortem.

¿WP Rocket ya es compatible con WordPress 7.1?

Sí, desde la versión 3.23.2.2 WP Rocket es compatible con WordPress 7.1. Si todavía tenés una versión anterior instalada, actualizá cuanto antes: ese mismo parche también corrige el error de integración con Cloudflare que apareció en paralelo.

¿WordPress 7.1.1 ya solucionó el problema de raíz?

El ticket de retrocompatibilidad que abrió Weston Ruter tiene arreglo programado para WordPress 7.1.1, pero no reemplaza la solución inmediata. Mientras ese parche del core no salga de forma estable, lo que evita el error fatal es actualizar WP Rocket a la versión 3.23.2.2 o superior.

Fuentes

• WP Rocket Publishes WordPress 7.1 Fatal Error Post-Mortem, Estimates 10% of Sites Were Hit – The Repository
• Error fatal de WP Rocket con WordPress 7.1: causas, solución y antecedentes – Blog de Donweb
• WP Rocket alerta de un problema de compatibilidad con WordPress 7.1 – IguanaWP
• WP Rocket y WordPress 7.1: cómo solucionar el error fatal en la integración de Cloudflare – Sombraradio
• Fatal error on WordPress 7.1 – Documentación oficial de WP Rocket