3 причины, почему вы должны использовать WP_DEBUG_LOG в WordPress-разработке

Как и в случае со многими другими вещами, связанными с разработкой WordPress, лучший способ разобраться в константе WP_DEBUG_LOG – это найти ее в коде ядра WordPress.

Важный участок кода находится в файле wp-includes/load.php:

function wp_debug_mode() {
	if ( WP_DEBUG ) {
		error_reporting( E_ALL );

		if ( WP_DEBUG_DISPLAY )
			ini_set( 'display_errors', 1 );
		elseif ( null !== WP_DEBUG_DISPLAY )
			ini_set( 'display_errors', 0 );

		if ( WP_DEBUG_LOG ) {
			ini_set( 'log_errors', 1 );
			ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
		}
	} else {
		error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
	}
	if ( defined( 'XMLRPC_REQUEST' ) )
		ini_set( 'display_errors', 0 );
}

Если вы установите WP_DEBUG в true, зададите WP_DEBUG_DISPLAY в false и WP_DEBUG_LOG в true, то в таком случае все ошибки будут выводиться в файле debug.log в вашей папке wp-content; в PHP информация об ошибках будет отсутствовать.

Чтобы задать эти константы, вы должны добавить следующие строки в свой wp-config.php:

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

Но зачем это делается?

1. Чтобы скрыть ошибки

Нравится ли вам видеть ошибки в веб-браузере? Вы действительно уверены, что вам выводится абсолютно всё? Что по поводу блоков div, скрытых с помощью CSS? Что по поводу AJAX-запросов?

Интерфейс – не самое надежное место, чтобы отлавливать ошибки. Лог-файл PHP показывает абсолютно всё.

2. Чтобы отловить все ошибки.

Может быть, вы любите использовать такие плагины, как Debug Bar или Query Monitor, для отлова ошибок, и вам их вполне хватает. Я не виню вас в этом. Эти плагины действительно крутые.

Однако я обнаружил, что они пропускают некоторые ошибки. Я подозреваю, что это вызвано их натурой – ведь они являются плагинами, и перед ними могут загружаться другие плагины. Конечно, вы можете изменить порядок загрузки, чтобы они загружались в самом начале, однако как быть относительно ошибок в мультисайтовых плагинах и в самом ядре WordPress? Кроме того, как я обнаружил, ошибки с Strict Standards не учитываются этими плагинами.

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

3. Чтобы убрать ошибки сторонних плагинов.

Все это прекрасно, если ваш код выдает ошибки. Вы можете их исправить.

Но как быть со сторонними плагинами, которые вы активировали? Как быть, если они выдают предупреждения и уведомления повсюду в вашем интерфейсе? А поскольку вы включили отчеты WP_DEBUG, вы получаете уведомления, предупреждения, несоответствие стандартам и т.д. Перебор. Это может мешать и сделать практически невозможной работу с определенными активированными плагинами.

В прошлом я попросту бы деактивировал такие плагины. Не самое лучшее решение. Кроме того, как быть, если вы не можете работать без этих плагинов? Раньше я просто отключал WP_DEBUG. Позорно, я знаю.

На данном этапе я буду просто считать, что переиграл вас. Вы уже добавили константы выше в wp-config.php и подключили debug.log. Теперь вы можете отслеживать и фильтровать debug.log.

Отслеживание и фильтрация debug.log

Помимо отслеживания debug.log на ошибки, вам, естественно, понадобится убрать из него весь шум, созданный сторонними плагинами. Иначе ваши «правильные» ошибки могут утонуть в этом шуме.

Безусловно, некоторые люди используют приложение Console в OS X для считывания лог-файла, которое имеет свою фильтрацию лишнего шума от сторонних плагинов. Звучит интересно, хотя сам я это не пробовал. Я решил пойти окольным путем.

Я написал PHP-скрипт. Он просто отслеживает лог-файл на изменения и выдает уведомления об ошибках. Он может также фильтровать все Xdebug блоки, основываясь на регулярных выражениях, что позволит вам игнорировать предупреждения и уведомления со стороны сторонних плагинов.

Один debug.log для всех сайтов

Раньше я использовал отдельные логи debug.log для всех сайтов, которые у меня имеются в среде разработки. Когда я переключался на другой сайт, чтобы работать с ним, мне нужно было также отслеживать уже другой лог-файл. Не самое лучшее решение.

Теперь у меня для всех сайтов задан один лог. Сделал я это с помощью простого плагина. Я добавил следующий код в wp-content/mu-plugins/custom-debug-log-path.php для каждого сайта:

<?php
/**
 * Plugin Name: Custom Debug Log Path
 */

ini_set( 'error_log', '/srv/www/all-debug.log' );

Теперь мне достаточно было следить за одним логом для всех своих разрабатываемых сайтов.

Такой подход работает просто прекрасно. Конечно, есть еще много улучшений, которые можно сделать, однако мне вполне хватило такого отчета об ошибках.

Используете ли вы похожий отчет об ошибках? Какие улучшения вы можете предложить?

Источник: deliciousbrains.com/

Блог про WordPress
Добавить комментарий

Получать новые комментарии по электронной почте.