Menos é mais: limpar e resolver conflitos

Módulo 5: Temas e plugins · Tempo de leitura: 9 minutos

Objetivo de aprendizagem: Depois desta lição, saberá limpar plugins e detetar e resolver sozinho um conflito ou uma página em branco.

Conceitos-chave: desactivar vs eliminar, código inativo, erro crítico, modo de recuperação (recovery mode), Diagnóstico do site, modo de resolução de problemas, mudar o nome da pasta do plugin, WP_DEBUG, WP_DEBUG_LOG, debug.log, registo de erros

Desligar não é deitar fora

Em Plugins, pode desactivar ou eliminar um plugin. A diferença:

• Desactivar: o WordPress deixa de carregar o plugin. Mas os ficheiros continuam em wp-content/plugins/ e, muitas vezes, ainda podem ser pedidos diretamente através do servidor web. Se um ficheiro PHP isolado desse plugin tiver uma falha de segurança, essa falha continua lá. Os atacantes procuram ficheiros vulneráveis conhecidos, não plugins ativos.
• Eliminar: os ficheiros são removidos. Alguns plugins, ao serem eliminados, também apagam as suas definições e tabelas na base de dados; outros deixam-nas ficar.

Se já não utiliza um plugin, elimine-o. Desactivar serve apenas para um curto período (durante a procura de um problema). O mesmo se aplica aos temas (lição 2.4).

Limpar: uma ronda fixa

Reveja os seus plugins uma vez por trimestre (lição 9.4). Para cada plugin:

1. Para que serve? Se já não se lembra, descubra. Muitas vezes, um plugin foi instalado para uma única coisa e nunca chegou a ser removido.
2. Ainda é utilizado? Um plugin de slider quando não existe nenhum slider no site, um plugin de formulários quando a página de contacto usa outro formulário.
3. É possível passar sem ele? O WordPress, o tema ou outro plugin já fazem o mesmo (lição 5.3)?
4. Ainda tem manutenção? Quando foi atualizado pela última vez, ainda está no diretório de plugins?

Faça a limpeza primeiro no ambiente de testes (staging) (lição 8.3), ou faça pelo menos uma cópia de segurança, e elimine um plugin de cada vez, para saber o que correu mal se algo correr mal. Atenção aos shortcodes: se eliminar um plugin que fornecia [formulier id="2"], esse texto passa a aparecer literalmente na sua página.

Quando algo corre mal: o erro crítico

Depois de uma atualização, de um novo plugin ou de uma atualização de PHP, vê de repente:

Ocorreu um erro crítico neste site.

ou uma página completamente em branco. Isso significa que o PHP parou com um erro fatal antes de haver uma página (lição 1.2). Normalmente, a causa é um plugin ou tema que não é compatível com outra coisa: outro plugin, a nova versão do WordPress ou a versão de PHP.

Desde o WordPress 5.2, o WordPress faz então duas coisas:

• envia um e-mail para o endereço do administrador com o plugin ou tema que provocou o erro e uma ligação especial;
• com essa ligação, inicia sessão no modo de recuperação (recovery mode): a administração funciona, com o plugin que provocou o erro temporariamente desligado, para que o possa atualizar, substituir ou eliminar.

Por isso é tão importante ter um endereço de administrador que realmente lê (lição 2.2).

Procurar por conta própria: os passos

Não recebeu nenhum e-mail, ou o modo de recuperação não funciona? Eis como encontrar a causa sozinho.

1. Consulte o registo de erros

O erro aparece quase sempre no registo de erros do servidor web ou do PHP. No DirectAdmin, encontra-o nos registos do seu domínio. Procure uma linha com PHP Fatal error e a hora da sua tentativa:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

O caminho indica-lhe o culpado: neste caso, o plugin na pasta oude-slider. O resto da linha diz porquê (aqui: uma função que foi removida no PHP 8, lição 8.4).

2. Ative o registo de depuração (não a apresentação no ecrã)

Se o registo de erros não tiver nada de útil, adicione ao wp-config.php (acima da linha que diz para parar de editar, «stop editing»):

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

O WordPress passa então a escrever todos os erros em wp-content/debug.log, sem os mostrar aos visitantes. Nunca deixe isto ativo mais tempo do que o necessário: o debug.log fica numa pasta que o servidor web disponibiliza e quem souber o endereço pode lê-lo. Contém caminhos, por vezes nomes de utilizador e outras informações úteis para um atacante. Desative-o depois da procura e elimine o debug.log. Em alternativa, faça o WordPress escrever o ficheiro de registo fora da pasta web, indicando um caminho em WP_DEBUG_LOG (por exemplo '/home/gebruiker/logs/wp-debug.log', se o seu fornecedor de alojamento o permitir). Na lição 7.4 verifica que o debug.log não está público.

