Como resolver o editor de blocos do WordPress que não carrega

Na maioria das vezes, um editor de blocos do WordPress que não carrega é um erro de JavaScript — um único script quebrado de um plugin ou tema trava o app React inteiro, e o editor nunca termina de renderizar. Abra o console de desenvolvedor do navegador (F12, ou Cmd+Option+I no Mac), recarregue a tela de edição e leia o erro em vermelho. Quase sempre ele aponta o arquivo que gerou a falha. Essa única linha te diz qual plugin desativar, e normalmente você volta a escrever em menos de cinco minutos. Reinstalar o WordPress, aumentar o limite de memória do PHP e trocar para o Editor Clássico são as três sugestões mais comuns na internet, e as três costumam ser a decisão errada.

Por que o editor quebra do jeito que quebra

O editor de blocos (Gutenberg) é uma aplicação React de página única que roda dentro de wp-admin/post.php e post-new.php. O WordPress enfileira uma pilha de pacotes de script — wp-blocks, wp-element, wp-editor, wp-edit-post — e o app é inicializado por meio de wp.domReady(). O JavaScript para de executar na primeira exceção não tratada. Então, se qualquer script enfileirado gerar um erro enquanto o editor está inicializando, tudo que vem depois dele morre junto. Sua área de texto cuidadosamente escrita vira um painel branco em branco ou a mensagem “O editor encontrou um erro inesperado”.

Por padrão, o WordPress também concatena os scripts do admin em menos requisições. Isso significa que o JS quebrado de um plugin pode arrastar junto scripts sem relação carregados no mesmo pacote, e é por isso que o culpado nem sempre é óbvio só pelo comportamento. Mas no console ele é.

O segundo tipo de falha tem uma cara diferente: o editor carrega, mas ao salvar aparece “Falha ao atualizar. A resposta não é uma resposta JSON válida.” Isso não é um problema de JavaScript. O editor conversa com a REST API em /wp-json/wp/v2/, e espera receber JSON limpo de volta. Se um plugin ou o functions.php do seu tema emite um notice, warning ou fatal do PHP antes do JSON — ou um plugin de segurança bloqueia a rota REST, ou um plugin de redirecionamento reescreve a URL — a resposta fica poluída e o editor não consegue interpretá-la.

Como resolver, do mais rápido para o mais lento

1. Leia o console. Reproduza a falha com o DevTools aberto. Um erro como Uncaught TypeError ... some-plugin/build/index.js aponta diretamente para o plugin problemático. Esse único passo resolve a maioria dos casos e te poupa de ficar testando às cegas.

2. Descarte o navegador. Force o recarregamento (Cmd/Ctrl+Shift+R), depois tente uma janela anônima com as extensões desativadas. Bloqueadores de anúncios e extensões de privacidade às vezes removem scripts do admin. Se funcionar no modo anônimo, o problema é uma extensão do navegador ou cache antigo, não o seu site.

3. Teste a REST API diretamente se você viu a mensagem “não é uma resposta JSON válida”. Acesse https://seusite.com/wp-json/ no navegador. Você deveria receber um monte de JSON. Se receber HTML, um erro 500 ou um redirecionamento para o login, esse é o seu problema — um plugin está quebrando a resposta da REST, não o editor em si.

4. Teste os plugins um a um. Desative todos, confirme que o editor carrega, então reative um de cada vez até quebrar de novo. Se você estiver completamente trancado para fora do wp-admin, faça isso por SFTP renomeando a pasta:

mv wp-content/plugins wp-content/plugins_off

O WordPress desativa tudo quando a pasta some. Renomeie de volta e vá movendo os plugins para dentro e para fora individualmente.

5. Teste o tema. Troque para o Twenty Twenty-Four. Um tema que enfileira JS quebrado do editor ou gera erro de PHP no functions.php produz os mesmos sintomas.

6. Ative o log e leia o erro de verdade. Especialmente para as falhas de REST/JSON, ative a depuração no wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

O fatal é gravado em wp-content/debug.log com o arquivo e o número da linha exatos. Se esse stack trace estiver denso — nomes de classes com namespace, cadeias de require, um fatal enterrado sob dez linhas de trace — cole tudo no nosso decodificador de log de erros do WordPress para ver, em termos simples, qual plugin e qual linha realmente causaram a falha. Essa é a diferença entre “alguma coisa quebrou” e “a linha 214 deste plugin específico está quebrada”.

Se você suspeita que a concatenação de scripts está mascarando o verdadeiro culpado, force cada script a carregar separadamente para que o erro no console aponte para exatamente um arquivo:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

O que não fazer

Não instale o plugin Editor Clássico e ache que resolveu. Ele não conserta nada — apenas esconde o editor de blocos para você parar de ver o erro. O JavaScript quebrado ou a resposta REST quebrada continuam lá, e vão te pegar de novo no editor do site, nos widgets, ou na próxima vez que você atualizar. Diagnostique primeiro; só volte para o Clássico se você fez uma escolha deliberada de parar de usar blocos.

Não aumente o limite de memória do PHP por reflexo. É a correção copia-e-cola preferida da internet, mas um editor em branco raramente é esgotamento de memória. Esgotamento de verdade gera um fatal específico — “Allowed memory size of N bytes exhausted” — que você vai ver no debug.log. Se essa linha não estiver lá, mais memória não muda nada.

Não reinstale o núcleo do WordPress. Os arquivos do núcleo são idênticos byte a byte em toda instalação. Se o núcleo fosse o problema, todo site WordPress do planeta estaria com o editor quebrado agora. A falha quase sempre está nos seus plugins ou no tema, e reinstalar o núcleo corre o risco de sobrescrever coisas sem consertar nada.

Não limpe nem desative o plugin de cache cegamente como primeiro passo. Minificação e concatenação agressivas de JS podem quebrar o editor, então vale testar — mas confira o console antes de sair limpando caches ao acaso. Adivinhar é como uma correção de cinco minutos vira uma tarde inteira.

Ainda travado?

Se o console está limpo, a REST API retorna JSON válido, e um teste completo de plugins e tema ainda deixa o editor morto, a resposta quase sempre está no debug.log. Ative o WP_DEBUG_LOG, reproduza a falha uma vez, e passe o fatal resultante pelo decodificador de log de erros. O stack trace aponta o arquivo — comece por ali.