Você sabe como depurar códigos no WordPress? Codificar aplicativos e websites exige uma depuração constante para garantir qualidade, desempenho e bom funcionamento. Toda linguagem, framework e CMS possuem (ou deveriam possuir) mecanismos para essa finalidade.

O WordPress e seu ecossistema de plugins fornece formas simples e eficazes de depurar códigos. Depurar código é de extrema importância, mas somente em ambiente de desenvolvimento, já que no ambiente de produção a regra é o silêncio.

O que eu quero dizer, é que quando você está criando sua aplicação, codificando seus códigos em sua máquina, você precisa exibir/registrar os erros que ocorrem para atuar sobre eles.

No entanto, quando a aplicação está em uso (publicada), esses mesmos erros devem ser ocultados para o usuário final, uma vez que eles expõem informações sobre seu sistema – como a versão do servidor web, a versão da linguagem, os caminhos físicos do servidor – e que podem ser usadas por usuários mal intencionados.

Como ativar e desativar o recurso de debug no WordPress

Por padrão, o recurso de debugging do WordPress vem desativado. Ele é ativado através de uma constante localizada no arquivo wp-config.php. Essa constante recebe um valor booleano true ou false para ativar ou desativar a funcionalidade, respectivamente.

Veja os exemplos:

Com a opção de debug ativada, os erros serão exibidos na tela. Assim, o desenvolvedor tomará conhecimento da sua existência para atuar em sua correção e, com isso, garantir uma melhor entrega.

Os tipos de erros exibidos

• Mensagens de erros/alertas do PHP informando sobre erros fatais, indexes inexistentes, verificados pelas funções empty(), isset(), entre outros;
• Mensagens de debug do WordPress informando sobre o uso de funções em desuso e
• Mensagens de erro de banco de dados do WordPress – a partir da versão 2.3.2 o WordPress oculta mensagens de erro do banco de dados caso a constante WP_DEBUG esteja com o valor false.

Particularmente não gosto de exibir os erros na tela, mesmo em ambiente de desenvolvimento.

Eu tenho alguns bons motivos para isso. Pense comigo:

• Somos humanos e suscetíveis a erros. Portanto, pode acontecer um deploy com a constante WP_DEBUG com o valor true. Como já disse acima, o resultado é uma exposição de dados sensíveis do ambiente;
• Em requisições AJAX não verei os erros, se existirem. Exceto se ficar monitorando através do Firebug, por exemplo;
• Visualmente é feio e impacta na renderização do site no navegador de internet.

Eu disse que não gosto de exibir os erros na tela, mas gosto muito de depurar códigos e garantir qualidade. Portanto, adiciono outras duas constantes para trabalhar em conjunto a que conhecemos agora. São as constantes WP_DEBUG_LOG e WP_DEBUG_DISPLAY. Respectivamente, atribuo o valor true para uma e false para outra.

Com isso, os erros serão gravados em um arquivo de log, e não exibidos na tela. Esse arquivo se chama debug.log e fica armazenado em /wp-content. Se o Apache – ou o servidor web que estiver em uso – não tiver permissão de escrita, você precisará criar esse arquivo e definir a permissão apropriada que seria o 0666.

Veja um exemplo de código com essas opções ativadas:

Conclusão

Espero que com essas sugestões e exemplos você possa monitorar mais de perto os erros, trabalhar em suas correções e garantir uma melhor entrega de seus trabalhos.

Há outras formas de debugging no WordPress, assim como plugins que nos ajudam nesse quesito, mas por ora conhecemos um bom caminho.