WordPress 7.0 quebrou o site? Diagnóstico e rollback seguro

O site quebrou depois da atualização: respire, o conserto quase nunca é o core

Você clicou em “Atualizar agora”, a barra andou, e na volta o site mostra “Houve um erro crítico neste site”, ou uma tela branca, ou o editor abre sem o estilo do tema. A primeira reação é culpar a versão nova e querer voltar para a anterior. Às vezes é isso mesmo. Na maioria das vezes, porém, o WordPress 7.0 quebrou o site só no sentido de ter exposto um plugin, um tema ou uma versão de PHP que já estava no limite.

Este guia segue a ordem que economiza tempo: primeiro descobrir o que quebrou (sintoma → causa), depois entrar pelo modo de recuperação ou pelo terminal, e só no fim, se o problema for mesmo a versão do núcleo, fazer o rollback com um comando, para a versão certa. Porque existe versão errada para voltar, e ela é a que a maioria dos tutoriais recomenda.

Primeiro: em que ponto da linha do tempo você está

O WordPress 7.0 “Armstrong” saiu em 20 de maio de 2026. Depois vieram o 7.0.1 (9 de julho, 31 correções no núcleo e no editor de blocos), o 7.0.3 e o 7.0.4 (atualizações de segurança de 7 e 12 de agosto), o 7.1 “Mary Lou” (19 de agosto), o 7.1.1 em 17 de setembro (17 correções no núcleo, 19 no editor e 11 de segurança) e o 7.1.2 em 22 de setembro, que corrige uma vulnerabilidade de gravidade crítica, segundo o anúncio em br.wordpress.org.

Isso importa por um motivo prático: a API oficial de versões do WordPress (api.wordpress.org/core/stable-check), consultada hoje, 29 de setembro de 2026, classifica assim:

Em outras palavras: voltar “para a versão anterior que funcionava”, sem olhar o número, pode colocar o site numa versão marcada como insegura, justo quando o 7.1.2 acabou de fechar uma falha crítica. Confira você mesmo antes de decidir:

# Versao instalada (rode na pasta do WordPress)
wp core version

# Classificacao oficial de cada versao (latest / outdated / insecure)
curl -s https://api.wordpress.org/core/stable-check/1.0/ | tr ',' 'n' | grep -E '"(6.9|7.)'

O que o 7.0 mudou de verdade, e onde cada mudança quebra

O Field Guide oficial do WordPress 7.0 lista mais de 419 tickets fechados. A maioria é invisível. Estas são as mudanças que, na prática, viram chamado de suporte:

Repare que nenhuma linha da tabela se resolve com rollback de forma definitiva. O rollback compra tempo; o conserto está no plugin, no tema ou no PHP. E vale lembrar que o 7.0.1 já corrigiu regressões do lançamento, entre elas um bug no wp_kses() que podia gerar atributo style inválido em CSS inline de imagem de fundo. Se você está parado no 7.0 puro, o primeiro passo é atualizar, não voltar.

Diagnóstico por sintoma: comece pelo que está na sua tela

Para os dois primeiros casos você precisa ver a mensagem de erro real. O caminho documentado na documentação oficial de depuração do WordPress é este, no wp-config.php, antes da linha “That’s all, stop editing”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );          // grava em wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );     // nao mostra o erro ao visitante
@ini_set( 'display_errors', 0 );

Recarregue a página que quebra e abra o debug.log. A linha que importa começa com PHP Fatal error e termina com o caminho de um arquivo: se o caminho passa por wp-content/plugins/nome-do-plugin/, você já sabe quem é o culpado, e não é o WordPress 7.0. Desligue o log quando terminar: deixar WP_DEBUG ligado em produção é convite para vazar caminho de arquivo.

Modo de recuperação: o botão de emergência que já vem no WordPress

Desde a versão 5.2, quando o WordPress detecta um erro fatal num carregamento normal de página, ele mostra a mensagem de erro crítico ao visitante e envia um e-mail ao administrador com um link secreto de modo de recuperação. Pelo link, você entra no painel com o plugin ou tema problemático pausado só para a sua sessão: o site continua quebrado para o público até você agir, mas você consegue entrar para desativar o culpado sem FTP. A documentação do modo de recuperação descreve o fluxo completo.

Três detalhes que quase ninguém conta e que explicam por que o e-mail “não chegou”:

1. O e-mail tem limite de frequência. No código do núcleo, o intervalo padrão entre envios é de um dia (DAY_IN_SECONDS, ajustável pelo filtro recovery_mode_email_rate_limit), e o link vale pelo menos esse mesmo período. Se você já recebeu um e-mail ontem de manhã e apagou, o próximo pode não vir hoje.
2. O e-mail pode sair sem o seu plugin de SMTP. Se o erro fatal acontece antes de o plugin de envio carregar, a mensagem sai direto do servidor, e servidor com IP mal avaliado cai em spam ou é bloqueado. Olhe a caixa de spam do e-mail do administrador.
3. Algumas hospedagens desligam o recurso inteiro com a constante WP_DISABLE_FATAL_ERROR_HANDLER. Nesse caso você vê tela branca em vez da mensagem de erro crítico, e nenhum e-mail sai.

Para receber o aviso num endereço que você realmente lê, defina no wp-config.php:

define( 'RECOVERY_MODE_EMAIL', 'seu-email-tecnico@seudominio.com.br' );

Dentro do modo de recuperação, o painel mostra um aviso apontando qual extensão falhou. Desative-a em Plugins ou em Aparência → Temas, confira o site, e clique em “Sair do modo de recuperação” na barra do topo.

