Menos é mais: arrumar e resolver conflitos

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

Objetivo de aprendizagem: Depois desta lição, saberá arrumar os plugins e localizar e resolver você mesmo um conflito ou uma página em branco.

Conceitos-chave: desativar vs eliminar, código inativo, falha crítica, 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 desativar ou eliminar um plugin. A diferença:

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

Se já não utiliza um plugin, elimine-o. Desativar serve apenas para situações temporárias (durante a procura de um problema). O mesmo se aplica aos temas (lição 2.4).

Arrumar: 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, procure saber. É frequente um plugin ter sido instalado em tempos para uma única coisa e nunca mais ter sido removido.
2. Ainda é utilizado? Um plugin de slider quando não há nenhum slider em lado nenhum, um plugin de formulários quando a sua página de contacto usa outro formulário.
3. É possível passar sem ele? O WordPress, o tema ou outro plugin já fazem isso (lição 5.3)?
4. Ainda tem manutenção? Última atualização, ainda está na pasta de plugins?

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

Quando algo corre mal: a falha crítica

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

Ocorreu um erro crítico neste site.

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

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

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

É por isso que um endereço de administração que lê regularmente é tão importante (lição 2.2).

Procurar você mesmo: os passos

Não recebeu nenhum e-mail, ou o modo de recuperação não funciona? Assim é como pode descobrir sozinho.

1. Consulte o registo de erros

O erro está quase sempre no registo de erros do servidor web ou do PHP. No DirectAdmin encontra isso nos registos (logs) 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 quem é o culpado: aqui, o plugin na pasta oude-slider. O resto da linha indica o motivo (neste caso: uma função que foi removida no PHP 8, lição 8.4).

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

Se não houver nada de útil no registo de erros, defina em wp-config.php (acima de "pare de editar"):

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

O WordPress escreve então todos os erros em wp-content/debug.log, sem os mostrar aos visitantes. Nunca deixe isto ativado 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. Nele constam caminhos, por vezes nomes de utilizador e outras informações que ajudam um invasor. Desative-o novamente depois de terminar a procura e elimine o debug.log. Ou faça com que o WordPress escreva 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 alojamento o permitir). Na lição 7.4 verifica se o debug.log não está público.

3. Desativar o plugin sem aceder ao painel

Se não conseguir aceder ao painel, desative o plugin suspeito mudando o nome da sua pasta, através do Gerenciador de arquivos ou de SFTP:

wp-content/plugins/oude-slider   wordt   wp-content/plugins/oude-slider-uit

O WordPress deixa então de encontrar o plugin e desativa-o. Se não souber qual é, mude o nome da pasta inteira plugins para plugins-uit: todos os plugins são desativados. Se o site funcionar então, crie uma nova pasta vazia plugins, volte a colocar os plugins um a um e verifique após cada plugin se o erro volta a ocorrer. Para um tema aplica-se o mesmo: mude o nome da pasta do tema ativo e o WordPress recorre a um tema padrão, se ainda estiver instalado (lição 2.4).

4. Conflitos sem erro fatal

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

Verifique 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 WordPress verifica automaticamente o seu site: versão de PHP desatualizada, plugins e temas que não estão ativos, extensões de PHP em falta, uma REST API que não funciona, tarefas agendadas com atraso. No separador Informações encontram-se todos os dados da sua instalação (versões, caminhos, definições de PHP). Pode copiar esse separador e enviá-lo quando pedir ajuda. Consulte isto depois de cada alteração importante.

Resumo

• Desativar deixa os ficheiros no lugar; elimine os plugins e temas que não utiliza.
• Arrume tudo a cada trimestre, um plugin de cada vez, com uma cópia de segurança ou num ambiente de testes (staging).
• Numa falha crítica, 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 de terminar a procura, pois o debug.log fica público caso contrário.
• Sem acesso ao painel, desativa 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 comprove com o código que o exercício lhe fornece que é o seu próprio site (um registo TXT ou um pequeno ficheiro). O programa solicita /wp-content/debug.log: é positivo se esse ficheiro não existir ou for recusado (404 ou 403). Se o programa receber um ficheiro de volta, isso é assinalado 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 servem, ainda são necessários (sim/não), alternativa sem plugin. Elimine (depois de uma cópia de segurança ou num 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 registe se ficaram shortcodes que teve de arrumar.

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 (mesmo 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, Inglês): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/