WordPress 7.1 «Mary Lou»: qué cambió y qué se rompió

Actualizado el 27/08/2026: WP Rocket publicó el post-mortem técnico del error fatal de WordPress 7.1. El culpable no fue el plugin: un cambio en cómo el Core genera los IDs de los callbacks, combinado con PHP 8, tumbó sitios con WP Rocket, Elementor Pro y otros. Acá el detalle técnico, las cifras de impacto, la cronología hora por hora y cómo se parcheó.

En pocas palabras: el error fatal de WordPress 7.1 no fue un ataque ni culpa de un plugin puntual. Fue un bug de compatibilidad del Core: 7.1 cambió cómo genera los IDs de callbacks en ciertos hooks, y bajo PHP 8 con tipado estricto eso disparaba un error fatal. WP Rocket lo detalló en su post-mortem y sacó el hotfix 3.23.2.2 el mismo día.

WordPress 7.1 «Mary Lou» salió el 19 de agosto de 2026 con más de 1.500 mejoras, pero su presentación en WordCamp US fue un papelón de coordinación: se publicó antes de tiempo, empezó a descargarse sin anuncio oficial en el escenario y rompió WP Rocket en miles de sitios. Ahora tenemos la otra mitad de la historia: por qué, técnicamente, se cayeron esos sitios.

El post-mortem que publicó WP Rocket separa las dos cosas que quedaron mezcladas en el ruido del lanzamiento. Una es el descontrol del «show» en Phoenix. La otra —la que importa si administrás sitios— es el error fatal en sí: qué lo causó, a cuántos afectó y cómo se resolvió.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto, desarrollado inicialmente por Matt Mullenweg y Mike Little, que permite crear y administrar sitios web y blogs.

WordPress es un software de gestión de contenidos de código abierto que permite crear y administrar sitios web, blogs y tiendas en línea. Fue desarrollado por Automattic y lanzado en 2003.

¿Qué pasó exactamente en el apagón de WordPress 7.1?

El apagón fue un error de compatibilidad, no un ataque de seguridad. El 20 de agosto de 2026, apenas los sitios pasaron a WordPress 7.1, una parte de ellos quedó con la pantalla en blanco: frontend caído y, en muchos casos, dashboard inaccesible. No había forma de deshacerlo desde el propio WordPress, porque el error fatal se disparaba antes de que cargara el panel.

Ese es el punto que asustó a los administradores. Un plugin que falla en una pantalla se desactiva y listo. Acá el sitio entero se caía, y el camino de recuperación pasaba por FTP o por el gestor de archivos del hosting, no por el botón de «desactivar plugin». Austin Ginder, de Anchor Hosting, fue de los primeros en marcar el error fatal en X mientras el release todavía ni se había anunciado en el escenario. En la comunidad de WordPress profundizamos sobre esto.

Conviene subrayar algo que el post-mortem de WP Rocket deja claro: los plugins involucrados no estaban haciendo nada incorrecto. Elementor Pro, WP Rocket y compañía usaban APIs de WordPress de la forma documentada. Lo que cambió fue el terreno debajo de ellos. El bug estaba en el Core de 7.1, y esos plugins solo tuvieron la mala suerte de tocar la parte que cambió.

¿Cuáles plugins causaron el error fatal de WordPress 7.1?

Ningún plugin «causó» el error en sentido estricto: lo hicieron evidente. El post-mortem de WP Rocket identifica a Elementor Pro y a Redirection para Contact Form 7 entre los que participaban en la combinación que reventaba, junto con el módulo de Cloudflare del propio WP Rocket. El denominador común es que todos registran callbacks en hooks de WordPress de una manera particular, y ahí es donde 7.1 cambió las reglas.

La condición se cumplía cuando coincidían varias cosas a la vez. Por eso no todos los sitios con esos plugins se cayeron, sino los que además corrían PHP 8 y tenían activa la combinación exacta. Esta tabla resume quién entra en la foto y cuándo se activaba el problema:

Plugin / componente	Qué hacía	Cuándo se activaba el fallo
WP Rocket (módulo Cloudflare)	Registraba un callback en un hook del Core	Con 7.1 + PHP 8 y el plugin de Cloudflare activo
Elementor Pro	Enganchaba funciones en hooks del editor y del front	Al generar la página con 7.1 bajo PHP 8
Redirection para Contact Form 7	Añadía callbacks a la lógica de formularios	Al procesar hooks afectados por el cambio de 7.1

