A WPPoland (Mariusz Szatkowski) atualiza o WP Rocket para 3.23.2.2 em staging antes do WordPress 7.1. As versões 3.23.2.1 e anteriores dão erro fatal em todos os pedidos: Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given em Cloudflare.php:562. O relatório no GitHub chegou a 6 de julho de 2026. O WordPress 7.1 Mary Lou saiu a 19 de agosto. A correção do plugin saiu a 20 de agosto. Plugin primeiro, núcleo depois.
O que falhou
Atualizou para o WordPress 7.1 e o site ficou em ecrã branco. O wp-admin está em baixo. O admin-ajax está em baixo. A REST está em baixo. O WP-CLI morre com o mesmo stack. O registo PHP repete uma linha em todos os pedidos:
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
A Wordify reproduziu o caso de ponta a ponta num site de teste e publicou o stack a 20 de agosto de 2026. O erro fatal dispara no init, enquanto o WordPress ainda está a arrancar, por isso a frente e o painel morrem juntos. Ligar o WP_DEBUG nem sempre imprime nada no ecrã. O sítio fiável é o registo de erros.
Isto é um erro do WP Rocket, não um erro do alojamento, e não é “o WordPress 7.1 está partido.” Sites sem WP Rocket não apanharam este TypeError. Sites no WP Rocket 3.23.2.2 também não. A linha do changelog é: “Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations.”
O caminho de código vive no módulo de compatibilidade Cloudflare. Não precisa de uma zona Cloudflare para ele correr. A Wordify foi explícita: o módulo corre em todos os pedidos, esteja ou não o plugin Cloudflare instalado.
Três peças inofensivas sozinhas
O WordPress 7.1 mudou a forma como os IDs de callback dos hooks são construídos. O ticket Trac 65919 é a alteração no núcleo. Até ao 7.0.x, _wp_filter_build_unique_id() usava spl_object_hash(), uma string hexadecimal de 32 caracteres. O 7.1 passou para spl_object_id(), um inteiro pequeno convertido para string. David Levine, da rtCamp, apontou mais tarde para o mesmo ticket quando a conta oficial do WordPress no X disse “this wasn’t a bug in 7.1.” O TypeError está no plugin. O tipo da chave mudou no núcleo. As duas afirmações podem ser verdadeiras.
O PHP depois guarda chaves de string numéricas como inteiros. Quando "5292" entra como chave de array em $wp_filter, o PHP guarda-a como 5292. Depois do 7.1, uma closure ligada a uma action tem uma chave inteira. Antes do 7.1, todas as chaves eram strings.
O WP Rocket assume que essas chaves são strings, com strict_types=1 no Cloudflare.php. No init percorre os callbacks de deleted_post e transition_post_status e chama substr() em cada chave. Os tipos estritos recusam converter o inteiro. Erro fatal.
A Wordify publicou o ciclo:
foreach ( $original_wp_filter[ $priority ] as $key => $config ) {
if ( substr( $key, - strlen( $method ) ) !== $method ) {Um WordPress limpo mais o WP Rocket muitas vezes sobrevive. Austin Ginder encontrou isso. Acrescente um plugin que liga uma closure a deleted_post na prioridade 10, ou a transition_post_status em PHP_INT_MAX, e o pedido seguinte morre. O Elementor Pro é o exemplo generalizado. O Contact Form 7 Redirection é outro. O segundo plugin não está a fazer nada de errado. Ligar uma closure é WordPress normal.
Matt Cromwell notou a ironia no X: a alteração no núcleo era uma melhoria de desempenho, que é o produto que o WP Rocket vende.
O relatório de seis semanas no GitHub
A issue 8596 do wp-media/wp-rocket foi aberta a 6 de julho de 2026, durante a beta do 7.1. O relatório nomeava o TypeError e sugeria um cast de string de uma linha. The Repository, a 21 de agosto: o WP Rocket reviu-a no mesmo dia, o QA não conseguiu reproduzi-la nos testes automatizados, e a issue caiu. Nunca teve dono atribuído.
O WordPress 7.1 saiu a 19 de agosto de 2026, dia de encerramento da WordCamp US em Phoenix. Ginder publicou no mesmo dia: os sites WP Rocket da frota Anchor Hosting ficaram offline depois do salto para o 7.1. Corrigiu o plugin à mão para os trazer de volta.
Mais duas issues no GitHub, 8740 e 8741, chegaram no dia a seguir ao lançamento. O WP Rocket publicou um aviso: não atualize para o 7.1 até haver correção, com um artigo de suporte em docs.wp-rocket.me/article/1927. Mais tarde, a 20 de agosto, lançaram a 3.23.2.2, o cast de uma linha do relatório de julho. A Wordify verificou a correção no mesmo crash que tinha voltado a montar na 3.23.2.1.
O pull no GitHub é wp-media/wp-rocket#8745.
Quem ficou em baixo
Os números da frota de Ginder, a 20 de agosto: 124 de 332 sites de produção a correr WP Rocket em erro fatal, 37 por cento. Todos os erros fatais eram WordPress 7.1 + PHP 8.x + Cloudflare.php.
O post-mortem posterior do WP Rocket, coberto pelo The Repository a 27 de agosto, estimou cerca de 27 por cento da base de utilizadores em risco e cerca de 10 por cento realmente atingidos. O CEO Rémy Lamiot disse que o Elementor Pro, apesar da base instalada e apesar de ser um dos gatilhos, não estava na lista de compatibilidade que testaram. O relatório de julho não tinha dono. “This cost real time and real trust,” escreveu.
Essas duas percentagens não são a mesma medição. Ginder contou uma frota gerida que já corria WP Rocket. O WP Rocket contou a base de utilizadores inteira, incluindo sites que nunca passaram ao 7.1 nessa semana e sites sem o segundo plugin. Cite as duas. Não faça a média.
O primeiro site de cliente da Wordify atualizou o núcleo às 01:55 UTC. O primeiro erro fatal entrou no registo três segundos depois. O suporte desativou o plugin. Cerca de 35 minutos de ponta a ponta, a maior parte em diagnóstico, porque ainda ninguém tinha ligado “7.1” a “WP Rocket.”
Andrew Hoyer escreveu que tinha avisado a equipa sobre o 7.1 e mesmo assim acordou com dezenas de sites partidos. A frase dele: teste alpha, beta e RC no seu próprio stack em vez de confiar no fornecedor. Steve Jones perguntou se as pessoas estavam a atualizar produção na hora em que um major saía, sem rollback. As duas perguntas são o trabalho de um contrato de manutenção. Não são um argumento de marca.
Ordem segura
Se o site ainda está no WordPress 7.0.x e o WP Rocket é anterior a 3.23.2.2:
- Clone para staging.
- Atualize o WP Rocket para 3.23.2.2 em staging. Confirme que o wp-admin e uma página frontal sem sessão carregam.
- Depois passe ao WordPress 7.1 em staging. Bata no login, no checkout se houver WooCommerce, num formulário, no cron.
- Repita a mesma ordem em produção: plugin primeiro, núcleo depois.
Se as atualizações automáticas já levaram o 7.1 e o site está em ecrã branco, não siga a ordem acima. Desative primeiro.
Não reative a 3.23.2.1 no 7.1. O artigo de suporte da WP Media é explícito: se não aparecer atualização na lista de plugins, siga o guia de atualização em falta. Reativar a versão partida deita o site abaixo outra vez.
Builds muito antigas do WP Rocket, anteriores ao ciclo do Cloudflare.php, não são afetadas. A Wordify situou a faixa afetada grosso modo entre 3.16 e 3.23.2.1. Se não tiver a certeza, atualize na mesma para 3.23.2.2. É a versão com o cast de string.
| Peça | Versão / data | Papel |
|---|---|---|
| WordPress | 7.1 Mary Lou, 19 Aug 2026 | Passou os IDs de hook para spl_object_id (Trac 65919) |
| PHP | 8.x com strict_types=1 no ficheiro do plugin | Chave inteira em substr() é TypeError, não um aviso |
| WP Rocket | 3.16 até 3.23.2.1 | Cloudflare.php:562 percorre chaves de hook no init |
| WP Rocket | 3.23.2.2, 20 Aug 2026 | Cast de string de uma linha a partir da GitHub 8596 |
| Plugin gatilho | Elementor Pro, CF7 Redirection, outros | Closure em deleted_post ou transition_post_status |
Já cobrimos o que o 7.1 realmente entregou, e o que cortou, na nota do roteiro do WordPress 7.1. O editor de artigos em iframe é uma quebra de programador à parte. Os pormenores estão na nota do editor em iframe. Este texto trata só do erro fatal do Rocket.
Se o wp-admin já está em ecrã branco
Não apague o Cloudflare.php. Wordify: a classe está ligada ao contentor do plugin, e remover o ficheiro troca este erro fatal por outro.
WP-CLI. O WP-CLI carrega plugins, por isso um wp plugin deactivate wp-rocket nu morre. Salte o plugin enquanto o desativa:
wp plugin deactivate wp-rocket --skip-plugins=wp-rocketSFTP. Mude o nome de wp-content/plugins/wp-rocket para wp-rocket.off. O WordPress trata uma pasta com o nome mudado como desativada no pedido seguinte.
Depois atualize para 3.23.2.2 a partir do wp-admin, que já está vivo outra vez, e reative.
Recuar para 7.0.4 a partir de uma cópia de segurança anterior à atualização também restaura o site. É o caminho mais lento. Deita fora os ficheiros 7.1 que já escreveu em disco. Use-o quando não chega ao SFTP nem ao WP-CLI.
Uma cache de páginas ao nível do alojamento (LiteSpeed, nginx FastCGI, cache Cloudflare de HTML) pode continuar a servir a última página boa a visitantes anónimos enquanto o wp-admin está morto. Isso esconde a interrupção a parte dos clientes e atrasa o ticket. Veja o registo de erros, não só a homepage.
Como testamos um salto do núcleo
A WPPoland (Mariusz Szatkowski) trata um major como uma verificação em três camadas, não como um evento de calendário.
O staging é um clone, não uma subpasta em produção. O mesmo PHP, a mesma object cache, os mesmos plugins. Primeiro levamos as atualizações de plugin com incompatibilidade conhecida. Para o 7.1 essa lista começou no WP Rocket 3.23.2.2. Depois o núcleo. Depois uma lista de testes de fumo: login, um guardar no editor de artigos (agora sempre em iframe), carrinho e checkout WooCommerce se o site os tiver, um POST de formulário, uma corrida de cron.
Num clone típico de loja portuguesa essa lista de testes de fumo não pára no checkout genérico. Depois do salto do núcleo corremos o callback IfthenPay com um payload de teste assinado, e geramos uma referência MB Way no sandbox do banco aderente. É o mesmo smoke da ronda semanal de manutenção WordPress. Um TypeError no init mata o checkout antes de qualquer gateway responder. Um 200 no login não prova que o Multibanco ainda emite referências, nem que o SMS do MB Way ainda é aceite pela app.
Não confiamos em “o WP Rocket disse que testou o 7.1.” Testaram. A suíte deles falhou a chave inteira mais uma closure de um segundo plugin. A instalação limpa de Ginder não deu este erro. A combinação deu. A combinação é o que um site de cliente realmente é. Loja WooCommerce com Elementor Pro, WP Rocket e IfthenPay é exatamente essa combinação, só que o segundo plugin aqui também gera referências MB Way.
Em produção mantemos uma cópia de segurança com nome, de antes do salto, e uma janela de 15 minutos em que alguém está a olhar para o registo de erros, não só para o ping de uptime. Uma homepage em ecrã branco com um 200 vindo da cache HTML não é um passe.
Um clone típico nesta casa é WordPress + WooCommerce ou Elementor + WP Rocket + um plugin de formulário. É a combinação que Ginder e a Wordify descreveram. Não esperamos pelo tweet do fornecedor a dizer “testámos o 7.1.” Levamos o 7.1 no clone, pedimos / e /wp-admin/, e fazemos grep no registo PHP por TypeError e Cloudflare.php. Se o registo está calado e os dois URLs devolvem 200 sem saltar plugins, o salto pode ir para produção na mesma ordem.
A versão de PHP faz parte do clone. O TypeError é uma falha de tipos estritos do PHP 8. Um alojamento ainda em PHP 7.4 não lançaria este erro fatal em concreto. Isso não é razão para ficar no 7.4. É razão para testar 8.2 ou 8.3 com o mesmo conjunto de plugins que corre em produção, não com um WordPress nu.
É o contrato de manutenção de sites WordPress num parágrafo. Staging primeiro. Plugin primeiro quando o fornecedor tem um pin. Núcleo depois. Verificação de saúde no fim. Orçamento por escrito após um brief curto.
Se a superfície pública já está em Cloudflare Workers ou Pages, o erro fatal PHP mesmo assim mata o wp-admin e qualquer rota de origem. A cache HTML no edge não substitui um plugin que dá erro fatal no init. O pilar Cloudflare edge é a camada de entrega. Este incidente é a camada de origem.
Atualizações automáticas e 7.1.1
A Wordify avisou que as atualizações automáticas do 7.1 estavam a rolar na mesma semana. Um site que ninguém tocou podia na mesma passar de bem para em baixo de um dia para o outro.
Adam Silverstein abriu o Trac 65920 a 20 de agosto: um fluxo GitHub Actions para testar os 100 plugins de topo do diretório contra WordPress ainda não lançado. Rascunho de pull request 13198, marcado para o 7.2. Notou no ticket que este incidente exato não teria sido apanhado, porque o WP Rocket é premium e a API do diretório cobre plugins gratuitos. A mesma classe de erro fatal por mudança de tipo pode na mesma atingir um plugin gratuito com milhões de instalações. É esse o ponto do fluxo.
Aaron Jorbin pediu voluntários para gerir o 7.1.x. O 7.1.1 ficou apontado entre 1 e 24 de setembro de 2026. Trate o 7.1.1 da mesma forma: staging, depois produção. Se as chaves inteiras do 65919 ganharem um shim de compatibilidade no 7.1.1, isso é seguro extra. Não é razão para saltar a 3.23.2.2.
Jeffrey Paul apoiou o ticket de Silverstein: erros fatais repetidos depois de majors estão dentro da esfera de preocupação do núcleo, mesmo quando o ficheiro partido vive num plugin. Essa é a divisão honesta. O núcleo pode testar plugins do diretório. O núcleo não pode testar plugins premium que não tem. O dono do site, ou a pessoa no contrato de manutenção, continua a ser dono do clone.
O que não estamos a afirmar
Não estamos a dizer para deitar fora o WP Rocket. A 3.23.2.2 é a build atual com o cast. Os plugins de cache continuam a justificar-se em origens PHP.
Não estamos a dizer para saltar o WordPress 7.1. A estilização responsiva, os media do lado do cliente, a barra de administração persistente e o editor em iframe saíram. A nota do roteiro lista o que entrou e o que não entrou.
Não estamos a citar os preços do WP Rocket. As licenças de terceiros são a lista deles. O nosso trabalho de manutenção tem orçamento individual.
Não estamos a inventar uma por centoagem para “a internet inteira.” Os 37 por cento de Ginder são uma frota. Os 10 por cento do WP Rocket são a estimativa da base de utilizadores deles. As duas têm fonte. Nenhuma é um censo.
Última atualização a 1 de setembro de 2026. Fontes: The Repository (21 e 27 de agosto de 2026), o texto com stack trace da Wordify (20 de agosto), a issue 8596 e o pull 8745 no GitHub, Trac 65919 e 65920, o changelog do WP Rocket 3.23.2.2 e o artigo de suporte 1927, Austin Ginder no X, citações do post-mortem de Rémy Lamiot via The Repository.
