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.
En 30 segundos
- Con el lanzamiento de WordPress 7.1, el core cambió los IDs de los callbacks de hooks de strings a integers y rompió sitios con WP Rocket + Elementor Pro.
- WP Rocket sacó un parche, aunque antes había pedido no actualizar a 7.1.
- Matt Mullenweg tuiteó «¿Te explotó el cohete? Conseguite un Jetpack» y la cuenta oficial de WordPress sumó críticas al día siguiente.
- WP Rocket estaba avisado desde hacía 44 días, según la propia cuenta de WordPress citando el reporte previo al lanzamiento.
- Core committers independientes propusieron tests automáticos con 200 plugins, con milestone para WordPress 7.2.
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.
¿Qué pasó con WP Rocket y WordPress 7.1?
Cuando salió WordPress 7.1, los primeros reportes de sitios caídos con error fatal de PHP no tardaron en llegar. El denominador común era WP Rocket activo. El plugin llegó a recomendar no actualizar hasta aplicar el parche, según su aviso oficial, y recién después publicó la solución.
Ponele que actualizás un miércoles a la mañana: el sitio arranca, las métricas dan normal, y a media tarde tenés clientes escribiendo porque el checkout tira un fatal que nadie vio venir, todo porque tres piezas de software que funcionaban bien por separado decidieron no entenderse entre sí, el hosting no tenía forma de saberlo y vos tampoco. Así de simple y así de feo. Ya lo cubrimos antes en la dinámica interna de la comunidad WordPress.
A mediados de agosto de 2026, Mullenweg publicó en X: «¿Te explotó el cohete? Conseguite un Jetpack» (spoiler: la comunidad no se lo tragó). Al día siguiente, la cuenta oficial citó el aviso de WP Rocket donde pedía no actualizar y remató: «Ay, decirle a la gente que no actualice… esto no fue un bug de 7.1. Quizás reconsiderá tu uso de WP Rocket». Después vino un hilo completo: el aviso con 44 días de anticipación, un desvío hacia una cuenta de GitHub que usaba la marca WordPress, y el recordatorio de que apenas un par de empresas tienen licencia de la marca, así que mejor «estar alerta y desconfiar» del resto. ¿Y quién controla esa cuenta? Mullenweg. Un solo altavoz, dos cuentas.
¿Cuál es la causa técnica del error fatal?
Todo nació de un cambio interno silencioso: WordPress 7.1 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ó en esa trampa, y PHP respondió con un error fatal. Traducido: le pediste texto a PHP y le diste un número.
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. Ojo con esto: si mantenés un plugin que toca hooks, revisá cómo manejás esos IDs antes de que 7.1.1 te agarre dormido.
¿Quién está afectado por el error fatal de WP Rocket?
No todos los sitios con WP Rocket se cayeron, y acá está la clave del caso. Austin Ginder, fundador de Anchor Hosting, fue el primero en reportar los fatals y su diagnóstico complicó la narrativa oficial: «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». Lo explicamos a fondo en nuestra guía para crear una landing page en WordPress.
Esa tercera variable explica por qué muchos sitios actualizaron sin drama mientras otros amanecieron rotos. Si tu stack era WP Rocket + Elementor Pro sobre 7.1, comiste el error. Si no usabas Elementor, probablemente ni te enteraste (por eso el incidente les pareció catástrofe global a unos y tormenta en un vaso de agua a otros).
¿Cómo solucionar el error fatal de WP Rocket tras actualizar a WordPress 7.1?
La solución definitiva es actualizar WP Rocket a la última versión disponible. 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.
¿Por qué no se detectó el bug antes del lanzamiento?
Porque recibir un aviso y corregir son cosas distintas. Según The Repository, WP Rocket había sido informado del problema 44 días antes del lanzamiento de 7.1. Aun así, el parche del plugin salió después del release del core, no antes.
La lección aplica para los dos lados. Para WP Media: un aviso de 44 días exige un test de regresión sobre las betas, no una lectura distraída del changelog. Para el resto de los developers: si tu código asume tipos en los callbacks de hooks, 7.1 te puede pasar factura igual, tengas o no un logo conocido.
¿Es seguro actualizar a WordPress 7.1 hoy?
Sí, siempre que WP Rocket esté actualizado a la versión corregida antes de tocar el core. ¿Y si ya actualizaste y todo funciona? Entonces no toques nada. Para el resto, este incidente dejó un manual que conviene adoptar ya: Tema relacionado: probar cada actualización en un staging.
- 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 7.1.
- Activá notificaciones para los plugins de los que depende tu ingreso: enterarte del parche tres días tarde sale caro.
Lo interesante es que el incidente ya movió algo en el core: los committers independientes Adam Silverstein y Aaron Jorbin impulsaron una propuesta de tests automáticos de compatibilidad. Silverstein corrió una batería de 200 plugins contra su fork y encontró un fatal real en eps-301-redirects (bug preexistente del plugin, no del core); Jorbin sugirió corridas mensuales. El ticket quedó con milestone para WordPress 7.2. Tarde para los que se cayeron, útil para la próxima vez.
¿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.
Preguntas Frecuentes
¿WP Rocket ya lanzó una actualización compatible con WordPress 7.1?
Sí. WP Rocket publicó una versión corregida después del incidente. Actualizá el plugin, vaciá la caché y confirmá en Plugins que estás en la última versión.
¿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ó.
¿A cuántos sitios afectó el error fatal?
No existe una cifra oficial consolidada. Los reportes conocidos vienen de hosts como Anchor Hosting y de foros de soporte, y el fallo exigía la combinación de WP Rocket con Elementor Pro u otro plugin similar, por lo que muchos sitios actualizaron sin problemas.
¿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.
¿WP Rocket pidió disculpas o publicó un comunicado?
Publicó un aviso oficial en su documentación con los pasos de recuperación y anunció un post-mortem para esta misma semana, donde explicará qué falló y qué va a cambiar en su proceso de testing de compatibilidad.
Conclusión
El incidente deja tres cosas claras. El error fatal de WP Rocket con WordPress 7.1 ya tiene solución concreta, la versión corregida del plugin, y aplicarla toma minutos si seguís el orden correcto. La tensión entre el core y los plugins comerciales sigue creciendo, y esta vez la cuenta oficial eligió el palo en lugar del puente, con el costo reputacional a la vista. Y nadie tradujo los 44 días de aviso en un parche previo al lanzamiento, que es justo para lo que sirven las alertas tempranas.
Qué hacer hoy: verificá que WP Rocket esté actualizado a la versión corregida, 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.
