Использование журнала отладки WordPress

Вы всегда пишете код с первого раза без ошибок? Я – нет. Но признание ошибок – первый шаг к их исправлению. А для того, чтобы исправить ошибку, её сначала нужно найти. Эта статья поможет простым смертным отследить их ошибки при помощи отладочного журнала WordPress (debug log):

Я уже упоминал о настройках отладки WordPress в своей недавней статье «Файл конфигурации WordPress: wp-config.php». Я рассказал о том, как показать ошибки в среде разработки и скрыть их на публичном сервере.

Скрывать отладочные сообщения от посетителей – важный элемент безопасности вашего сайта. Даже если вы думаете, что ваш сайт вообще не генерирует никаких ошибок или предупреждений, посетители могут обнаружить что-то, что не успели обнаружить вы.

Именно по этой причине неплохо было бы оставить WP_DEBUG включённым, но не показывать ошибки на страницах сайта, а записывать их для последующего анализа в особый файл – журнал отладки. В этой статье я опишу различные способы настройки и чтения журнала. А ещё я расскажу, как записывать информацию в журнал программным способом.

Записывать ошибки параллельно с их отображением на страницах сайта может быть полезно при разработке. Иногда источник ошибки на первый взгляд непонятен, но анализ нескольких аналогичных ситуаций может помочь выявить его.

Настройка

Я хочу вкратце резюмировать мою статью о настройке отладки в WordPress. Если вы раньше никогда не редактировали файл wp-config.php, я рекомендую вам прочитать ту статью целиком, а потом вернуться сюда.

Чтобы разрешить генерацию отладочной информации и записывать её в журнал, но не выводить на страницах сайта, вам нужно изменить ваш файл wp-config.php следующим образом:

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

Заметим, что фатальные ошибки (так называемый «белый экран смерти») скрыть невозможно.

Просмотр журнала отладки

Файл с отладочной информацией называется debug.log и располагается в том же каталоге, что и контент вашего сайта. Можно читать его и удалять из него устаревшую информацию при помощи любого текстового редактора, однако это не очень удобный способ, особенно если журнал расположен на удалённом сервере, находящемся под нагрузкой.

Существуют плагины, заметно упрощающие работу с журналом отладки. Однако в ряде случаев (например, при недоступности сайта) необходимо работать с файлом журнала напрямую.

Существует целый ряд инструментов, позволяющих работать с журналом отладки через интерфейс администратора сайта. Мой любимый инструмент – Log Viewer. Этот бесплатный плагин позволяет читать и очищать журнал через панель управления сайтом, пункт меню «Tools» («Инструменты»).

Вдобавок к этому, если на вашем сайте установлен плагин Debug Bar, это сочетание плагинов позволит работать с журналом на любой странице сайта в панели отладки.

Разумеется, панель отладки не стоит использовать на рабочем сервере, но в процессе разработки она весьма полезна. Оба плагина (Log Viewer и Debug Bar) могут быть установлены через установщик плагинов как сами по себе, так и в составе комплексного плагина Developer.

Вот как может выглядеть ваш журнал:

Просмотр журнала отладки

Как видите, каждое событие, сгенерированное WordPress, отмечается в журнале меткой времени в UTC.

Запись произвольной информации в журнал отладки

В некоторых случаях бывает полезным выводить в журнал дополнительную информацию, которая не сообщает об ошибке, а только помогает в написании собственного кода. Для таких случаев в PHP есть функция error_log(), которая выводит сообщение в журнал.

Эта функция не имеет опций форматирования, поэтому я рекомендую создать собственную обёртку над error_log, которая бы форматировала записываемые в журнал переменные и объекты при помощи функции print_r(). Вот так может выглядеть эта функция-обёртка:

if ( ! function_exists('write_log')) {

   function write_log ( $log )  {
      if ( is_array( $log ) || is_object( $log ) ) {
         error_log( print_r( $log, true ) );
      } else {
         error_log( $log );
      }
   }
}

Помещать этот код в файл functions.php вашей темы не имеет смысла, так как при отладке сайта вы, скорее всего, переключите тему на стандартную и потеряете к нему доступ. Оформите этот код в виде плагина. Для этого создайте файл в вашем каталоге плагинов, добавьте в него заголовок плагина и выше приведённый код. Заголовок плагина может выглядеть так:

/*

Plugin Name: Log Error
*/

У созданной нами функции есть множество вариантов применения. Хотите узнать, вызывается ли данная строка? Напишите:

write_log( __LINE__ );

Вы также можете собирать в журнал базовую статистику сайта. Например, вы хотите узнать, кто и когда просматривал определённую статью? Добавьте в плагин следующий код:

add_action( 'wp_head', 'slug_log_post_view' );

function slug_log_post_view() {
   //set the ID of the post you want to track here:
   $post_to_track = 42;

   //get the current post's ID & make sure it's a valid ID and it matches our ID
   $id = get_queried_object_id();
   if ( intval( $id ) > 0 && $post_to_track === $id ) {

      //check if current user is logged in and if so get the user ID
      if ( is_user_logged_in() ) {
         $user_id = get_current_user_id();
         $user_id = 'a user with the ID ' . $user_id;
      }
      else{
         $user_id = 'a user that was not logged in.';
      }

      //log the information
      write_log( "The post {$post_to_track} was accessed by {$user_id}" );

   }

}

Конечно, написанный нами код не является серьёзным аналитическим инструментом, но он вполне может помочь проследить за отдельным постом, обозначенным переменной $post_to_track. Чтобы следить за всеми постами, вы можете удалить из кода, приведенного выше, проверку идентификатора поста $id на равенство $post_to_track.

Отладка – это здорово!

Надеюсь, моя короткая статья поможет вам овладеть такой необходимой, но часто упускаемой из вида возможностью WordPress. Но не забывайте, что ошибками в PHP-коде отладка не ограничивается. Проблемы с JavaScript поможет выявить JavaScript-консоль вашего браузера, но это – тема для другой статьи.