Sem e-mail e sem painel: WP-CLI ou gerenciador de arquivos

Se você tem acesso SSH, o WP-CLI permite rodar comandos sem carregar os plugins, o que contorna o erro fatal:

# Lista plugins sem executar nenhum deles
wp plugin list --status=active --skip-plugins --skip-themes

# Desativa o suspeito (troque pelo slug que apareceu no debug.log)
wp plugin deactivate nome-do-plugin --skip-plugins --skip-themes

# Se o suspeito for o tema, troca por um tema padrao instalado
wp theme list --skip-plugins --skip-themes
wp theme activate twentytwentyfive --skip-plugins --skip-themes

Sem SSH, o método documentado pelo próprio WordPress é renomear a pasta do plugin pelo FTP ou pelo gerenciador de arquivos da hospedagem: wp-content/plugins/nome-do-plugin vira nome-do-plugin-off. O WordPress não encontra o plugin, desativa, e o site volta. Não sabe qual é? Renomeie a pasta plugins inteira para plugins-off, confirme que o site volta, restaure o nome e desative um por um até achar.

Rollback do núcleo: quando faz sentido e como fazer sem cair em versão insegura

Quando o WordPress 7.0 quebrou o site e o culpado é mesmo o núcleo, o rollback é a resposta certa. Isso acontece em um único cenário: você desativou plugins, trocou para um tema padrão, o erro continua, e o log aponta para arquivos de wp-includes ou wp-admin. Ou então um plugin crítico para o negócio (loja, área de membros) ainda não é compatível e você precisa de alguns dias até o autor lançar a correção.

O comando oficial está na referência do wp core update: a opção --version escolhe a versão e --force permite instalar uma versão menor do que a atual.

# 1) Backup do banco ANTES de qualquer coisa
wp db export antes-do-rollback.sql

# 2) Volta para a ultima versao corrigida do ramo anterior
wp core update --version=6.9.9 --force

# 3) Confere se os arquivos do nucleo batem com os oficiais
wp core verify-checksums

# 4) Confirma a versao
wp core version

Pontos de atenção que evitam o segundo problema do dia:

• Escolha o número pela tabela da API, não pela memória. Hoje, 6.9.9 para quem veio do ramo 7.0, e 7.0.6 para quem veio do 7.1. Qualquer 6.9.x abaixo de 6.9.9 está marcado como inseguro.
• O banco de dados não volta junto. O comando troca os arquivos do núcleo; se a atualização rodou rotinas de banco, elas continuam lá. Se você tem um backup completo feito imediatamente antes da atualização, restaurar arquivos e banco juntos é o rollback mais limpo.
• Segure a atualização automática enquanto investiga. Com define( 'WP_AUTO_UPDATE_CORE', 'minor' ); no wp-config.php, o site continua recebendo as correções de segurança do ramo em que está, mas não pula sozinho para o ramo novo durante a investigação.
• Plugins de rollback de núcleo resolvem para quem não tem terminal, mas aplique a mesma regra: escolha a versão pela tabela de segurança.

Rollback é torniquete, não tratamento

Mesmo quando o WordPress 7.0 quebrou o site por culpa do núcleo, o rollback não é destino. Ficar numa versão “outdated” é aceitável por dias, não por meses. O 7.1.1 trouxe 11 correções de segurança e o 7.1.2 fechou uma vulnerabilidade crítica; cada semana parado no ramo antigo é uma semana dependendo de a equipe do núcleo continuar portando correções para trás. O plano de saída é simples:

1. Monte uma cópia de teste do site (a maioria das hospedagens tem botão de staging).
2. Atualize a cópia para a versão mais recente e reproduza o erro com o log ligado.
3. Atualize, substitua ou remova o plugin culpado na cópia até o erro sumir.
4. Repita no site real, na mesma ordem: primeiro o plugin, depois o núcleo.
5. Volte o WP_AUTO_UPDATE_CORE para o valor anterior.

Se o motivo do rollback foi segurança da informação, e não só compatibilidade, vale reler o que já cobrimos sobre as versões recentes: o que fazer na chegada do WordPress 7.1, as 12 correções do WordPress 7.0.3 e o caso da falha crítica wp2shell, que mostra por que ficar numa versão insegura custa caro.

Checklist para a próxima atualização grande não virar incidente

• Confira a versão de PHP antes do núcleo. A tabela oficial de compatibilidade PHP × WordPress mostra que o 7.0 e o 7.1 rodam do PHP 7.4 ao 8.5. Estar dentro da faixa do núcleo não garante que os plugins acompanhem.
• Backup de arquivos e banco com data e hora, feito minutos antes, não “o da semana passada”.
• Atualize plugins e tema primeiro, núcleo depois. Autores costumam lançar compatibilidade antes da versão maior do WordPress sair.
• Deixe o RECOVERY_MODE_EMAIL apontado para um endereço técnico que você lê, e teste se o servidor entrega e-mail.
• Mantenha a lista de plugins enxuta. Cada plugin é um ponto de falha a mais em toda atualização; o nosso checklist de hardening do WordPress trata disso como trava de segurança, e ela vale igual para estabilidade.
• Atualize em horário de pouco tráfego e com o log de erros do PHP à mão.

E se o que você encontrou no log não foi incompatibilidade, e sim arquivo estranho, usuário administrador que você não criou ou redirecionamento para outro domínio, o problema não é a atualização: é invasão. Nesse caso, siga o roteiro de como limpar um site WordPress invadido antes de qualquer rollback, porque voltar a versão com o invasor dentro só troca a porta de lugar.