Дебаг в WordPress

В разработке нужно иметь возможность смотреть где ошибка, когда что-то вдруг сломалось. В WordPress для этого есть специальный режим «дебаг» (режим отладки). В этой заметке разберем его на части и посмотрим что это за константа такая WP_DEBUG.

Читайте также:

Общие знания

Дебаг режим включается константой WP_DEBUG. По умолчанию он отключен - в файле wp-config.php установлена константа:

define( 'WP_DEBUG', false );

Его можно включить, установив значение константы в true:

define( 'WP_DEBUG', true );

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

Подробнее про WP_DEBUG читайте ниже.

Нужно знать

Все константы дебаг режима определяются в файле wp-config.php.

По умолчанию константы дебага имеют следующие значения:

  • WP_DEBUG = false (true при 'development' === wp_get_environment_type())
  • WP_DEBUG_DISPLAY = true (но работает только при включенном WP_DEBUG)
  • WP_DEBUG_LOG = false

WP_DEBUG_DISPLAY и WP_DEBUG_LOG активируются, только если включена константа WP_DEBUG.

Включение WP_DEBUG не изменяет значение других констант. Т.е. при WP_DEBUG = true WP_DEBUG_DISPLAY и WP_DEBUG_LOG сохранят свои дефолтные значения и на основе этих значений будут выставлены PHP настройки показа и логирования ошибок.

Однако при WP_DEBUG = false показ и логирование ошибок, будут работать на основе настроек php.ini файла.

Используйте wp_get_environment_type(), для управления средой разработки.

Всегда отключайте Дебаг режим на рабочем (продакшн) сайте.

Отображение ошибок форсировано отключено для AJAX/REST/XMLRPC/JSONP запросов. См. код wp_debug_mode():

if (
	defined( 'XMLRPC_REQUEST' )
	|| defined( 'REST_REQUEST' )
	|| defined( 'MS_FILES_REQUEST' )
	|| ( defined( 'WP_INSTALLING' ) && WP_INSTALLING )
	|| wp_doing_ajax()
	|| wp_is_json_request()
) {
	ini_set( 'display_errors', 0 );
}

Как включить показ ошибок в AJAX запросе, сморите в статье про AJAX.

Зачем нужен «Дебаг режим»?

Допустим, вы изменили код файла functions.php темы и сайт перестал работать. Вместо него белый экран - ничего не понятно. Дебаг режим поможет разобраться, он покажет ошибку и скажет в какой она строке какого файла.

Дебаг режим выводит все уровни ошибок: не только ошибки, из-за которых PHP перестает работать, но и различные предупреждения и заметки. Заметки могут создаваться самим PHP (например, когда неправильно используется переменная) или в PHP коде (например, WP создает такие заметки, если сайт использует устаревшую функцию WordPress, или устаревший параметр функции).

Примеры включения Дебаг режима

Базовое включение

Откройте файл wp-config.php в корне сайта и измените false на true в строке:

define( 'WP_DEBUG', true ); // false - отключить показ ошибок

При таком включении:

  • В отчет об ошибках попадут все уровни ошибок.
  • Все ошибки будут выводиться на экран, потому что WP_DEBUG_DISPLAY = true по умолчанию.
  • Логироваться ошибки будут в лог файл указанные в php.ini, потому что WP_DEBUG_LOG = false по умолчанию.

Включение дебаг режима и лог файла, и отключение показа ошибок на экран

Код ниже, включит запись ошибок всех уровней (notice, warning, error) в файл wp-content/debug.log и отключит вывод на экран (показ) notice, warning.

define( 'WP_DEBUG', true );          // дебаг режим
define( 'WP_DEBUG_LOG', true );      // логирование ошибок в файл /wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // отключает вывод ошибок на экран

Теперь мы можем записывать значение переменных в лог файл так:

error_log( $value );                   // Скалярные значения
error_log( print_r( $value, true ) );  // Любые данные

Дебаг режим для продакшн среды

Для рабочего сайта в файле wp-config.php рекомендуется указать следующее:

