Всякий раз, когда я работаю над проектом, я часто устанавливаю WordPress в режим отладки, и мне нравится писать сообщения в журнал ошибок, которые я могу легко просматривать, отслеживать и отслеживать всякий раз, когда я работаю над проектом.
Когда я это делаю, есть два способа (и это зависит только от проекта):
- Я буду использовать такую библиотеку, как Monolog ,
- Я буду использовать свою собственную простую функцию журнала.
В этом посте я расскажу о последнем. То есть я собираюсь поделиться тем, как я пишу сообщения в журнал отладки WordPress, а затем некоторыми вещами, на которые вам, возможно, придется обратить внимание, когда вы делаете то же самое.
Журнал отладки WordPress
Во-первых, важно отметить, что функция, о которой я собираюсь рассказать, обычно находится в контексте базового класса.
Допустим, у меня есть AbstractSubscriber, который реализуют все мои подписчики (например, ScriptAssetSubscriber для регистрации и постановки в очередь файла JavaScript).
AbstractSubscriber будет включать эту функцию, чтобы ее могли вызывать любые дочерние классы. Функция довольно проста:
<?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;
}
}Но в этой функции есть несколько моментов, которые могут нарушать принцип или вызывать ошибки в инструментах контроля качества кода.
Необязательные логические аргументы
Всякий раз, когда функция принимает необязательный логический аргумент, это может указывать на то, что функция имеет более одной ответственности (таким образом, нарушается принцип единой ответственности ).
Причина, по которой это нарушит указанный принцип, заключается в том, что это дает модулю более одной причины для изменения.
Мне удобно, чтобы это было написано таким образом, потому что я использую его для отладки, а не для производственных сред, и потому что иногда я могу захотеть остановить выполнение, а иногда нет.
И, конечно, я мог бы написать две отдельные функции, но если это единственная функция, которая делает это, я согласен с этим.
Заявления о запрещенном выходе
Другим инструментам контроля качества кода не нравится оператор выхода (и точно так же им не нравится оператор die ). И это понятно: они обычно полностью останавливают программу, когда мы должны генерировать исключение, возвращать значение или вообще делать что-то, чтобы изящно справиться с ситуацией.
Опять же, поскольку в этой функции есть моменты, когда я хочу остановить выполнение, я в порядке, имея дело с последствиями наличия строки кода в функции.
В качестве альтернативы я мог бы использовать wp_die(), и большинство инструментов контроля качества кода, скорее всего, не обнаружат его, но это маскирует основную проблему. Во всяком случае, возможно, лучше просто подавить предупреждение, используя любую директиву, которую может разрешить выбранный вами сниффер.
В любом случае, зарегистрируйте сообщение
В конечном счете, цель вышеприведенной функции — предоставить простой способ записи в журнал отладки WordPress и при необходимости остановить выполнение программы при этом.
Это явно не без проблем, и есть доступные библиотеки более высокого качества, но иногда вам не нужна кувалда для решения проблемы.