El detalle importa para no repartir culpas mal. Si tu sitio se cayó con Elementor Pro activo, el problema no era Elementor: era la interacción entre el código de 7.1 y PHP 8. Desactivar el plugin resolvía el síntoma, pero la raíz estaba en el Core, y por eso hizo falta un parche tanto del lado de los plugins como del propio WordPress.

¿Por qué WordPress 7.1 rompió estos plugins? El error explicado

Porque WordPress 7.1 cambió cómo genera los IDs de los callbacks en ciertos hooks, y ese cambio chocó con el tipado estricto de PHP 8. En versiones anteriores, cuando el Core necesitaba identificar un callback, terminaba con un valor de un tipo; en 7.1 ese valor podía llegar como un entero en lugar del objeto esperado. Ahí aparece el problema.

La función que arma esos IDs se apoya en spl_object_id(), que —como su nombre indica— espera un objeto. Bajo PHP 8 con tipado estricto, pasarle un valor de otro tipo no se degrada en silencio como pasaba antes: dispara un error fatal y corta la ejecución. En modelos de PHP más permisivos, el mismo caso se hubiera «tragado» sin tumbar el sitio. Con 7.1 y PHP 8, en cambio, el sitio moría en el acto. Sobre eso hablamos en impacto en tus páginas publicadas.

Esto es lo interesante desde el punto de vista técnico: no fue un plugin escribiendo código malo, sino un cambio del Core que dejó al descubierto una suposición que antes funcionaba por casualidad. Weston Ruter, maintainer del Core de WordPress, confirmó de forma oficial que el origen del cambio estaba en el propio 7.1, lo que cerró la discusión sobre a quién «echarle la culpa». Cualquiera que haya peleado con PHP sabe que el salto a tipado estricto siempre saca a la luz este tipo de deudas ocultas.

¿Cuántos sitios afectó el error de WordPress 7.1?

Menos de los que estaban en riesgo, pero muchos igual. Según el post-mortem de WP Rocket, cerca del 27% de sus usuarios corría la combinación potencialmente peligrosa (WordPress 7.1 + PHP 8 + el módulo de Cloudflare y plugins con callbacks del tipo afectado), pero solo alrededor del 10% se vio realmente impactado. La diferencia entre «en riesgo» e «impactado» depende de qué plugins concretos tenía cada sitio activos y de si se cumplían todas las condiciones a la vez.

¿Por qué esta combinación específica resultó tan común en la práctica? Porque cada pieza, por separado, es habitual. PHP 8 ya es el estándar en la mayoría de los hostings modernos. El plugin de Cloudflare está en muchísimos sitios. Y los page builders o plugins de formularios que registran callbacks están en la enorme mayoría de las webs de WordPress. Cuando algo tan corriente se junta con un bug del Core, el resultado escala rápido.

Ese ~10% real de impacto suena chico, pero en la base instalada de un plugin tan usado como WP Rocket son miles de sitios. Y lo que lo hizo doloroso no fue la cantidad, sino la gravedad: no era un aviso amarillo en el admin, era el sitio entero abajo. Un 0,5% de sitios rotos es un problema; un 10% cayéndose el día del lanzamiento oficial es una tormenta.

¿Cuál fue la cronología del incidente de WordPress 7.1?

El bug no apareció de la nada el día del lanzamiento: había asomado semanas antes. El post-mortem reconstruye una línea de tiempo que arranca en pleno ciclo de desarrollo y termina con el hotfix pocas horas después del release. Estos son los hitos, con las horas en CEST (horario centroeuropeo) que usa WP Rocket en su reporte:

• 6 de julio: primer reporte del problema durante el ciclo alpha. En ese momento no se dimensionó su gravedad.
• Alpha, beta y release candidate: la versión pasó por todas las etapas de prueba; el 19 de agosto se etiquetó el RC.
• 20 de agosto, 02:18 CEST: release oficial de WordPress 7.1. Las auto-actualizaciones empiezan a propagarse.
• Madrugada: escalada de tickets a medida que los sitios con la combinación afectada empiezan a caer.
• 20 de agosto, 07:30 CEST: comunicación pública de WP Rocket reconociendo el problema.
• 20 de agosto, 10:11 CEST: se libera el hotfix 3.23.2.2, menos de ocho horas después del release.