define( 'WP_DEBUG', false );
@ini_set( 'display_errors', 0 );
@ini_set( 'log_errors', 1 );

В этой настройке мы форсировано изменяем значения из php.ini файла для log_errors и display_errors директив, потому что WP не будет устанавливать при WP_DEBUG = false, а мы не доверяем тому что устанолвено в php.ini. Если нам нужно оставить значения из php.ini, то эти директивы можно не указывать.

В интернете вы можете увидеть, что также устанавливаются значения констант:

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

Однако в такой установке просто нет смысла, потому что WP_DEBUG_DISPLAY просто не работает без включенного WP_DEBUG, а WP_DEBUG_LOG и так по умолчанию false.

Динамическое включение показа ошибок

Этот код помогает быстро включать константу WP_DEBUG, которая на рабочем сайте должна быть выключена. Также код позволяет включить запись ошибок в файл debug.log в папку /wp-content и отключить показ ошибок на экране.

Зачем это надо? Допустим, мы сделали сайт и на боевом сайте нам иногда нужно видеть ошибки (обычно конечно все это тестируется на локалке, но всякое бывает нужно). Чтобы видеть причину ошибки, нам нужно включить дебаг, но на боевом сайте где ходят пользователи делать этого не рекомендуется. С помощью кода ниже можно включить дебаг режим в WordPress через URL, зная определенный ключ.

Включение ошибок сохраняется в куку.

Установка

Замените строку define( WP_DEBUG, false ); в файле wp-config.php на такой код:

GitHub
<?php

/**
 * Dynamically enable/disable the display of PHP errors in WordPress.
 *
 * Installation:
 * replace line 'define( WP_DEBUG, false );' in 'wp-config.php' file with this code.
 *
 * Enabling debug mode:
 * NOTE: Strongly recommended to changing the 'debug' word to something more unique!
 * add the 'debug' query parameter to the URL. Examples:
 * https://site.com/?debug - default enabling of WP_DEBUG constant
 * https://site.com/?debug=1 - logging of errors into file 'DOCUMENT_ROOT/../php-errors-{HOST}.log'.
 * https://site.com/?debug=2 - linking uncompressed scripts and saving all SQL queries to $wpdb->queries
 * https://site.com/?debug=3 - saving all SQL queries in $wpdb->queries
 * https://site.com/?debug=4 - disable displaying errors (enabled by default)
 * https://site.com/?debug=14 - combining
 *
 * Disabling debug mode:
 * https://site.com/?debug=anything
 *
 * @author Kama (http://wp-kama.ru)
 * @version 2.5
 */
// IMPORTANT: change from `debug` to your unique key!
kama_define_wp_debug( 'debug' );

function kama_define_wp_debug( $key ){

	$val = isset( $_GET[ $key ] ) ? ( $_GET[ $key ] ?: 'yes' ) : false;

	// set/delete cookie
	if( $val !== false ){

		$cookie = preg_match( '/^(yes|[1234])$/', $val ) ? $val : null;

		$host = str_replace( 'www.', '', $_SERVER['HTTP_HOST'] );

		// cirilic domains: .сайт, .онлайн, .дети, .ком, .орг, .рус, .укр, .москва, .испытание, .бг
		false !== strpos( $host, 'xn--' )
			? preg_match( '~xn--[^.]+.xn--[^.]+$~', $host, $mm )
			: preg_match( '~[a-z0-9][a-z0-9-]{1,63}.[a-z.]{2,6}$~', $host, $mm );

		$host = $mm[0];

		$_COOKIE[ $key ] = $cookie;
		setcookie( $key, $cookie, time() + ( $cookie ? 3600 * 24 * 365 : -3600 ), '/', ".$host" );
	}

	// enable the debug based on the cookie
	if( ! empty( $_COOKIE[ $key ] ) ){

		define( 'WP_DEBUG', true );

		$set = array_flip(
			preg_split( '/(\d)/', $_COOKIE[ $key ], -1, PREG_SPLIT_DELIM_CAPTURE | PREG_SPLIT_NO_EMPTY )
		);

		isset( $set[1] ) && define( 'WP_DEBUG_LOG', dirname( $_SERVER['DOCUMENT_ROOT'] ) . "/php-errors-{$_SERVER['HTTP_HOST']}.log" );
		isset( $set[2] ) && define( 'SCRIPT_DEBUG', true );
		isset( $set[3] ) && define( 'SAVEQUERIES', true );
		isset( $set[4] ) && define( 'WP_DEBUG_DISPLAY', false );
	}
	else {
		define( 'WP_DEBUG', false );
	}
}

