Sempre que estou trabalhando em um projeto, geralmente tenho o WordPress definido no modo de depuração e gosto de escrever mensagens no log de erros que posso visualizar, rastrear e seguir facilmente sempre que estou trabalhando em um projeto.
Quando eu faço isso, existem duas maneiras (e só depende do projeto):
- Vou usar uma biblioteca como Monolog ,
- Usarei minha própria função de log simples.
Neste post, vou abordar o último. Ou seja, vou compartilhar como escrevo mensagens no log de depuração do WordPress e, em seguida, algumas das coisas que você pode precisar prestar atenção sempre que estiver fazendo o mesmo.
O log de depuração do WordPress
Primeiro, é importante notar que a função que vou compartilhar geralmente está no contexto de uma classe base.
Digamos que eu tenha um AbstractSubscriber que todos os meus assinantes implementam (como um ScriptAssetSubscriber para registrar e enfileirar o arquivo JavaScript).
O AbstractSubscriber incluirá esta função para que possa ser chamada por qualquer classe filha. A função é bem simples:
<?php
/**
* Prints a message to the debug file that can easily be called by any subclass.
*
* @param mixed $message an object, array, string, number, or other data to write to the debug log
* @param bool $shouldNotDie whether or not the The function should exit after writing to the log
*
*/
protected function log($message, $shouldNotDie = true)
{
error_log(print_r($message, true));
if ($shouldNotDie) {
exit;
}
}Mas há várias coisas sobre essa função que podem violar um princípio ou desencadear erros em ferramentas de qualidade de código.
Argumentos booleanos opcionais
Sempre que uma função aceita um argumento booleano opcional, pode indicar que uma função tem mais de uma responsabilidade (violando assim o Princípio da Responsabilidade Única ).
A razão pela qual isso violaria o referido princípio é que dá a um módulo mais de uma razão para mudar.
Estou confortável em permitir que isso seja escrito dessa maneira porque o uso para depuração, não para ambientes de produção, e porque há momentos em que posso querer interromper a execução e há momentos em que não.
E claro, eu poderia escrever duas funções separadas, mas se esta for a única função fazendo isso, estou bem com isso.
Declarações de Saída Proibida
Outras ferramentas de qualidade de código não gostam da instrução exit (e, da mesma forma, não gostam da instrução die ). E compreensivelmente: eles normalmente param o programa quando deveríamos estar lançando uma exceção, retornando um valor ou geralmente fazendo algo para lidar com a situação normalmente.
Novamente, porém, como nesta função há momentos em que quero interromper a execução, estou bem lidando com as consequências de ter a linha de código na função.
Alternativamente, eu poderia usar wp_die(), e a maioria das ferramentas de qualidade de código provavelmente não o pegaria, mas isso está mascarando o problema principal. Se alguma coisa, talvez seja melhor apenas suprimir o aviso usando qualquer diretiva que seu sniffer de escolha permitir.
Independentemente disso, registre a mensagem
Em última análise, o objetivo da função acima é fornecer uma maneira simples de gravar no log de depuração do WordPress e, opcionalmente, interromper a execução do programa ao fazê-lo.
Claramente, não está isento de problemas, e existem bibliotecas de maior qualidade disponíveis, mas às vezes você não precisa de uma marreta para um percevejo problemático.