3. Desligar um plugin sem a administração

Se não conseguir entrar na administração, desligue o plugin suspeito mudando o nome da sua pasta, através do Gerenciador de arquivos ou por SFTP:

wp-content/plugins/oude-slider   passa a   wp-content/plugins/oude-slider-uit

O WordPress deixa de encontrar o plugin e desliga-o. Se não souber qual é, mude o nome de toda a pasta plugins para plugins-uit: todos os plugins ficam desligados. Se o site voltar a funcionar, crie uma nova pasta plugins vazia, volte a colocar os plugins um a um e verifique após cada plugin se o erro regressa. Com um tema passa-se o mesmo: mude o nome da pasta do tema ativo e o WordPress recorre a um tema predefinido, se ainda existir algum (lição 2.4).

4. Conflitos sem erro fatal

Nem todos os problemas são um erro crítico. Por vezes, há apenas uma função que não funciona: um botão que não faz nada, um formulário que não envia, um editor que carrega só metade. Nesse caso, trata-se muitas vezes de um conflito entre dois plugins ou entre um plugin e o tema. Para isso, o plugin oficial Health Check & Troubleshooting é útil: no modo de resolução de problemas, desliga todos os plugins e muda para um tema predefinido apenas na sua sessão, enquanto os visitantes continuam a ver o site normal. Depois, ative-os um a um até o problema voltar a aparecer.

Consulte também a consola do seu navegador (F12): os erros de JavaScript indicam muitas vezes o ficheiro e, com isso, o plugin.

Diagnóstico do site

Em Ferramentas > Diagnóstico do site, o próprio WordPress verifica o seu site: versão de PHP desatualizada, plugins e temas inativos, extensões de PHP em falta, uma REST API que não funciona, tarefas agendadas em atraso. No separador Informação encontra todos os dados da sua instalação (versões, caminhos, definições de PHP). Pode copiar esse separador e enviá-lo quando pedir ajuda. Dê uma vista de olhos aqui depois de cada alteração importante.

Resumo

• Desactivar deixa os ficheiros no servidor; elimine os plugins e temas que não utiliza.
• Faça a limpeza todos os trimestres, um plugin de cada vez, com uma cópia de segurança ou no ambiente de testes (staging).
• Num erro crítico, o WordPress envia um e-mail com uma ligação para o modo de recuperação.
• O registo de erros ou o debug.log indica o caminho do culpado; desative a depuração depois da procura, caso contrário o debug.log fica público.
• Sem acesso à administração, desliga um plugin mudando o nome da sua pasta; os conflitos procuram-se com o modo de resolução de problemas.

Questionário

Exercício

Exercício A5.4: O seu registo de depuração não está público? Introduza o endereço do seu site e prove, com o código que o exercício lhe fornece, que o site é seu (um registo TXT ou um pequeno ficheiro). O programa pede /wp-content/debug.log: o resultado é bom se o ficheiro não existir ou se o acesso for recusado (404 ou 403). Se o programa receber um ficheiro, o resultado fica a vermelho. Além disso, o programa conta quantas pastas de plugins diferentes aparecem no HTML da sua página inicial (apenas a título informativo).

Exercício D5.4: Organizar a sua lista de plugins. Faça uma lista de todos os seus plugins (ativos e inativos): nome, para que serve, ainda é necessário (sim/não), alternativa sem plugin. Elimine (depois de uma cópia de segurança ou no ambiente de testes (staging)) os plugins que já não são necessários, um de cada vez, e verifique após cada eliminação se o site continua a funcionar. Indique quantos plugins tinha e quantos restam, e anote se ficaram shortcodes que teve de limpar.

Leitura adicional

Estes artigos descrevem os passos nos painéis da WebOké; noutros painéis, funcionam de forma semelhante.

• Manual DirectAdmin 18.1: O meu site está em branco ou apresenta um erro 500
• Erro 500 ou "erro crítico" no seu website (também após uma atualização do WordPress)
• Manual DirectAdmin 14.6: Erros após uma atualização do PHP e como encontrar o log de erros
• Manual DirectAdmin 17.2: Estatísticas e logs dos domínios: o log de erros e o log de acesso
• Como posso depurar PHP sem alterar o php.ini?
• Depuração no WordPress (developer.wordpress.org, em inglês): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• Escolher, avaliar e limpar plugins do WordPress