Теперь, чтобы включить режим WP_DEBUG, необходимо к любому URL добавить параметр запроса ?debug, например:

  • http://example.com/?debug - включает отладку.
  • http://example.com/?debug=1 - принудительный вывод на экран, если такой вывод отключен.
  • http://example.com/?debug=2 - логирование в файл.

Для защиты, ключ debug нужно изменить на свой, который будете знать только вы, потому что по нему вы будете включить/отключать дебаг режим.

При включении регистрации ошибок (?debug=2) родительская папка сайта (DOCUMENT_ROOT/...) должна быть доступна для записи, иначе PHP не сможет создать файл журнала. Либо можно вручную создать файл журнала DOCUMENT_ROOT/../php-errors-example.com.log. Он должен иметь права на запись (CHMOD 660 или выше).

WP_DEBUG

По умолчанию: false.

Константа WP_DEBUG включает или отключает дебаг режим в WordPress.

При включенном дебаг режиме в отчет об ошибках попадают абсолютно все уровни ошибок. При отключенном режиме в отчет попадут только важные уровни ошибок.

  • При WP_DEBUG = true:

    • за display_errors отвечает значение константы WP_DEBUG_DISPLAY.
    • за log_errors и error_log отвечает значение константы WP_DEBUG_LOG.
    • А error_reporting устанавливается в значение E_ALL - включать в отчет абсолютно все уровни ошибок.
  • При WP_DEBUG = false:
    • display_errors, log_errors и error_log, остаются такими какие они указаны в php.ini файле.
    • А 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

Константу WP_DEBUG нужно устанавливать в файле wp-config.php.

define( 'WP_DEBUG', false ); // дебаг отключен. По умолчанию.
// или
define( 'WP_DEBUG', true ); // дебаг включен

Если константа WP_DEBUG вообще не установлена в wp-config.php, то она по умолчанию равна false. Однако если указана среда разработки development она по умолчанию true.

if ( wp_get_development_mode() || 'development' === wp_get_environment_type() ) {
	define( 'WP_DEBUG', true );
} else {
	define( 'WP_DEBUG', false );
}

Нельзя указывать false в кавычках - 'false'. В этом случае дебаг будет включен, потому что значение равно строке false, а не логическому - нет.

PHP ошибки, предупреждения и заметки (errors, warnings и notices)

В PHP есть разные уровни ошибок. Если не вдаваться в подробности, то уровни значимости такие:

  1. errors - серьезная ошибка, которая приводит к остановке скрипта. PHP прерывает работу.
  2. warnings - не ошибка, а предупреждение о чем-либо. PHP не прерывает работу.
  3. notices - не ошибка, а заметка о чем-либо. PHP не прерывает работу. Заметки могут показать возможные баги в коде. Их исправление, как правило, делает код более стабильным.

«Режим дебаг» включает все уровни ошибок. Это не похоже на обычное поведение PHP, там обычно включены только ошибки уровня errors, а warnings и notices не включаются в отчет. Подробнее читайте в описании error_reporting().

Устаревшие функции, хуки и устаревшие параметры функций

WP_DEBUG также включает внутренние заметки самого WordPress. В WordPress есть специальные функции вроде _deprecated_function(), которые показывают ошибку уровня notices, когда используется устаревшая функция или хук или параметр хука, функции и т.д. Эти заметки предупреждают, что функция WP считается устаревшей и её нужно заменить, потому что она в любой момент может быть удалена. В таких заметках чаще всего предлагается альтернативная функция для замены.

WP_DEBUG_DISPLAY

По умолчанию: true

