A trilogia para um debug seguro e eficaz no WordPress

Ter um debug seguro é ter um processo de depuração do código. Isso amplifica a qualidade final do produto e eleva a interoperabilidade com o ecossitema do WordPress, ou seja, o core, os plugins em questão e o tema em uso.

É sabido que cada instalação do WP é recheada com plugins para agregar funcionalidades diversas e um tema para interação pública. Isso traz uma variedade de códigos, padrões e desafios.

Portanto, considere o desenvolvimento dos seus projetos com o debug ativo e revisado para evitar os erros ocultos, os avisos e alertas e as advertências de códigos.

Na correria, ou na falta de planejamento do desenvolvimento, o debug é deixado de lado, qualidade e segurança passam batidos e, lamentalvelmente, chegam à produção um código ruim, inseguro e falho.

Um debug seguro depende de ter um processo de depuração de código. Como você tem lidado com isso?

Tweet

Debug seguro: as três constantes e duas funções

De forma nativa temos um sistema de debug que, por padrão, vem desativado.

Além da possibilidade da ativação, temos capacidades ocultas para um poderio e segurança maior do mecanismo.

A constante WP_DEBUG

O debug do WordPress é ativado através da constante WP_DEBUG arquivo wp-config.php.

define( 'WP_DEBUG', false ); // Por padrão vem desativado
define( 'WP_DEBUG', true ); // Considere o valor true para ativar

As outras possibilidades de configuração para um debug seguro são as seguintes:

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

A constante WP_DEBUG_LOG

Através da constante WP_DEBUG_LOG com o valor true teremos todos os avisos e alertas, erros, e as advertências de códigos salvas em um arquivo chamado debug.log que é localizado em /wp-content/debug.log.

Este arquivo deve ser revisado com periodicidade e deve ser realizada uma análise das inconsistências de todos os códigos da aplicação e assim levar ao conhecimento da equipe para a solução.

Além de ser um grande aliado para análises de situações fora da tela em que o processamento acontece em requisições AJAX e o recurso de Cron do WordPress, por exemplo.

A contante WP_DEBUG_DISPLAY

O valor true e/ou false podem e devem ser considerados para a constante WP_DEBUG_DISPLAY.

Seu valor padrão é true e assim faz com que os erros sejam exibidos na tela. Esse mesmo valor deve ser considerado em ambientes de desenvolvimento.

Em ambientes de produção a referida constante deve está com o valor false evitando assim a exibição dos erros na tela onde detalhes da aplicação são expostos.

Eu aconselho o uso do valor false para todos os ambientes, mas em conjunto com o valor true para a constante WP_DEBUG_LOG. Desta forma não teremos os erros printados na tela, evitando exposição do ambiente e em alguns casos comprometendo a execução da interface, além de forçar a equipe revisar o arquivo debug.log para análises e correções das inconsistências.

Os valores das contantes alinhados às configurações do PHP

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); 
@ini_set( 'log_errors', 'On' ); 
define( 'WP_DEBUG_DISPLAY', false ); 
@ini_set( 'display_errors', 'Off' );

Com essa combinação de constantes e valores garantimos um cenário ideal para um debug seguro e eficaz no WordPress, registrando e armazenando as inconsistências, mas evitando sua exposição.

Atente-se ao uso da função ini_set do PHP, utilizada para definir o valor de uma configuração. É importante seu uso, além da constante do WP, para certificarmos que o comportamento desejado para a aplicação está alinhado com o comportamento do PHP configurado no servidor.

Por exemplo, imagine que o PHP foi configurado para exibir erros, tendo a diretiva display_errors no arquivo php.ini com o valor On e a constante WP_DEBUG_DISPLAY está com o valor false para não exibir erros.

O comportamento configurado no PHP vai sobrepor o do WP, por isso alinhe ambos e evite surpresas.

Além dos erros ocultos, os avisos e alertas e as advertências de códigos

O WordPress modifica, melhora, adiciona e remove novas funções e seus argumentos a cada versão lançada.

Mas há uma política clara de manutenção de códigos legados, tratando segurança e consistência para o uso de novas versões e manutenção de códigos antigos. Portanto, considere manter o WordPress e seus componentes sempre atualizados.

As funções e seus argumentos que ficaram em desuso no WP são tratados de forma especial.

Primeiro que não há quebra e inconsistência. Durante alguns ciclos de lançamentos é mantido uma compatibilidade com o sistema legado.

Segundo que avisos são emitidos quando se faz uso de código em desuso, informando que eles foram modificados na versão x e o correto a ser utilizado a partir de agora é uma outra função/argumento e que, em um futuro não muito distante, a forma de uso deixará de ser suportada.

Esses avisos são registrados no debug.log, permitindo assim a consulta pelo desenvolvedor sobre a nova forma de prosseguir adiante. Ou seja, o WordPress, além de manter a compatibilidade, detalha o código ultrapassado a ser corrigido.

Localização e proteção do arquivo debug.log

Como informado, o arquivo debug.log fica localizado no diretório /wp-content. Esse arquivo em hipótese alguma deve ser público e para isso precisamos protegê-lo.

A correta permissão para o arquivo

Considere a permissão 600 para o arquivo debug.log que permitirá a leitura e gravação do core do WordPress e seus plugins ao arquivo.

Uma contribuição do .htaccess

Além da correta permissão, para quem usa Apache, considere uma proteção extra ao arquivo através de diretivas no .htaccess, e bloqueie o arquivo de acessos externos através do navegador de internet, por exemplo, quando alguém tentar acessar dominio-do-site.com/wp-content/debug.log.

<Files debug.log> 
 Order allow,deny 
 Deny from all
</Files>

Considere o uso do mecanismo de debug padrão do WordPress, mas faça uso de forma segura através das contantes e funções corretas para isso.

Garanta segurança e maior qualidade dos códigos desenvolvidos e atualizados da plataforma. Um debug eficiente e bem estruturado contribui com a segurança para WordPress.