O site deixou de abrir e mostra um ecrã branco, ou a linha «Ocorreu um erro crítico neste site». São duas caras do mesmo problema, alguma coisa dentro do WordPress partiu, e resolvem-se da mesma maneira.
|
O ecrã branco é a versão antiga. Até ao WordPress 5.2, um erro fatal deixava a página em branco sem explicação. A partir do 5.2 aparece a mensagem de erro crítico, que é a mesma avaria com melhores maneiras. Se ainda vê branco, provavelmente está numa versão velha, e isso, por si só, já é um problema de segurança.
|
|
Antes de mexer seja no que for, tenha caminho de volta. Todos os passos abaixo alteram ficheiros do site. Faça primeiro uma cópia: como restaurar os seus dados com o JetBackup. Sem ela, um passo errado transforma um site partido num site perdido.
|
Comece pelo e-mail: o modo de recuperação
Isto poupa-lhe o resto do artigo mais vezes do que não poupa, e quase ninguém sabe que existe. Quando há um erro crítico, o WordPress envia um e-mail ao administrador com uma ligação especial. Essa ligação abre o painel com o plugin avariado em pausa, e diz-lhe qual é.
| 1 |
Abra a caixa do endereço de administração do WordPress. Procure por «O seu site está com um problema técnico» ou «Your site is experiencing a technical issue». Veja também no lixo e no spam.
|
|
| 2 |
Abra a ligação do e-mail. Ela entra no painel por si e o WordPress diz-lhe o nome do culpado.
|
|
| 3 |
Desactive ou actualize esse plugin e saia do modo de recuperação.
|
|
Qual é o endereço que recebe esse e-mail? Não é o do seu utilizador. É o que está em Opções › Geral › Endereço de e-mail de administração. Em sites antigos esse campo ficou muitas vezes com a morada de quem montou o site há cinco anos. Enquanto o painel não abre não o consegue mudar por lá, mas pode forçá-lo pelo wp-config.php, acrescentando define( 'RECOVERY_MODE_EMAIL', 'voce@asuaempresa.ao' ); por cima da linha que diz para parar de editar. Recarregue a página com erro e o WordPress manda um e-mail novo, agora para si.
|
A ligação do e-mail expira. Se a sua já não funciona, não insista: volte a abrir a página que dá erro e o WordPress gera outra. Enquanto houver erro, há e-mail.
|
|
Se o site não consegue enviar e-mail, o aviso nunca chega. É o caso mais comum de «não recebi nada». Esse e-mail sai do próprio site, e um site que envia mal não consegue avisar-se a si mesmo: porque é que o seu e-mail não sai nem entra. Nesse caso, siga em frente pelo caminho de baixo.
|
Ver o erro sem o mostrar ao mundo
O passo seguinte é fazer o WordPress dizer o que está mal. Há uma maneira certa e uma maneira errada de o fazer.
|
Não ponha os erros no ecrã dos visitantes. Muitos guias mandam pôr o WP_DEBUG a true e deixá-lo assim. Isso escreve as mensagens de erro na página pública, com caminhos de ficheiros e nomes de bases de dados à vista de toda a gente. Num site no ar, é um problema de segurança por cima do que já tinha.
|
A maneira certa manda o erro para um ficheiro. No cPanel abra o Gestor de Ficheiros, entre em public_html, edite o wp-config.php e ponha as três linhas:
| 1 |
define( 'WP_DEBUG', true ); liga o diagnóstico
|
|
| 2 |
define( 'WP_DEBUG_LOG', true ); escreve num ficheiro
|
|
| 3 |
define( 'WP_DEBUG_DISPLAY', false ); e não mostra a ninguém
|
|
Recarregue a página com erro e abra depois o wp-content/debug.log. A última linha nomeia quase sempre o ficheiro culpado, e o caminho diz-lhe se é um plugin ou o tema.
|
E se o debug.log não aparecer? Então o erro aconteceu antes de o WordPress arrancar, e o registo está noutro sítio: o error_log da própria pasta. Ligue os ficheiros ocultos no Gestor de Ficheiros e veja onde está o log de erros do PHP e como se lê.
|
|
Volte a desligar quando acabar. Deixar o diagnóstico ligado enche o disco e guarda informação que não deve ficar por aí. Ponha o WP_DEBUG outra vez a false e apague o debug.log.
|
Quando a página de erro crítico esconde o erro
A partir do WordPress 5.2 há um apanhador de erros fatais que intercepta a avaria e mostra a página educada. É bom para o visitante e mau para quem está a diagnosticar, porque a mensagem verdadeira fica escondida. Para a ver em cru, e só durante o diagnóstico, acrescente ao wp-config.php:
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );
Com o WP_DEBUG_LOG ligado e o WP_DEBUG_DISPLAY desligado, o erro completo vai para o debug.log sem passar pelo ecrã de ninguém. Tire esta linha assim que perceber o que se passa: sem o apanhador, o visitante volta a ver o ecrã branco.
As três causas, por ordem
| Causa |
Como se confirma |
| Um plugin |
De longe a mais comum. Um plugin desactualizado, ou dois que deixaram de se dar bem depois de uma actualização. |
| O tema |
Costuma aparecer logo a seguir a mudar ou actualizar o tema, ou depois de uma actualização do WordPress. |
| Falta de memória |
O log mostra Allowed memory size exhausted. Não é código partido: o site simplesmente não cabe no que tem. |
Desligar plugins sem chegar ao painel
Se o wp-admin também não abre, ainda consegue desligar tudo pelo Gestor de Ficheiros do cPanel, ou por FTP:
| 1 |
Entre em public_html/wp-content.
|
|
| 2 |
Mude o nome da pasta plugins para plugins-off. O WordPress deixa de os encontrar e desliga-os todos de uma vez.
|
|
| 3 |
Abra o site. Se voltou, o culpado é um plugin: reponha o nome plugins e desactive-os um a um no painel até o erro regressar.
|
|
|
O mesmo truque serve para o tema. Mude o nome da pasta do tema activo em wp-content/themes. O WordPress cai num tema de origem, feio mas a funcionar, que é tudo o que precisa para diagnosticar.
|
Falta de memória
Se o log fala de memória esgotada, acrescente esta linha ao wp-config.php, por cima da que diz That’s all, stop editing:
define( 'WP_MEMORY_LIMIT', '256M' );
Se não chegar, o tecto pode ser o do PHP ou o do próprio plano. Os três tectos e a ordem em que mandam estão em limites do PHP: memória, tempo e tamanho de envio.
O site ficou preso em «manutenção»
Sintoma diferente, causa banal: a página diz «Brevemente indisponível para manutenção programada» e não sai dali. Aconteceu uma actualização que foi interrompida a meio. O WordPress cria um ficheiro chamado .maintenance na raiz do site quando começa a actualizar e apaga-o quando acaba. Se a actualização morreu pelo caminho, o ficheiro fica.
| 1 |
No Gestor de Ficheiros, ligue Opções › Mostrar ficheiros ocultos. O nome começa por ponto, por isso está escondido.
|
|
| 2 |
Na pasta do site, normalmente public_html, apague o ficheiro .maintenance.
|
|
| 3 |
Abra o site. Volte a correr a actualização que falhou, uma de cada vez, e veja o resultado de cada uma antes de passar à seguinte.
|
|
Quando nada disto resulta
Reponha uma cópia anterior ao dia em que começou: como restaurar os seus dados. É o caminho mais rápido quando já se foi uma tarde.
E se o erro que vê tem um número, 500, 403, 404, 508, o diagnóstico é outro: erros de site explicados. Se o painel é que não abre mas o site abre, veja não consigo entrar no painel do WordPress. Se o site nunca abriu desde que registou o domínio, veja registei o domínio e ele continua a não abrir. E se o site abre mas arrasta, o problema é outro: o site está lento. Se vê Error establishing a database connection, o caminho é erro de ligação à base de dados: as causas por ordem. E se não sabe por onde começar, o mapa de todos os sintomas está em alguma coisa correu mal no WordPress: por onde começar.
|
Até onde vamos. O servidor, o PHP, os limites e as cópias são nossos. O que vive dentro do WordPress, plugins, tema e o código que lá foi posto, é seu ou de quem lho fez. Ajudamos a perceber de que lado está a avaria: até onde vai o nosso suporte.
|
Português
English