Еще один компонент WP_DEBUG, который контролирует вывод (показ) ошибок на экран.

Зависит от WP_DEBUG! Работает только, если дебаг включен WP_DEBUG = true . В противном случае просто используется глобальное значение PHP опции display_errors.

Если указать в wp-config.php:

  • define( 'WP_DEBUG_DISPLAY', true ) — (по умолчанию) WP будет выводить (показывать) ошибки на экран.
  • define( 'WP_DEBUG_DISPLAY', false ) — ошибки не будут выводиться на экран. Это нужно, когда ошибки записываются в файл (см. WP_DEBUG_LOG) и их можно смотреть позднее.
  • define( 'WP_DEBUG_DISPLAY', null ) — WP вообще не будет указывать значение для PHP опции display_errors, т.е. будет использована глобальная настройка PHP (сервера).

Показ ошибок всегда отключается для REST, AJAX или XML-RPC запросов. Для них срабатывает такой код ini_set( 'display_errors', 0 ), но при этом значение константы WP_DEBUG_DISPLAY не изменяется!

WP_DEBUG_LOG

По умолчанию: false.

Включает запись ошибок в файл. Перезаписывает следующие директивы указанные в файле php.ini:

ini_set( 'log_errors', 1 );
ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );

Работает только при WP_DEBUG = true. В противном случае будут работать директивы из php.ini.

Запись ошибок в файл может пригодится, когда нужно проверить наличие ошибок в коде, который ничего не выводит на экран. Например, при AJAX запросе или при тестировании CRON или REST.

Пример включения записи ошибок в дефолтный лог файл /wp-content/debug.log:

define( 'WP_DEBUG_LOG', true );

В этом случае используется дефолтный путь к файлу, который находится в папке к которой есть доступ по HTTP: https://example.com/wp-content/debug.log. Это не безопасное место потому что к нему есть доступ у кого угодно.

В идеале файл лога должен находиться выше корневого каталога к которму нет HTTP доступа. Если вы по каким-то причинам не можете вынести его выше корневого каталога, то, установите 600 права на файл и добавьте такую запись в в файл .htaccess в корневом каталоге вашей установки WordPress:

<Files debug.log>
	Order allow,deny
	Deny from all
</Files>

Пример включения записи ошибок в кастомный лог файл

Через WP

C WordPress 5.1, в WP_DEBUG_LOG можно указать путь файла, куда будут записываться ошибки. Например, давайте расположем его на один уровень выше текущей установки WORDPRESS:

define( 'WP_DEBUG_LOG', dirname( __DIR__ ) . '/errors.log' );
Через PHP

Изменение пути через PHP, может пригодится, при WP_DEBUG = false и когда вы хотите изменить путь указанный в php.ini файле.

ini_set( 'error_log', dirname( __DIR__ ) . '/errors.log' );

Имейте ввиду:

  • Конечная папка в указанном пути должна существовать и быть доступна для записи для PHP.
  • Файла внутри может не быть, он будет создан автоматически.

WP_DISABLE_FATAL_ERROR_HANDLER

По умолчанию: false

Позволяет отключить обработку фатальных ошибок встроенную в WordPress с версии 5.2.

Когда на сайте WordPress возникает фатальная ошибка, он отправляет письмо администратору.

Если по каким-либо причинам вы не хотите получать такие письма, добавьте такую строку в wp-config.php:

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

С версии WP 5.2 в ядро был добавлен класс WP_Fatal_Error_Handler{}, который обрабатывает фатальные ошибки (Fatal Errors). Для этого на событие shutdown вешается метод WP_Fatal_Error_Handler::handle().

Класс обрабоки фатальных ошибок можно переопределить!

Для этого вам нужно создать файл wp-content/fatal-error-handler.php в котором нужно вернуть объект обработчика:

<?php
/**
 * Файл: wp-content/fatal-error-handler.php
 * Замена классу: WP_Fatal_Error_Handler()
 */

class My_Fatal_Error_Handler {

	public function handle() {
		// your code here
	}
}

return new My_Fatal_Error_Handler();

