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
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.
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 ativarAs outras possibilidades de configuração para um debug seguro são as seguintes:
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );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.
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.
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.
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.
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.
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.
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.