La pregunta obligada es por qué los tests automatizados no lo agarraron, si el bug estaba reportado desde julio. La respuesta que da WP Rocket es incómoda pero honesta: la suite de testing no reproducía la combinación real que rompía en producción. Probaba plugins y temas, sí, pero no ese cruce puntual de 7.1 + PHP 8 + Cloudflare + plugins con callbacks particulares. El caso existía en un ticket, pero no en un test que corriera en cada build. Habría que ver cuántos proyectos grandes están en la misma situación sin saberlo. Tema relacionado: usar un ambiente de prueba.

¿Cómo se resolvió el error fatal de WordPress 7.1?

Con un hotfix el mismo día y un arreglo en el Core poco después. WP Rocket liberó la versión 3.23.2.2 la mañana del 20 de agosto, a las 10:11 CEST. El fix es quirúrgico: ahora el plugin verifica si el plugin de Cloudflare está realmente activo antes de ejecutar el código que disparaba el error. Si no lo está, ni siquiera entra en la ruta problemática. Es una guarda simple que corta el caso de raíz sin tocar el resto del comportamiento.

Del otro lado, WordPress también hizo su parte. El fix del bug de generación de IDs de callbacks entró en el Core con WordPress 7.1.1, la versión de mantenimiento posterior. Esto es importante porque significa que el problema se atacó en las dos capas: el plugin dejó de tropezar con la trampa, y el Core dejó de poner la trampa. Si actualizás a 7.1.1, la causa de fondo desaparece aunque tengas plugins que todavía no se hayan parcheado.

Para un sitio ya caído, el camino de recuperación en el momento fue el clásico: desactivar WP Rocket por FTP o por el gestor de archivos del hosting, subir la versión parcheada y reactivar. Nada elegante, pero efectivo. Con 7.1.1 y los plugins al día, ese baile ya no hace falta.

¿Qué cambia WP Rocket para evitar otro apagón?

El post-mortem no se queda en el «qué pasó» y enumera cambios concretos de proceso. WP Rocket asignó un ownership claro al triage en GitHub, para que un reporte como el de julio no se quede sin dueño y sin escalar. La idea es que ningún ticket con potencial de tumbar sitios pase desapercibido entre el ruido del resto de issues.

El cambio más de fondo es la reconstrucción intencional de la suite de testing. En vez de probar contra un set histórico de plugins y temas, ahora buscan cubrir combinaciones reales de plugins y temas que la gente usa de verdad —incluidos los cruces raros como el que rompió esta vez—. La lección explícita es que testear incrementalmente no alcanza si no reproducís el entorno real donde el código va a correr.

• Ownership en el triage de GitHub: cada reporte crítico tiene un responsable de escalarlo, para que no se diluya.
• Suite de testing con plugins y temas reales: se prueban combinaciones que la base de usuarios usa de verdad, no un set histórico fijo.
• Validación más rápida de hotfixes: el objetivo es acortar la ventana entre detectar un problema grave y publicar el parche.
• Gating del módulo Cloudflare: ese módulo solo ejecuta su código cuando el plugin de Cloudflare está efectivamente en uso.

Es la parte más sana del episodio. Un error fatal el día del lanzamiento es un mal trago, pero publicar un post-mortem con nombres, horas y decisiones —y hacerse cargo de qué falló en el propio proceso— es lo que separa a un equipo que aprende de uno que barre bajo la alfombra. Nuestros colegas de seguridadenwordpress.com analizan estos temas de cadena y compatibilidad en su artículo sobre vulnerabilidades en la cadena de suministro.

¿Por qué el lanzamiento de WordPress 7.1 en WordCamp US fue tan confuso?

Porque el lanzamiento en vivo se disparó solo antes de que nadie lo anunciara. Según el decision log que publicó Anne McCarthy, release lead de 7.1, un commit activó las auto-actualizaciones cerca de la 1:30 PM (hora de Phoenix), cuando la versión supuestamente solo debía estar disponible desde la página de descargas y por WP-CLI. La ceremonia todavía no había empezado.