За основу для создания такого класса нужно взять класс WP_Fatal_Error_Handler{}.

Как это работает смотрите в коде функций:

SAVEQUERIES

По умолчанию: не определена.

Связанная с дебагом константана. При включении, все SQL запросы будут сохраняться в переменную $wpdb->queries в виде массива. В любой момент можно заглянуть в этот массив и посмотреть все сделанные SQL запросы.

Кроме самого запроса, также туда записываются данные, о том сколько времени занял запрос и какой функцией он был вызван.

define( 'SAVEQUERIES', true ); // сохранять SQL запросы в `$wpdb->queries`

Важно! Включение логированя SQL запросов требует дополнительной памяти и PHP операций. Поэтому, в целях производительности, на рабочем сайте эта константа должна быть отключена!

Пример, как можно посмотреть все запросы:

if ( current_user_can( 'administrator' ) ) {
	global $wpdb;
	print_r( $wpdb->queries );
}

SCRIPT_DEBUG

По умолчанию: false.

Контролирует какие JS и CSS файлы использовать: минифицированные или оригинальные. При включении WordPress будет использовать не минифицированные версии (dev версии) JS и CSS файлов. По умолчанию используются min версии файлов. Отключение минификации может пригодится для дебага встроенных js и css файлов WordPress.

// true - использование полных версий `.css` и `.js` файлов
define( 'SCRIPT_DEBUG', true );

CONCATENATE_SCRIPTS

По умолчанию: true.

Позволяет отключить конкатенацию скриптов в админке. См. script_concat_settings().

Для ускорения работы админки все файлы JavaScript объединяются в один URL. Если вы работаете со скриптами админки, то желательно отключить эту функцию:

define( 'CONCATENATE_SCRIPTS', false );

Как работает Дебаг режим?

При генерации страницы, в самом начале загрузки WordPress (см. wp-settings.php) кроме прочих, срабатывают две фукнции:

  • wp_initial_constants() - устанавливает дефолтные значения констанат, если они не были установлены в wp-config.php файле.

  • wp_debug_mode() - переопределяет значения php.ini директив на основе указанные дебаг констант. Используя функции PHP, устанавливается:
    • Какие уровни ошибок обрабатывать.
    • Показывать их на экран или нет.
    • Логировать ошибки в файл или нет.
    • В какой файл логировать ошибки.

Не работает WP_DEBUG?

Иногда может возникнуть такая ситуация, когда вы включаете WP_DEBUG в конфиге, а ошибки все равно не видно. Такое поведение может возникнуть, когда где-то после установок параметров показа ошибок самим WordPress эти установки меняются. Например в MU плагине, обычном плагине или в теме, ошибки выключаются переустановкой ini директив PHP, примерно таким кодом:

error_reporting( 0 ); // отключает сообщения об ошибках
ini_set( 'display_errors', 0 ); // отключает показ ошибок на экран

В этом случает установки дебага WP перебиваются и он перестает работать...

Для решения, лучше всего найти где изменяются настройки и удалить такие строки, чтобы дальше работать только с константой WP_DEBUG.

В качестве другого решения можно попробовать еще раз перебить настройки вывода ошибок, указав их снова:

error_reporting( E_ALL ); // включаем сообщения об ошибках
ini_set( 'display_errors', 1 ); // включаем показ ошибок на экран

Функции WP для дебага

  • wp_debug_backtrace_summary() — Получает трассировку с названиями функций — список названий всех функций/методов, которые были вызваны для того, чтобы добраться до текущего места в коде (откуда была вызвана эта функция).
  • wp_get_environment_type() — Получает текущий тип окружения: local, development, staging, production (по умолчанию).

Данные системы

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

require_once ABSPATH . '/wp-admin/includes/class-wp-debug-data.php';
require_once ABSPATH . '/wp-admin/includes/update.php';
require_once ABSPATH . '/wp-admin/includes/misc.php';

$data = WP_Debug_Data::debug_data();

print_r( $data );

Получим большой массив данных:

