Immer wenn ich an einem Projekt arbeite, habe ich WordPress oft im Debug-Modus eingestellt, und ich schreibe gerne Nachrichten in das Fehlerprotokoll, die ich einfach anzeigen, verfolgen und verfolgen kann, wenn ich an einem Projekt arbeite.
Wenn ich das mache, gibt es zwei Möglichkeiten (und es hängt nur vom Projekt ab):
- Ich verwende eine Bibliothek wie Monolog ,
- Ich werde meine eigene, einfache Protokollfunktion verwenden.
In diesem Beitrag werde ich auf Letzteres eingehen. Das heißt, ich werde mitteilen, wie ich Nachrichten in das WordPress-Debug-Protokoll schreibe, und dann einige der Dinge, auf die Sie möglicherweise achten müssen, wenn Sie dasselbe tun.
Das WordPress-Debug-Log
Zunächst ist es wichtig zu beachten, dass die Funktion, die ich teilen werde, normalerweise im Kontext einer Basisklasse steht.
Angenommen, ich habe einen AbstractSubscriber, den alle meine Abonnenten implementieren (z. B. einen ScriptAssetSubscriber zum Registrieren und Einreihen einer JavaScript-Datei).
Der AbstractSubscriber enthält diese Funktion, damit sie von allen untergeordneten Klassen aufgerufen werden kann. Die Funktion ist ganz einfach:
<?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;
}
}Aber es gibt mehrere Dinge an dieser Funktion, die gegen ein Prinzip verstoßen oder Fehler in Codequalitätstools auslösen können.
Optionale boolesche Argumente
Immer wenn eine Funktion ein optionales boolesches Argument akzeptiert, kann dies anzeigen, dass eine Funktion mehr als eine Verantwortung hat (wodurch das Prinzip der einzelnen Verantwortung verletzt wird ).
Der Grund, warum dies gegen dieses Prinzip verstoßen würde, besteht darin, dass es einem Modul mehr als einen Grund gibt, es zu ändern.
Ich bin damit einverstanden, dies auf diese Weise zu schreiben, weil ich es zum Debuggen verwende, nicht für Produktionsumgebungen, und weil es Zeiten gibt, in denen ich die Ausführung anhalten möchte und es Zeiten gibt, in denen ich es nicht tue.
Und sicher, ich könnte zwei separate Funktionen schreiben, aber wenn dies die einzige Funktion ist, die dies tut, bin ich damit einverstanden.
Verbotene Austrittserklärungen
Andere Tools zur Codequalität mögen die exit – Anweisung nicht (und ebenso wenig die die – Anweisung). Und das ist verständlich: Sie halten das Programm normalerweise vollständig an, wenn wir eine Ausnahme auslösen, einen Wert zurückgeben oder allgemein etwas tun sollten, um die Situation anständig zu handhaben.
Da es in dieser Funktion Zeiten gibt, in denen ich die Ausführung anhalten möchte, bin ich jedoch damit einverstanden, mit den Konsequenzen umzugehen, wenn die Codezeile in der Funktion enthalten ist.
Alternativ könnte ich wp_die() verwenden, und die meisten Tools zur Codequalität würden es wahrscheinlich nicht erkennen, aber das maskiert das Hauptproblem. Wenn überhaupt, ist es vielleicht am besten, die Warnung einfach zu unterdrücken, indem Sie die Anweisung verwenden, die Ihr Sniffer Ihrer Wahl zulässt.
Unabhängig davon, protokollieren Sie die Nachricht
Letztendlich besteht der Zweck der obigen Funktion darin, eine einfache Möglichkeit zu bieten, in das WordPress-Debug-Protokoll zu schreiben und dabei optional die Ausführung des Programms zu stoppen.
Es ist eindeutig nicht ohne Probleme, und es gibt qualitativ hochwertigere Bibliotheken, aber manchmal braucht man keinen Vorschlaghammer für eine problematische Reißzwecke.