El plan era prolijo: Matt Mullenweg recibía la proclamación de la Ciudad de Phoenix, pasaba el video de highlights y arrancaba su sesión de cierre. Nada salió como estaba escrito. Llegó un mensaje entre bambalinas de que Mullenweg «no quería hacer lo del botón», algo que McCarthy describió como ambiguo. ¿Y qué hizo ella con esa ambigüedad? Publicar. Para cuando el release estaba en marcha, ya se estaba descargando y Austin Ginder ya había marcado en X el error fatal de WP Rocket. Esto se conecta con lo que analizamos en reparar enlaces dañados tras el error.

¿Qué novedades trae WordPress 7.1 «Mary Lou»?

WordPress 7.1 se enfoca en el editor y en la colaboración, con más de 1.500 mejoras según el anuncio oficial en es.wordpress.org. Lo más jugoso: ahora podés definir estilos por breakpoint sin tocar CSS, tenés bloques nuevos y el lienzo de edición pasó a correr dentro de un iframe.

• Diseño responsive en el editor: ajustás tipografía, espacios, bordes y dimensiones distintos para móvil, tablet y escritorio, directo desde la interfaz.
• Bloques Tabs y Playlist: pestañas y listas de reproducción nativas, sin depender de un plugin de terceros.
• Notas con @menciones: comentarios colaborativos dentro del contenido, con menciones a otros editores.
• Procesamiento de medios en el navegador: las imágenes se optimizan del lado del cliente antes de subirlas.
• Abilities API: una capa para que herramientas de IA interactúen con acciones de WordPress de forma estructurada.
• Editor en iframe: el canvas queda aislado del resto del admin, lo que también rompe plugins legacy que asumían un DOM compartido.

Función	Qué hace	A quién le sirve
Responsive en editor	Estilos por breakpoint sin CSS	Diseñadores, no-code
Bloques Tabs / Playlist	Pestañas y audio nativos	Creadores de contenido
Notas @menciones	Colaboración inline	Equipos editoriales
Medios en navegador	Optimiza antes de subir	Sitios con muchas imágenes
Abilities API	Acciones para IA	Desarrolladores
Editor en iframe	Aísla el canvas	Devs de plugins/themes

Un matiz que conviene tener claro: el iframe del editor y el error fatal del post-mortem son dos frentes distintos. El iframe rompe plugins que tocan el editor y asumían un DOM compartido. El bug de los callbacks —el del apagón— es otra cosa, y golpeaba en el front y el admin de sitios con la combinación de PHP 8 y ciertos plugins. Hubo, en la práctica, dos fuentes de rotura en el mismo lanzamiento.

¿Cómo actualizar tu sitio a WordPress 7.1 sin romperlo?

La regla de oro es no actualizar producción a ciegas: probá primero en staging. Con el antecedente del error fatal de los callbacks y el cambio a iframe, actualizar producción sin testear es jugar a la ruleta. Estos son los pasos que conviene seguir:

• Actualizá a 7.1.1, no a 7.1 a secas: la versión de mantenimiento incluye el fix del bug de callbacks en el Core, así que ataca la causa de fondo.
• Chequeá tus plugins críticos: cache, builder, WooCommerce y formularios primero. Con WP Rocket, asegurate de tener la 3.23.2.2 o superior.
• Cloná a staging: actualizá ahí, revisá el sitio a ojo y en consola antes de tocar producción.
• Si algo revienta, aislá el culpable: desactivá plugins uno por uno. Con WP Rocket, el workaround es desactivarlo por FTP, actualizar el core y después reactivarlo ya parcheado.

Si no tenés un staging a mano, ese es el momento de que tu hosting te lo dé fácil. En un hosting WordPress como el de Donweb podés levantar una copia de prueba, actualizar ahí y recién después pasar los cambios a producción sin sustos. Zafás del papelón de romper el sitio en el peor momento.

Si querés los detalles completos, revisá nuestro artículo The WordPress 7.1 Outage.

Qué está confirmado y qué no

• Confirmado: el error fatal de WordPress 7.1 fue un bug de compatibilidad del Core, no un ataque (post-mortem de WP Rocket).
• Confirmado: el cambio en la generación de IDs de callbacks se originó en 7.1 y chocó con PHP 8; Weston Ruter, maintainer del Core, lo confirmó oficialmente.
• Confirmado: ~27% de usuarios de WP Rocket en riesgo potencial y ~10% realmente impactados (cifras del post-mortem de WP Rocket).
• Confirmado: hotfix 3.23.2.2 publicado el 20 de agosto a las 10:11 CEST, y fix en el Core con WordPress 7.1.1.
• Pendiente: el listado completo de plugins de terceros afectados. Cada equipo publica sus parches a su ritmo.
• Sin confirmar: si Mullenweg no quería el botón ceremonial o el release en vivo entero. McCarthy lo describió como ambiguo, no como un hecho cerrado.