Array (
	[wp-core] => Array(
			[label] => WordPress
			[fields] => Array(
					[version] => array( data )
					[site_language] => array( data )
					[user_language] => array( data )
					[timezone] => array( data )
					[home_url] => array( data )
					[site_url] => array( data )
					[permalink] => array( data )
					[https_status] => array( data )
					[multisite] => array( data )
					[user_registration] => array( data )
					[blog_public] => array( data )
					[default_comment_status] => array( data )
					[environment_type] => array( data )
					[user_count] => array( data )
					[dotorg_communication] => array( data )
				)
		)

	[wp-paths-sizes] => Array(
			[label] => Directories and Sizes
			[fields] => Array(
					[wordpress_path] => array( data )
					[wordpress_size] => array( data )
					[uploads_path] => array( data )
					[uploads_size] => array( data )
					[themes_path] => array( data )
					[themes_size] => array( data )
					[plugins_path] => array( data )
					[plugins_size] => array( data )
					[database_size] => array( data )
					[total_size] => array( data )
				)
		)

	[wp-dropins] => Array(
			[label] => Drop-ins
			[show_count] => 1
			[description] => Drop-ins are single files, found in the /public_html/assets directory, that replace or enhance WordPress features in ways that are not possible for traditional plugins.
			[fields] => Array(
					[maintenance.php] => array( data )
					[object-cache.php] => array( data )
				)
		)

	[wp-active-theme] => Array(
			[label] => Active Theme
			[fields] => Array(
					[name] => array( data )
					[version] => array( data )
					[author] => array( data )
					[author_website] => array( data )
					[parent_theme] => array( data )
					[theme_features] => array( data )
					[theme_path] => array( data )
					[auto_update] => array( data )
				)
		)

	[wp-parent-theme] => Array(
			[label] => Parent Theme
			[fields] => Array( data )
		)

	[wp-themes-inactive] => Array(
			[label] => Inactive Themes
			[show_count] => 1
			[fields] => Array(
					[Dummy] => array( data )
				)
		)

	[wp-mu-plugins] => Array(
			[label] => Must Use Plugins
			[show_count] => 1
			[fields] => Array(
					[disable-plugins-in-front.php] => array( data )
					[main.php] => array( data )
					[not_support_browsers_redirect.php] => array( data )
					[POMOdoro Translation Cache] => array( data )
					[protect-malicious-queries.php] => array( data )
					[Rus to Lat] => array( data )
				)
		)

	[wp-plugins-active] => Array(
			[label] => Active Plugins
			[show_count] => 1
			[fields] => Array(
					[AJAX Simply] => array( data )
					[Democracy Poll] => array( data )
					[Disable Emojis (GDPR friendly)] => array( data )
					[Display Active Plugins First] => array( data )
					[Kama Breadcrumbs] => array( data )
					[Kama Postviews] => array( data )
					[Kama SpamBlock] => array( data )
					[Kama Thumbnail Pro] => array( data )
					[Redis Object Cache] => array( data )
				)
		)

	[wp-plugins-inactive] => Array(
			[label] => Inactive Plugins
			[show_count] => 1
			[fields] => Array(
					[404 Error Monitor] => array( data )
					[Category Order and Taxonomy Terms Order] => array( data )
					[Contact Form 7] => array( data )
					[Kama Thumbnail] => array( data )
					[Query Monitor] => array( data )
					[Query Monitor Extend] => array( data )
					[Right Now Reloaded] => array( data )
					[Three Column Screen Layout] => array( data )
					[TinyPNG - JPEG, PNG & WebP image compression] => array( data )
					[User Role Editor] => array( data )
					[Widget Logic] => array( data )
					[WooCommerce] => array( data )
					[WordPress Sphinx Search Plugin] => array( data )
					[WP Crontrol] => array( data )
					[WP Super Cache] => array( data )
					[Yoast SEO] => array( data )
				)
		)

	[wp-media] => Array(
			[label] => Media Handling
			[fields] => Array(
					[image_editor] => array( data )
					[imagick_module_version] => array( data )
					[imagemagick_version] => array( data )
					[imagick_version] => array( data )
					[file_uploads] => array( data )
					[post_max_size] => array( data )
					[upload_max_filesize] => array( data )
					[max_effective_size] => array( data )
					[max_file_uploads] => array( data )
					[imagick_limits] => Array ( data )
					[imagemagick_file_formats] => Array( JPEG, JPG, MOV, MP4, MPEG, MPG, PNG, PNG24, WBMP, WEBP, WMV ... )
					[gd_version] => array( data )
					[gd_formats] => array( data )
					[ghostscript_version] => array( data )
				)
		)

	[wp-server] => Array(
			[label] => Server
			[description] => The options shown below relate to your server setup. If changes are required, you may need your web host’s assistance.
			[fields] => Array(
					[server_architecture] => array( data )
					[httpd_software] => array( data )
					[php_version] => array( data )
					[php_sapi] => array( data )
					[max_input_variables] => array( data )
					[time_limit] => array( data )
					[memory_limit] => array( data )
					[max_input_time] => array( data )
					[upload_max_filesize] => array( data )
					[php_post_max_size] => array( data )
					[curl_version] => array( data )
					[suhosin] => array( data )
					[imagick_availability] => array( data )
					[pretty_permalinks] => array( data )
				)
		)

	[wp-database] => Array(
			[label] => Database
			[fields] => Array(
					[extension] => array( data )
					[server_version] => array( data )
					[client_version] => array( data )
					[database_user] => array( data )
					[database_host] => array( data )
					[database_name] => array( data )
					[database_prefix] => array( data )
					[database_charset] => array( data )
					[database_collate] => array( data )
				)
		)

	[wp-constants] => Array(
			[label] => WordPress Constants
			[description] => These settings alter where and how parts of WordPress are loaded.
			[fields] => Array(
					[ABSPATH] => array( data )
					[WP_HOME] => array( data )
					[WP_SITEURL] => array( data )
					[WP_CONTENT_DIR] => array( data )
					[WP_PLUGIN_DIR] => array( data )
					[WP_MEMORY_LIMIT] => array( data )
					[WP_MAX_MEMORY_LIMIT] => array( data )
					[WP_DEBUG] => array( data )
					[WP_DEBUG_DISPLAY] => array( data )
					[WP_DEBUG_LOG] => array( data )
					[SCRIPT_DEBUG] => array( data )
					[WP_CACHE] => array( data )
					[CONCATENATE_SCRIPTS] => array( data )
					[COMPRESS_SCRIPTS] => array( data )
					[COMPRESS_CSS] => array( data )
					[WP_LOCAL_DEV] => array( data )
					[DB_CHARSET] => array( data )
					[DB_COLLATE] => Array()
				)
		)

	[wp-filesystem] => Array(
			[label] => Filesystem Permissions
			[description] => Shows whether WordPress is able to write to the directories it needs access to.
			[fields] => Array(
					[wordpress] => array( data )
					[wp-content] => array( data )
					[uploads] => array( data )
					[plugins] => array( data )
					[themes] => array( data )
					[mu-plugins] => array( data )

				)
		)

)

