När jag arbetar med ett projekt har jag ofta WordPress inställt i felsökningsläge och jag gillar att skriva meddelanden till felloggen som jag enkelt kan se, spåra och följa när jag arbetar med ett projekt.
När jag gör detta finns det två sätt (och det beror bara på projektet):
- Jag kommer att använda ett bibliotek som Monolog ,
- Jag kommer att använda min egen enkla loggfunktion.
I det här inlägget ska jag ta upp det senare. Det vill säga, jag ska dela med mig av hur jag skriver meddelanden till WordPress felsökningsloggen och sedan några av de saker du kan behöva vara uppmärksam på när du gör detsamma.
WordPress felsökningslogg
Först är det viktigt att notera att funktionen jag ska dela är vanligtvis i en basklass.
Låt oss säga att jag har en AbstractSubscriber som alla mina prenumeranter implementerar (som en ScriptAssetSubscriber för att registrera och köa JavaScript-fil).
AbstractSubscriber kommer att inkludera denna funktion så att den kan anropas av alla barnklasser. Funktionen är ganska enkel:
<?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;
}
}Men det finns flera saker med den här funktionen som kan bryta mot en princip eller utlösa fel i kodkvalitetsverktyg.
Valfria booleska argument
Närhelst en funktion accepterar ett valfritt booleskt argument, kan det indikera att en funktion har mer än ett ansvar (och därmed bryter mot principen om ett enda ansvar ).
Anledningen till att detta skulle bryta mot nämnda princip är att det ger en modul mer än en anledning att byta.
Jag är bekväm med att tillåta detta att skrivas på det här sättet eftersom jag använder det för felsökning, inte för produktionsmiljöer, och för att det finns tillfällen då jag kanske vill stoppa körningen, och det finns tillfällen jag inte gör det.
Och visst, jag skulle kunna skriva två separata funktioner, men om det här är den enda funktionen som gör detta, är jag okej med det.
Uttalanden om förbjudna utträden
Andra kodkvalitetsverktyg ogillar exit – satsen (och på samma sätt ogillar de die- satsen). Och det är förståeligt: De stoppar vanligtvis programmet helt när vi borde göra ett undantag, returnera ett värde eller i allmänhet göra något för att hantera situationen på ett graciöst sätt.
Men igen, eftersom det i den här funktionen finns tillfällen då jag vill stoppa exekveringen, är jag okej att hantera konsekvenserna av att ha kodraden i funktionen.
Alternativt kan jag använda wp_die(), och de flesta kodkvalitetsverktyg skulle förmodligen inte fånga det, men det maskerar huvudproblemet. Om något, kanske det är bäst att bara undertrycka varningen genom att använda det direktiv som din valfria sniffer tillåter.
Oavsett, logga meddelandet
Ytterst är syftet med funktionen ovan att tillhandahålla ett enkelt sätt att skriva till WordPress felsökningsloggen och eventuellt stoppa körningen av programmet när du gör det.
Det är uppenbarligen inte problemfritt, och det finns bibliotek av högre kvalitet som finns tillgängliga, men ibland behöver du inte en slägga för en problemhäftstift.