Errores comunes al actualizar a WordPress 7.1

• Quedarte en 7.1 en vez de 7.1.1: el fix del bug de callbacks está en la 7.1.1. Si actualizás a la 7.1 a secas, seguís expuesto a la causa de fondo.
• Actualizar con WP Rocket sin parchear: si tenés una versión anterior a la 3.23.2.2, subí el plugin primero o desactivalo por FTP antes de tocar el core.
• Confiar en que «el auto-update se encarga»: justamente un auto-update prematuro fue el que descontroló el lanzamiento oficial. Controlá vos cuándo pasa.
• Ignorar los plugins que tocan el editor: el iframe rompe suposiciones viejas sobre el DOM. Testeá tu builder antes de dar por hecho que anda.

Preguntas Frecuentes

¿Qué pasó con WordPress 7.1?

WordPress 7.1 disparó un error fatal en una parte de los sitios apenas se actualizaron el 20 de agosto de 2026, dejándolos con el frontend y el dashboard caídos. No fue un ataque, sino un bug de compatibilidad del Core con PHP 8 que afectó a plugins como WP Rocket y Elementor Pro. WP Rocket sacó un hotfix el mismo día.

¿Por qué se cayó WordPress 7.1?

Porque 7.1 cambió cómo el Core genera los IDs de los callbacks en ciertos hooks. Bajo PHP 8 con tipado estricto, la función spl_object_id() recibía un valor de un tipo que no esperaba y disparaba un error fatal en lugar de continuar en silencio. Antes, con PHP más permisivo, el mismo caso no rompía nada.

¿Cuáles plugins causaron el problema de WordPress 7.1?

El post-mortem de WP Rocket menciona a Elementor Pro, a Redirection para Contact Form 7 y al módulo de Cloudflare del propio WP Rocket, entre otros. Ninguno estaba haciendo nada mal: solo registraban callbacks de la forma que 7.1 dejó de tolerar bajo PHP 8. La causa real estaba en el Core, no en los plugins.

¿Cómo arreglar el error fatal de WordPress 7.1?

Actualizá a WordPress 7.1.1, que trae el fix en el Core, y subí tus plugins a la versión parcheada (en WP Rocket, la 3.23.2.2 o superior). Si el sitio ya está caído, desactivá el plugin afectado por FTP o por el gestor de archivos del hosting, actualizá el core y reactivalo después.

¿Es seguro actualizar a WordPress 7.1?

Sí, pero saltando directamente a 7.1.1 y probando primero en staging. Con la versión de mantenimiento y los plugins de cache y builder al día, la causa del error fatal desaparece. Verificá tus plugins críticos antes de tocar producción, sobre todo si corrés PHP 8.

Conclusión

El post-mortem de WP Rocket convierte el «apagón de WordPress 7.1» de un misterio ruidoso en un caso técnico entendible: un cambio del Core en la generación de IDs de callbacks, PHP 8 con tipado estricto y una combinación de plugins demasiado común para no explotar. Nadie hizo nada malo; el terreno se movió debajo de plugins que funcionaban.

Para vos, lo práctico cambió respecto de los primeros días de pánico. Ahora la causa está identificada y parcheada en las dos capas: en los plugins y en el propio Core con 7.1.1. La recomendación concreta es actualizar a 7.1.1 —no a 7.1 pelada—, subir WP Rocket a la 3.23.2.2 o superior y hacerlo primero en staging. Y de acá en adelante, vale la pena mirar cómo evoluciona el proceso de testing que WP Rocket prometió reconstruir: que un equipo publique un post-mortem con horas, nombres y errores propios es exactamente lo que uno quiere ver después de un incidente así.

Fuentes

• WP Rocket – Post-mortem del apagón de WordPress 7.1
• WordPress.org – Anuncio oficial de WordPress 7.1 «Mary Lou»
• The Repository – Anne McCarthy publica el decision log de WordPress 7.1