Página em branco no WordPress: ler o erro antes de mexer no site

«Erro crítico» ou página em branco: a mesma avaria

Uma página em branco é quase sempre um erro fatal do PHP: um ficheiro do site pediu algo impossível, e a execução parou antes de mostrar o que quer que fosse. Desde o WordPress 5.2, o WordPress interceta estes erros: em vez de uma página vazia, mostra «Ocorreu um erro crítico neste site.» e envia um email para o endereço de administração do site.

A página fica totalmente em branco em alguns casos: uma versão mais antiga do WordPress, um erro que ocorre antes de este mecanismo ser carregado, a constante WP_DISABLE_FATAL_ERROR_HANDLER definida como true, ou um plugin de cache que serve uma página vazia guardada durante a avaria. O método que se segue serve para todos estes casos.

Três gestos podem esperar até ter lido o erro: reinstalar o WordPress, eliminar plugins, restaurar uma cópia de segurança antiga. Cada um pode apagar definições ou dados recentes, enquanto a mensagem de erro diz em geral que componente desativar, sem perder nada.

O atalho: o modo de recuperação

Quando o WordPress interceta o erro, envia para o endereço de email de administração do site uma mensagem com o assunto «[Nome do site] Há um problema técnico com o seu site». Nomeia o plugin ou o tema em causa e contém uma ligação que abre a administração em modo de recuperação.

• Neste modo, o componente com erro fica em pausa só para si: os seus visitantes continuam a ver o erro.
• Em Plugins ou em Apresentação > Temas, desative o componente indicado e clique depois em «Sair do modo de recuperação», na barra de administração.
• A ligação é válida durante 24 horas, e o WordPress envia no máximo um email deste tipo por dia. Se o email não chegar, veja na pasta de spam e passe depois ao método seguinte.

Ler o erro: o registo de depuração

Ligue-se ao site por SFTP ou pelo gestor de ficheiros do seu fornecedor de alojamento, abra o wp-config.php na raiz e substitua a linha define( 'WP_DEBUG', false ); por estas quatro linhas:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Colocam-se acima do comentário que fecha a zona editável do ficheiro (/* E é tudo, pare de editar! */ num WordPress instalado em português, pt_PT). Recarregue a página com erro e abra depois wp-content/debug.log. WP_DEBUG_DISPLAY a false guarda as mensagens no ficheiro, fora da página que os seus visitantes veem.

Se o debug.log ficar vazio ou não aparecer, o erro foi registado diretamente pelo PHP: procure um ficheiro error_log na raiz do site ou em wp-admin, ou a secção dos registos de erros no painel do seu fornecedor de alojamento.

O que diz a mensagem, e o gesto que lhe corresponde

Um erro fatal cabe numa linha: o tipo de erro, a descrição, e depois in seguido do caminho completo do ficheiro e do número da linha. O caminho é a informação mais útil: wp-content/plugins/nome/ designa um plugin, wp-content/themes/nome/ um tema.

define( 'WP_MEMORY_LIMIT', '256M' );

Desativar o componente em causa sem a administração

Por SFTP ou pelo gestor de ficheiros

Mude o nome da pasta do plugin indicado na mensagem, por exemplo wp-content/plugins/nome-do-plugin para nome-do-plugin.off. O WordPress deixa de encontrar o plugin e deixa de o carregar; as definições dele continuam guardadas na base de dados, e o WordPress desativa-o na próxima vez que o ecrã dos plugins for aberto.

Para um tema, mudar o nome da pasta em wp-content/themes devolve o acesso à administração, mas os visitantes veem uma página vazia enquanto nenhum tema estiver ativo. Abra logo Apresentação > Temas: o WordPress verifica que o tema ativo está danificado e volta a um tema por omissão instalado.

Com o WP-CLI

wp plugin list --status=active
wp plugin deactivate nome-do-plugin
wp theme list
wp theme activate twentytwentyfive

O primeiro comando guarda a lista dos plugins ativos, útil antes de qualquer desativação em bloco. Se o próprio WP-CLI parar com o erro, acrescente --skip-plugins --skip-themes ao comando: arranca então sem carregar os plugins nem o tema. Os plugins da pasta wp-content/mu-plugins carregam-se na mesma; se o erro vier de um deles, mude o nome do ficheiro.

Quando a mensagem não designa nenhum componente, wp plugin deactivate --all desativa todos os plugins. Se o site voltar, reative-os um a um, recarregando o site entre cada um: o último reativado antes de o erro voltar é o responsável.

Com o site de volta

1. Volte a colocar define( 'WP_DEBUG', false ); e retire WP_DEBUG_LOG do wp-config.php.
2. Elimine wp-content/debug.log: numa pasta acessível a partir da web, pode ser lido por qualquer pessoa e contém caminhos do servidor.
3. Atualize ou substitua o componente em causa, lendo o respetivo registo de alterações.
4. Limpe a cache do plugin de cache e a do fornecedor de alojamento, se existir.
5. Para a próxima vez: teste as atualizações numa cópia do site antes de as aplicar ao site publicado.