Настройка php.ini

Прежде всего, дефолтные настройки логирования и отображения ошибок указываются в файле конфигурации PHP php.ini, к которому у вас может быть, а может и не быть доступа. Если доступ есть, то их следует установить там. Настоятельно рекомендуется не выводить сообщения об ошибках на экран на рабочем сайте, а перенаправить их лог файл ошибок. Также лог файлы с ошибками не должны быть доступны по УРЛ.

Пример рекомендуемых настроек для php.ini:

error_reporting = 4339
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /home/example.com/logs/php_error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
html_errors = Off

error_reporting = 4339 - это кастомное значение. 4339 это десятиричное представление бинарного числа 1000011110011. Каждая 1 бинарного значения соответствует включенному уровную ошибки, а 0 отключенному.

В значении error_reporting удобнее указывать константы а не число, например:

# Включить в отчет все виды ошибок
error_reporting = E_ALL
# Включить в отчет все виды ошибок, кроме E_NOTICE E_STRICT E_DEPRECATED
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
# Включить в отчет только указанные виды ошибок
error_reporting = E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR

Таблица уровней ошибок в PHP (см. PHP Error Constants):

Константа decimal binary Описание
E_ERROR 1 1 Фатальные ошибки неустранимые средствами самого скрипта, такие как ошибка распределения памяти и т.п.
E_WARNING 2 10 Предупреждения. Скрипт не прерывается.
E_PARSE 4 100 Ошибки на этапе компиляции. Должны генерироваться только парсером.
E_NOTICE 8 1000 Уведомления. Потенциальная ошибка в скрипте. Скрипт не прерывается.
E_CORE_ERROR 16 10000 Фатальные ошибки. Происходят во время запуска РНР. Схожи с E_ERROR, только генерируются ядром PHP.
E_CORE_WARNING 32 100000 Предупреждения. Происходят во время начального запуска РНР. Схожи с E_WARNING, только генерируются ядром PHP.
E_COMPILE_ERROR 64 1000000 Фатальные ошибки на этапе компиляции. Схожи с E_ERROR, только генерируются движком Zend.
E_COMPILE_WARNING 128 10000000 Предупреждения на этапе компиляции. Схожи с E_WARNING, только генерируются движком Zend.
E_USER_ERROR 256 100000000 Схожа с E_ERROR, только генерируются пользовтаелем в коде скрипта через trigger_error().
E_USER_WARNING 512 1000000000 Схожа с E_WARNING, только генерируются пользовтаелем в коде скрипта через trigger_error().
E_USER_NOTICE 1024 10000000000 Схожа с E_NOTICE, только генерируются пользовтаелем в коде скрипта через trigger_error().
E_STRICT 2048 100000000000 Включаются для того, чтобы PHP предлагал изменения в коде, которые обеспечат лучшее взаимодействие и совместимость кода.
E_RECOVERABLE_ERROR 4096 1000000000000 Фатальные ошибки с возможностью обработки. Указывают, что, возникла опасная ситуация, но при этом, скриптовый движок стабилен. Если не обрабатывается пользовательской функцией (смотрите set_error_handler()), выполнение прерывается, как для E_ERROR.
E_DEPRECATED 8192 10000000000000 Уведомления об использовании устаревших конструкций. Включаются когда нужно предупредить о коде, который не будет работать в будущих версиях PHP.
E_USER_DEPRECATED 16384 100000000000000 Схожа с E_DEPRECATED, только генерируется пользователем через trigger_error().
E_ALL 32767 111111111111111 Все поддерживаемые ошибки, предупреждения и замечания.

