WPPoland (Mariusz Szatkowski) actualiza WP Rocket a 3.23.2.2 en staging antes de WordPress 7.1. Las versiones 3.23.2.1 y anteriores disparan un error fatal en cada petición: Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given en Cloudflare.php:562. El informe de GitHub llegó el 6 de julio de 2026. WordPress 7.1 Mary Lou salió el 19 de agosto. La corrección del plugin salió el 20 de agosto. Primero el plugin, después el núcleo.
Qué se cayó
Actualizaste a WordPress 7.1 y el sitio se quedó en blanco. wp-admin caído. admin-ajax caído. REST caído. WP-CLI muere con el mismo stack. El registro de PHP repite una línea en cada petición:
PHP Fatal error: Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given in .../wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php:562
Wordify lo reprodujo de punta a punta en un sitio de prueba y publicó el stack el 20 de agosto de 2026. El fatal dispara en init, mientras WordPress todavía arranca, así que el frontal y el escritorio mueren juntos. Activar WP_DEBUG no siempre imprime nada en pantalla. El registro de errores es el lugar fiable.
Esto es un bug de WP Rocket, no un bug del hosting, y no un “WordPress 7.1 está roto”. Los sitios sin WP Rocket no vieron este TypeError. Los sitios en WP Rocket 3.23.2.2 no lo ven. La línea del changelog es: “Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations.”
El código vive en el módulo de compatibilidad con Cloudflare. No hace falta una zona de Cloudflare para que se ejecute. Wordify lo dejó explícito: el módulo corre en cada petición, esté o no instalado el plugin de Cloudflare.
En las tiendas Elementor que vemos sobre SiteGround Madrid el síntoma se disfraza. SuperCacher (caché NGINX del plan GrowBig o Cloud) sigue sirviendo el último HTML bueno a los visitantes anónimos. La homepage responde 200. El cliente en España abre el sitio a las 09:00 CEST, ve el catálogo de ayer y no abre ticket. wp-admin, en cambio, es una pantalla en blanco desde las 03:55 CEST, que es cuando el primer fatal de Wordify quedó escrito a las 01:55 UTC. El registro de PHP, no la homepage, es la prueba.
Tres piezas inofensivas por separado
WordPress 7.1 cambió cómo se construyen los IDs de callback de los hooks. El ticket de Trac 65919 es el cambio de núcleo. Hasta 7.0.x, _wp_filter_build_unique_id() usaba spl_object_hash(), un string hexadecimal de 32 caracteres. 7.1 pasó a spl_object_id(), un entero pequeño convertido a string. David Levine, de rtCamp, señaló el mismo ticket cuando la cuenta oficial de WordPress en X dijo “this wasn’t a bug in 7.1.” El TypeError está en el plugin. El tipo de la clave cambió en el núcleo. Las dos frases pueden ser ciertas.
PHP, a continuación, guarda las claves de array que parecen números como enteros. Cuando "5292" se usa como clave en $wp_filter, PHP la conserva como 5292. Después de 7.1, un closure enganchado a una acción tiene una clave entera. Antes de 7.1, todas las claves eran strings.
WP Rocket asume que esas claves son strings, con strict_types=1 en Cloudflare.php. En init recorre los callbacks de deleted_post y transition_post_status y llama a substr() sobre cada clave. Los tipos estrictos se niegan a convertir el entero. Fatal.
Wordify publicó el bucle:
foreach ( $original_wp_filter[ $priority ] as $key => $config ) {
if ( substr( $key, - strlen( $method ) ) !== $method ) {Un WordPress limpio más WP Rocket a menudo sobrevive. Austin Ginder lo comprobó. Añade un plugin que enganche un closure en deleted_post en prioridad 10, o en transition_post_status en PHP_INT_MAX, y la siguiente petición muere. Elementor Pro es el ejemplo extendido. Contact Form 7 Redirection es otro. El segundo plugin no hace nada mal. Enganchar un closure es WordPress normal.
En el mercado español esa segunda pieza casi nunca falta. La tienda Elementor típica que llega a un contrato de mantenimiento lleva Elementor Pro, WP Rocket y un plugin de formularios, a menudo Contact Form 7 con la extensión de redirección, sobre PHP 8.2 en SiteGround. Ese es exactamente el combo que Ginder y Wordify describieron. No hace falta Cloudflare. No hace falta WooCommerce. Basta el closure de Elementor Pro en deleted_post y el bucle de Cloudflare.php en init.
Matt Cromwell señaló la ironía en X: el cambio de núcleo era una mejora de rendimiento, que es el producto que vende WP Rocket.
El informe de GitHub de seis semanas
El issue 8596 de wp-media/wp-rocket se abrió el 6 de julio de 2026, durante la beta de 7.1. El informe nombraba el TypeError y sugería un cast a string de una línea. The Repository, 21 de agosto: WP Rocket lo revisó el mismo día, QA no pudo reproducirlo en pruebas automáticas, y el issue se quedó ahí. Nunca se le asignó un responsable.
WordPress 7.1 salió el 19 de agosto de 2026, día de cierre de la WordCamp US en Phoenix. En España era tarde CEST (Phoenix va a UTC-7 en agosto). Ginder publicó el mismo día: los sitios con WP Rocket de la flota de Anchor Hosting se quedaron fuera de línea tras el salto a 7.1. Parcheó el plugin a mano para devolverlos.
Dos issues más de GitHub, 8740 y 8741, aterrizaron el día siguiente al lanzamiento. WP Rocket publicó un aviso: no actualice a 7.1 hasta que haya corrección, con un artículo de soporte en docs.wp-rocket.me/article/1927. Más tarde, el 20 de agosto, publicaron 3.23.2.2, el cast de una línea del informe de julio. Wordify verificó la corrección sobre el mismo fallo que habían vuelto a montar en 3.23.2.1.
El pull de GitHub es wp-media/wp-rocket#8745.
Seis semanas entre un informe con el parche escrito y un fatal en producción no es un fallo de PHP. Es un fallo de cola. El issue tuvo revisión el 6 de julio y no tuvo dueño. En CEST, el 19 de agosto cayó por la tarde y el 20 de agosto los sitios españoles con auto-updates nocturnas de SiteGround se encontraron el escritorio blanco al abrir el portátil.
Quién se quedó fuera
Los números de la flota de Ginder, 20 de agosto: 124 de 332 sitios de producción con WP Rocket cayeron, 37 por ciento. Cada caída era WordPress 7.1 + PHP 8.x + Cloudflare.php.
El post-mortem posterior de WP Rocket, cubierto por The Repository el 27 de agosto, estimó alrededor del 27 por ciento de su base de usuarios en riesgo y alrededor del 10 por ciento realmente afectados. El CEO Rémy Lamiot dijo que Elementor Pro, pese a la base instalada y pese a ser uno de los disparadores, no estaba en la lista de compatibilidad que probaron. El informe de julio no tuvo dueño. “This cost real time and real trust,” escribió.
Esos dos porcentajes no miden lo mismo. Ginder contó una flota gestionada que ya corría WP Rocket. WP Rocket contó su base de usuarios entera, incluidos sitios que no tomaron 7.1 esa semana y sitios sin el segundo plugin. Cita ambos. No los promedies.
El primer sitio de cliente de Wordify actualizó el núcleo a las 01:55 UTC. El primer fatal llegó al registro tres segundos después. Son las 03:55 CEST. Soporte desactivó el plugin. Unos 35 minutos de punta a punta, la mayor parte diagnóstico, porque nadie había unido todavía “7.1” con “WP Rocket”.
En una tienda Elementor española esa hora importa. SiteGround programa las actualizaciones automáticas del núcleo de madrugada. El propietario no está delante del registro a las 04:00. SuperCacher y, si también está activo, SiteGround Optimizer siguen sirviendo HTML. A las 09:00 CEST alguien entra a cambiar un precio o una página y wp-admin está blanco. El ticket llega con cinco horas de retraso y con un “a mí la web me carga”. El registro de PHP dice otra cosa.
Andrew Hoyer escribió que había avisado a su equipo sobre 7.1 y aun así se despertó con decenas de sitios rotos. Su frase: prueba alpha, beta y RC sobre tu propio stack, en lugar de fiarte del proveedor. Steve Jones preguntó si la gente actualizaba producción la hora en que aterrizaba una versión mayor, sin rollback. Las dos preguntas son el trabajo de un contrato de mantenimiento. No son un argumento de marca.
Orden seguro
Si el sitio sigue en WordPress 7.0.x y WP Rocket es anterior a 3.23.2.2:
- Clona a staging.
- Actualiza WP Rocket a 3.23.2.2 en staging. Confirma que cargan wp-admin y una portada sin sesión.
- Después toma WordPress 7.1 en staging. Prueba login, checkout si hay WooCommerce, un formulario, cron.
- Repite el mismo orden en producción: primero el plugin, después el núcleo.
En SiteGround el clon es el botón de staging de Site Tools, no un subdirectorio colgado de producción. Misma versión de PHP (en Madrid, casi siempre 8.2 u 8.3), misma object cache, mismos plugins. Si el sitio también lleva SiteGround Optimizer, déjalo en el clon. El combo Rocket + Optimizer es el que realmente corre, no un WordPress desnudo.
Si las auto-updates ya tomaron 7.1 y el sitio está en blanco, no sigas el orden anterior. Desactiva primero.
No reactives 3.23.2.1 sobre 7.1. El artículo de soporte de WP Media es explícito: si no aparece una actualización en la lista de plugins, sigue su guía de actualizaciones que no se muestran. Reactivar la versión rota tumba el sitio otra vez.
Las versiones muy antiguas de WP Rocket, anteriores al bucle de Cloudflare.php, no se ven afectadas. Wordify situó la franja afectada en más o menos 3.16 a 3.23.2.1. Si no estás seguro, actualiza a 3.23.2.2 de todos modos. Esa es la versión con el cast a string.
| Pieza | Versión / fecha | Papel |
|---|---|---|
| WordPress | 7.1 Mary Lou, 19 Aug 2026 | Cambió los IDs de hooks a spl_object_id (Trac 65919) |
| PHP | 8.x con strict_types=1 en el archivo del plugin | Una clave entera en substr() es un TypeError, no un aviso |
| WP Rocket | 3.16 a 3.23.2.1 | Cloudflare.php:562 recorre las claves de hooks en init |
| WP Rocket | 3.23.2.2, 20 Aug 2026 | Cast a string de una línea, del GitHub 8596 |
| Plugin disparador | Elementor Pro, CF7 Redirection, otros | Closure en deleted_post o transition_post_status |
Ya cubrimos qué salió de verdad en 7.1, y qué se recortó, en la nota sobre la hoja de ruta de WordPress 7.1. El editor de entradas en iframe es otro cambio que rompe a los desarrolladores. Detalles en la nota sobre el editor en iframe. Esta pieza es solo el fatal de Rocket.
Si wp-admin ya está en blanco
No borres Cloudflare.php. Wordify: la clase está cableada en el contenedor del plugin, y quitar el archivo cambia este fatal por otro.
WP-CLI. WP-CLI carga los plugins, así que un wp plugin deactivate wp-rocket a pelo muere. Omite el plugin mientras lo desactivas:
wp plugin deactivate wp-rocket --skip-plugins=wp-rocketEn SiteGround, SSH y WP-CLI están en los planes Cloud y en algunos GrowBig con acceso extra. En un plan más bajo el camino es SFTP.
SFTP. Renombra wp-content/plugins/wp-rocket a wp-rocket.off. WordPress trata una carpeta renombrada como desactivada en la siguiente petición. En Site Tools el administrador de archivos hace lo mismo si no tienes cliente SFTP a mano.
Después actualiza a 3.23.2.2 desde wp-admin, que ya está vivo, y reactívalo.
Un rollback a 7.0.4 desde una copia anterior a la actualización también devuelve el sitio. Es el camino más lento. Descarta los archivos de 7.1 que ya escribiste a disco. Úsalo cuando no puedas alcanzar SFTP ni WP-CLI.
Una caché de página a nivel de host (LiteSpeed, FastCGI de nginx, caché HTML de Cloudflare, SuperCacher de SiteGround) puede seguir sirviendo la última página buena a los visitantes anónimos mientras wp-admin está muerto. Eso esconde la caída a parte de los clientes y retrasa el ticket. Mira el registro de errores, no solo la homepage. En Raiola y otros hostings españoles con LiteSpeed el patrón es el mismo: la portada miente, el log no.
Cómo probamos un salto del núcleo
WPPoland (Mariusz Szatkowski) trata una versión mayor como una comprobación de tres capas, no como una fecha del calendario.
Staging es un clon, no un subdirectorio en producción. Mismo PHP, misma object cache, mismos plugins. Primero tomamos las actualizaciones de plugins con una incompatibilidad conocida. Para 7.1 esa lista empezó por WP Rocket 3.23.2.2. Después el núcleo. Después una lista de humo: login, un guardado en el editor de entradas (ahora siempre en iframe), carrito y checkout de WooCommerce si el sitio los tiene, un POST de formulario, una pasada de cron.
No nos fiamos de un “WP Rocket dijo que probaron 7.1”. Probaron. Su suite se saltó la clave entera más el closure de un segundo plugin. La instalación limpia de Ginder no cayó. La combinación sí. La combinación es lo que es un sitio de cliente de verdad.
El clon típico de este taller, cuando el cliente está en España, es WordPress + tienda Elementor o WooCommerce + WP Rocket + un plugin de formularios, a menudo sobre SiteGround Madrid en PHP 8.2. Esa es la combinación que Ginder y Wordify describieron. No esperamos el tuit del proveedor con “we tested 7.1”. Tomamos 7.1 en el clon, pedimos / y /wp-admin/, y hacemos grep del registro de PHP buscando TypeError y Cloudflare.php. Si el log está en silencio y las dos URLs devuelven 200 sin omitir plugins, el salto puede ir a producción en el mismo orden.
La versión de PHP forma parte del clon. El TypeError es un fallo de tipos estrictos de PHP 8. Un host que siga en PHP 7.4 no lanzaría este fatal concreto. Eso no es una razón para quedarse en 7.4. Es una razón para probar 8.2 u 8.3 con el mismo juego de plugins que corres en producción, no con un WordPress desnudo. SiteGround ya empuja 8.2 por defecto en Madrid. El clon tiene que coincidir, no “parecerse”.
En producción guardamos una copia con nombre de antes del salto y una ventana de 15 minutos en la que alguien mira el registro de errores, no solo el ping de uptime. Como el equipo y el cliente comparten CET, esa ventana es la misma tarde, no un solape con otra costa. Una homepage en blanco con un 200 de la caché HTML no es un aprobado.
Eso es el mantenimiento WordPress en un párrafo. Staging primero. Plugin primero cuando el proveedor tiene una versión fijada. Núcleo después. Comprobación de salud al final. Presupuesto por escrito tras un briefing corto.
Si la superficie pública ya vive en Cloudflare Workers o Pages, el fatal de PHP sigue matando wp-admin y cualquier ruta de origen. La caché HTML en el edge no sustituye a un plugin que muere en init. El pilar de Cloudflare edge es la capa de entrega. Este incidente es la capa de origen.
Actualizaciones automáticas y 7.1.1
Wordify advirtió que las auto-updates de 7.1 estaban rodando la misma semana. Un sitio que nadie tocó podía pasar de bien a caído de un día para otro. En CEST eso es un miércoles por la noche y un jueves por la mañana con el escritorio blanco. SiteGround y otros paneles con auto-updates del núcleo no preguntan la hora local del propietario.
Adam Silverstein abrió el Trac 65920 el 20 de agosto: un workflow de GitHub Actions para probar los 100 plugins más usados del directorio contra WordPress aún no publicado. PR en borrador 13198, con hito en 7.2. En el ticket señaló que este incidente concreto no se habría cazado, porque WP Rocket es de pago y la API del directorio cubre plugins gratuitos. La misma clase de fatal por cambio de tipo puede seguir pegando a un plugin gratuito con millones de instalaciones. Ese es el punto del workflow.
Aaron Jorbin pidió voluntarios para gestionar 7.1.x. 7.1.1 quedó esbozada entre el 1 y el 24 de septiembre de 2026. Trata 7.1.1 igual: staging, después producción. Si las claves enteras de 65919 reciben un shim de compatibilidad en 7.1.1, es un seguro extra. No es una razón para saltarse 3.23.2.2.
Jeffrey Paul respaldó el ticket de Silverstein: los fatales repetidos después de una versión mayor entran en la esfera de preocupación del núcleo, aunque el archivo roto viva en un plugin. Esa es la división honesta. El núcleo puede probar plugins del directorio. El núcleo no puede probar plugins de pago que no tiene. El dueño del sitio, o quien está en el contrato de mantenimiento, sigue siendo dueño del clon.
Lo que no estamos afirmando
No estamos diciendo que tires WP Rocket. 3.23.2.2 es la versión actual con el cast. Los plugins de caché siguen ganándose el sitio en orígenes PHP.
No estamos diciendo que te saltes WordPress 7.1. La estilización responsiva, los media del lado del cliente, la barra de administración persistente y el editor en iframe salieron. La nota de la hoja de ruta lista lo que aterrizó y lo que no.
No estamos citando los precios de WP Rocket. Las tarifas de licencia de terceros son su lista. Nuestro trabajo de mantenimiento es un presupuesto individual.
No estamos inventando un porcentaje para “todo internet”. El 37 por ciento de Ginder es una flota. El 10 por ciento de WP Rocket es su estimación de su base de usuarios. Ambos tienen fuente. Ninguno es un censo.
Última actualización: 1 de septiembre de 2026. Fuentes: The Repository (21 y 27 de agosto de 2026), el artículo del stack trace de Wordify (20 de agosto), el issue 8596 de GitHub y el pull 8745, Trac 65919 y 65920, el changelog de WP Rocket 3.23.2.2 y el artículo de soporte 1927, Austin Ginder en X, las citas del post-mortem de Rémy Lamiot vía The Repository.