Битовое представление константы можно посмотреть так:

$err_lvl = E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE;
var_dump( $err_lvl ); // int(119)
var_dump( decbin( $err_lvl ) ); // string(7) "1110111"

ВАЖНО: WordPress всегда изменяет значение error_reporting указанное в php.ini файле через функцию error_reporting(). Делается это в функции wp_debug_mode().

При WP_DEBUG = true в отчет включаются абсолютно все уровни ошибок:

error_reporting( E_ALL );

При WP_DEBUG = false в отчет включаются такой список ошибок:

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 );

Плагины для дебага и профилирования в WordPress

В каталоге WP есть несколько хороших плагинов, которые расширяют возможности «дебага» и дают дополнительную информацию для выявления слабых мест кода. Популярные из них:

  • Query Monitor - выводит в подвале кучу полезной информации о текущем запросе. Сколько времени затрачено, сколько SQL запросов, какие запросы, сколько времени занял каждый запрос, сколько памяти затрачено, какие хуки использовались и т.д.

  • Query Monitor Addons

  • Debug Bar - комплекс плагинов по дебагингу и профилированию. Это основной плагин, после его установки к нему можно подключать еще другие плагины, которые расширяют возможности профилирования. Но я его как-то не оценил...

  • Clockwork для WordPress - выводит любую отладочную информацию в консоль браузера Google Chrome или Firefox, работает на основе браузерного расширения Clockwork, чтобы иметь возможность передавать данные с сервера на клиент. Есть возможность отладки AJAX-запросов.