WordPress вывод ошибок php

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

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

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

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

Есть два варианта режима «дебаг»:

1. WP_DEBUG_DISPLAY — Константа показа ошибок на экран.
2. WP_DEBUG_LOG — Константа запись ошибок в лог файл.

Сам «дебаг» режим включается константой WP_DEBUG.

Все три константы могут принимать значения true или false.

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

• WP_DEBUG = false (true при 'development' === wp_get_environment_type())
• WP_DEBUG_DISPLAY = true
• WP_DEBUG_LOG = false

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

Как включить «дебаг» (показ ошибок в WordPress)

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

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

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

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

Включение и настройка дебага

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

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

Вставлять этот код нужно в файл wp-config.php куда угодно, но до строки:

require_once( ABSPATH . 'wp-settings.php' );

Благодаря коду выше, было включено логирование ошибок в файл. Этим можно воспользоваться для записи содержимого переменных в этот файл:

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

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

Этот код помогает быстро включать константу 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)
 * ver 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 (логирование в файл).

WP_DEBUG

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

WP_DEBUG нужно определять (устанавливать) в файле wp-config.php из корня сайта.

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

Для удобности, можно писать числа 1 или 0:

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

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-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 (сервера).

WP_DEBUG_LOG

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

Еще один компонент дебага. Включает запись ошибок в файл /wp-content/debug.log. Зависит от WP_DEBUG — работает только если WP_DEBUG равен true.

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

define( 'WP_DEBUG_LOG', true ); // true - запись ошибок в файл /wp-content/debug.log

Изменение адреса файла лога ошибок

Через WP

C WordPress 5.1, в WP_DEBUG_LOG можно указать путь к файлу лога:

define( 'WP_DEBUG_LOG', '/srv/path/to/custom/log/location/errors.log' );

Через PHP

Чтобы изменить название файла, добавьте следующую строку как можно раньше, например в MU плагины:

ini_set( 'error_log', WP_CONTENT_DIR . '/hidden-debug.log' );

Но эту строку нельзя добавлять в wp-config.php — это слишком рано…

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

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

SAVEQUERIES

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

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

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

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

SCRIPT_DEBUG

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

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

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

Как работает WP_DEBUG?

После установки констант дебага в wp-config.php мы заходим на сайт. И при генерации страницы, в самом начале загрузки WordPress (см. wp-settings.php) срабатывает функция wp_debug_mode(). Она, используя функции 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 )

				)

		)

)

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

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

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

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

• Log Deprecated Notices — записывает в лог все заметки о наличии устаревших функций WordPress или их параметров и т.д. Не зависит от WP_DEBUG — работает с отключенным WP_DEBUG.

• WordPress mu-plugin for debugging — альтернативный дебаггер на базе библиотеки Kint.

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

In development, you need to be able to see where the error is when something suddenly breaks. WordPress has a special debug mode for this. In this post, let’s take it apart and see what this WP_DEBUG constant is.

Why do we need «debug mode»?

Let’s say you changed the functions.php file of the theme and the site stopped working. In its place is a white screen — nothing is clear. «Debug» will help to understand, it will show you the error and tell you in which line of what file it is.

«Debug» displays not only the errors that cause the site to stop working, but also the notes and warnings. Notes can be created by PHP itself (for example, when a variable is used incorrectly) or by PHP script code (for example, WP creates such notes if the site uses a deprecated WordPress function, or an deprecated function parameter).

There are two options for debug mode:

1. WP_DEBUG_DISPLAY — Display errors on the screeen.
2. WP_DEBUG_LOG — Write errors to log file.

The debug mode itself is controlled by WP_DEBUG constant.

All three constants can take true or false values.

By default, the debug constants have these values:

• WP_DEBUG = false (true when 'development' === wp_get_environment_type())
• WP_DEBUG_DISPLAY = true
• WP_DEBUG_LOG = false

All constants can be defined in the wp-config.php file or defined by wp_initial_constants(), which is triggered early on WordPress loading.

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

How to enable «debug» (display errors in WordPress)

Basic enabling

Open the wp-config.php file at the root of your site and change false to true on the line:

define( `WP_DEBUG`, true ); // false - turn off error display

With this option errors and noties will be displayed, but nothing will be logged in log file.

Enable and configure debugging

The code below, will enable the recording of errors, warnings and noties in the wp-content/debug.log file and disable the display of notes and warnings on the screen, so they do not get in the way when browsing the site.

define( 'WP_DEBUG', true );          // enable debug mode
define( 'WP_DEBUG_LOG', true );      // true - logging errors into /wp-content/debug.log file
define( 'WP_DEBUG_DISPLAY', false ); // false - turns off displaying errors on the screen
define( 'SCRIPT_DEBUG', true );      // use full versions of JS and CSS engine files

Insert this code anywhere in the wp-config.php file, but before the line:

require_once( ABSPATH . 'wp-settings.php' );

Thanks to the code above, error logging to a file has been enabled. This can be used to write the contents of the variables to log file:

error_log( $value );               // Scalar values
error_log( print_r( $value, 1) );  // Any data

Dynamically turn on/off errors display

This code helps to quickly enable the WP_DEBUG constant, which on a working site should be turned off. The code also allows you to enable error logging in the /wp-content/debug.log file, and disable error display on the screen.

Why this code is handy? Let’s say we made the site and it works, but we periodically fix it’s code. While editing of course appear different errors, including fatal ones. To see what the cause, we need to enable debug, to do this, open wp-config.php and change the constant, after completion it is necessary to return everything back. This is inconvenient, it’s more convenient to enable debug via URL and see errors when needed.

Enabling errors is saved in the cookie of your site so it will works only for you.

To get things working, replace line define( WP_DEBUG, false ); in file wp-config.php with this code:

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)
 * ver 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 );
	}
}

Now, to enable WP_DEBUG mode, you need to add ?debugquery parameter to any URL, for example:

• http://example.com/?debug — enables debug.
• http://example.com/?debug=1 — forced output to screen if such output is disabled.
• http://example.com/?debug=2 — logging to file.

WP_DEBUG

WP_DEBUG — is a PHP constant (a global constant — only defined once). The value of this constant enables or disables error display in PHP. It is also used in various places in WordPress code to show or suppress errors where necessary.

WP_DEBUG should be defined in the wp-config.php file.

// disable debug (default)
define( 'WP_DEBUG', false );
// or
define( 'WP_DEBUG', 0 );

// enable debug
define( 'WP_DEBUG', true );
// or
define( 'WP_DEBUG', 1 );

PHP errors, warnings and notices

There are different levels of errors in PHP. Without going into details, the significance levels are:

1. errors — a serious error which leads to a halt of the script. Aborts PHP.
2. warnings — not an error, but a warning about something. PHP does not interrupt.
3. notices — not an error, but a note about something. PHP does not interrupt. Notes may indicate possible bugs in the code. Fixing them will usually make the code more stable.

«Debug mode» includes all levels of errors. This is not like PHP’s usual behavior: usually only errors at the ‘errors’ level are included, and warnings and notices are not shown. See error_reporting() for more details.

Deprecated functions, hooks and deprecated function parameters

WP_DEBUG also includes internal WordPress noties. WordPress has special functions like _deprecated_function(), which show a notices level error when an deprecated function or hook or parameter of a hook, function, etc. is used. These notices warn that the WP function is considered deprecated and should be replaced because it can be removed at any time. Such notes most often suggest an alternative function to replace it.

WP_DEBUG_DISPLAY

Default: true.

Another WP_DEBUG component, which controls the display of errors.

IMPORTANT: it depends on WP_DEBUG — the logic of this parameter works only if WP_DEBUG = true. Otherwise, the global PHP option display_errors is used as the value of WP_DEBUG_DISPLAY.

If you specify in wp-config.php:

• define( 'WP_DEBUG_DISPLAY', true ) — (by default) WP will display errors.

• define( 'WP_DEBUG_DISPLAY', false ) — The errors will not be displayed. This is needed when errors are written to a log file (see WP_DEBUG_LOG) and you can see them later.

• define( 'WP_DEBUG_DISPLAY', null ) — WP will not specify a value for PHP option display_errors at all, i.e. it will use the global PHP (server) setting.

WP_DEBUG_LOG

Default: false.

Another debug component. Enables error logging to file /wp-content/debug.log. Depends on WP_DEBUG — works only if WP_DEBUG = true.

Writing errors in the log file can be useful when you want catch errors, which does not display anything on the screen. For example, when AJAX request or when testing CRON or REST.

«php
define( ‘WP_DEBUG_LOG’, true ); // true — log errors to /wp-content/debug.log

#### Changing the address of the error log file

##### Via WP

Since WordPress 5.1, in ``WP_DEBUG_LOG`` you can specify the log file path:

```php
define( 'WP_DEBUG_LOG', '/srv/path/to/custom/log/location/errors.log' );

Via PHP

To change the file name, add the following line as early as possible, such as in MU plugins:

ini_set( 'error_log', WP_CONTENT_DIR . '/hidden-debug.log' );

This line cannot be added to wp-config.php — it’s too early!

SAVEQUERIES

Default: undefined.

Related to debug constant. When enabled, all SQL queries will be saved in the $wpdb->queries property as an array. In this array you can see all SQL queries and if necessary find the right one and make sure it is correct, etc.

In addition to the query itself, also recorded data about how much time the query took and what function it was called.

// save SQL queries and their data in `$wpdb->queries`
define( 'SAVEQUERIES', true );

SCRIPT_DEBUG

Default: false.

A debug-related constant. Controls which JS and CSS files to use: compressed or full. When enabled, WordPress will use uncompressed versions (dev versions) of JS and CSS files. The default is to use min versions of the files. This is necessary for testing when modifying embedded js or css files.

// use full versions of WP `.css` and `.js` files
define( 'SCRIPT_DEBUG', true );

How does WP_DEBUG work?

After setting the debug constants in wp-config.php we go to the site. And when generating the page, at the very beginning of WordPress loading — see wp-settings.php — wp_debug_mode() function is triggered. It uses PHP functions to set how and what error levels to show, whether or not to create a log file, etc.

WP_DEBUG does not work?

Sometimes you may have a situation when you enable WP_DEBUG in wp-config, but the error is still not visible. This behavior can occur when somewhere after the error display settings by WordPress itself, these settings are changed. For example in MU plugin, a regular plugin or in the theme, the errors are turned off by reinstalling the ini directives PHP, something like this code:

error_reporting( 0 ); // turn off error messages
ini_set( 'display_errors', 0 ); // disables displaying errors

In this case WP’s debug settings get interrupted and it stops working.

To solve this, it is best to find where the settings are changed and delete such lines, so that from now on you can work only with WP_DEBUG constant.

As another solution, you can try to re-build the error output settings by specifying them again:

error_reporting( E_ALL ); // enable error messages
ini_set( 'display_errors', 1 ); // show errors on the screen

WP functions for debugging

• wp_debug_backtrace_summary() — Return a comma-separated string of functions that have been called to get to the current point in code.
• wp_get_environment_type() — Retrieves the current environment type.

System data

For debugging, WP has a class WP_Debug_Data. For example, using the following method we can get a bunch of data about the system:

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

We get a big data set:

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 )

				)

		)

)

Plugins for debugging and profiling in WordPress

There are several plugins in the WP catalog that extend the «debugging» capabilities and provide additional information to identify code weaknesses. Popular ones are:

• Query Monitor — displays a bunch of useful information about the current page query. How much time was spent, how many SQL queries, what queries, how long each query took, how much memory was spent, what hooks were used, etc.

• Query Monitor Addons

WordPress — одна из самых популярных систем управления контентом (CMS), доступных сегодня на рынке. Он построен на различных языках разработки, в основе которых лежит PHP. Каждый раз, когда пользователь посещает сайт WordPress, код PHP компилируется модулем PHP, установленным на сервере (Apache или Nginx). По сути, это означает, что во время обработки запросов пользователя может произойти множество ошибок PHP. Если это так, это указывает на проблему с кодом PHP. Следовательно, вы должны понимать базовые знания о том, как проверять эти ошибки PHP, прежде чем искать решение. В этой статье мы объясним, как отлаживать ошибки PHP на сайте WordPress, а также включить ведение журнала ошибок.

Ошибки PHP могут быть предупреждением или фатальной ошибкой, нарушающей работу вашего сайта. Эти проблемы могут возникать по разным причинам, указанным ниже.

• Пропуск точки с запятой в синтаксисе
• Вызов неправильной переменной
• Конфликт с другим плагином или даже с параметром сервера
• Несовместимый плагин или тема с последней версией PHP

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

Почему вы должны отслеживать ошибки PHP?

Внимательное наблюдение за ошибками PHP на вашем сайте имеет решающее значение по двум основным аспектам.

• Безопасность — информация об ошибках PHP может подвергнуть ваш сайт вредоносным атакам. Следовательно, понимание и исправление ошибок является обязательной задачей для поддержания безопасности и надежности веб-сайта.
• Оптимизация — ошибки PHP могут снизить скорость вашего сайта, и если эти проблемы останутся незамеченными, они могут снизить производительность и потерять пропускную способность.

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

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

Отладка ошибок PHP в WordPress

В этой статье мы рассмотрим, как отлаживать ошибки PHP в WordPress двумя способами.

1. Отлаживайте ошибки PHP вручную с помощью кода.
2. Отлаживайте ошибки PHP с помощью плагинов.

1. Отладка ошибок PHP вручную с помощью кода

Если вы разработчик или хорошо владеете одним или двумя языками программирования, этот метод будет намного проще. Возможно, это не самый быстрый вариант, поскольку вам придется писать несколько строк кода, но даже это делает его более интересным. В этом конкретном посте мы отредактируем код в Visual Studio Code, поскольку сайт размещен локально на LAMPP. Если ваш сайт уже работает, вы можете редактировать код через приложение File Manager или FTP.

Мы рассмотрим три основные константы PHP:

WP_DEBUG и WP_DEBUG_DISPLAY

На нашем тестовом сайте прямо сейчас на сайте WordPress не отображаются ошибки PHP, как показано на изображении ниже. Это потому, что по умолчанию WordPress предотвращает отображение ошибок в браузере, задав для параметра WP_DEBUG значение false.

Чтобы установить для отладки WordPress значение true, перейдите в корневую папку установки вашего сайта и найдите файл wp-config.php. Отредактируйте файл и проверьте, содержит ли он следующую строку.

define( 'WP_DEBUG', false );

Он должен выглядеть так, как показано на изображении ниже.

Если строка есть, просто измените значение WP_DEBUG на true. В противном случае вы можете вставить новую строку со значением WP_DEBUG как true. Кроме того, добавьте строку ниже, чтобы включить отображение ошибок PHP в браузере.

define( 'WP_DEBUG_DISPLAY', true );

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

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

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

Но сначала не забудьте отключить отображение ошибок, отредактировав значение WP_DEBUG_DISPLAY, как показано на изображении ниже. Оставьте значение WP_DEBUG равным true, чтобы мы могли регистрировать ошибки.

Журнал ошибок с помощью WP_DEBUG_LOG

Ниже приведены некоторые из ситуаций, в которых вы можете создать файл журнала ошибок WordPress:

• Весь ваш сайт упал
• Обратите внимание на пустой экран при попытке открыть сайт
• Проблемы с производительностью вашего сайта
• Появляется предупреждение с кодами состояния HTTP 401, 404 или 500
• Если плагин или тема работает некорректно. Вы также можете рассмотреть возможность создания журналов ошибок, чтобы получить более подробную информацию о проблеме.

Чтобы записать ошибки WordPress в файл журнала, откройте файл wp-config.php и найдите строку определить ('WP_DEBUG_LOG,' истина);. Если его нет, вы можете вставить новую строку. Иногда строка также комментируется, и обязательно удалите комментарии и установите для параметра WP_DEBUG_LOG значение true, как показано на изображении ниже.

Сохраните файл и загрузите обратно на свой сервер. Теперь перезагрузите сайт в браузере. WordPress создаст файл журнала с именем debug.log в каталоге wp-content, в который будут записаны все ошибки PHP на вашем сайте.

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

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

2. Отладка ошибок PHP с помощью плагинов

Хотя описанный выше метод прост, вам необходимо получить доступ к серверу из учетной записи хостинга или удаленно, используя FTP для редактирования wp-config.php. К счастью, вы можете отлаживать ошибки PHP в WordPress, используя различные типы плагинов. Здесь мы обсудим следующие два плагина:

1. Плагин отладки WP
2. Плагин Query Monitor

Отладка ошибок PHP с помощью плагина отладки WP

В Отладка WP plugin — это бесплатный плагин WordPress, который запускает режим отладки WordPress и позволяет вести журнал ошибок. При активации этот плагин устанавливает константы отладки в wp-config.php и удаляет их при деактивации. При возникновении проблем возникает исключение PHP. Эти константы включают:

define( 'WP_DEBUG'; true );
define( 'WP_DEBUG_LOG'; true );
define( 'SCRIPT_DEBUG'; true );
define( 'SAVEQUERIES'; true );

Когда плагин деактивирован, предпринимаются все усилия для восстановления состояния уже существующих констант. Тем не менее, настройки по умолчанию и все сохраненные настройки восстанавливаются при повторной активации плагина. Плагин также имеет раздел отладки, в котором вы можете настроить константы отладки. Для начала;

• Перейдите в панель управления WordPress и нажмите меню «Инструменты».
• Щелкните подменю «Отладка WP».
• Прокрутите вниз и выберите константы отладки, которые вы хотите применить на своем сайте.
• Нажмите кнопку «Сохранить изменения», чтобы применить изменения, как показано на изображении ниже.

Отладка ошибок PHP с помощью подключаемого модуля Query Monitor

Монитор запросов — это бесплатный плагин WordPress, который помогает веб-администраторам анализировать запросы веб-страниц и веб-страниц. Он также предупредит вас о серьезных ошибках PHP среди множества его применений. Вы увидите новый элемент в верхней панели администратора после его установки и активации. Когда он определяет критическую (PHP) проблему, панель инструментов становится красной, как показано на изображении ниже.

Эта панель инструментов содержит раскрывающееся меню с несколькими параметрами, которые вы можете использовать для управления своим сайтом WordPress. Однако в этом посте мы сосредоточимся только на ошибках PHP. Наведите указатель мыши на недавно появившуюся панель инструментов «Монитор запросов» и щелкните «Ошибки PHP». Откроется окно со всеми ошибками PHP на вашем сайте WordPress, как показано на изображении ниже.

Кроме того, вы можете установить файл cookie аутентификации, который позволяет вам просматривать выходные данные Query Monitor, когда вы не вошли в систему или когда вы вошли в систему как другой пользователь. Для этого выполните следующие действия:

• Перейдите в раздел «Плагины» на панели инструментов WordPress.
• Нажмите на опцию «Настройки» под плагином Query Monitor.
• На вашей панели администратора появится окно консоли разработчика.
• Нажмите «Установить файл cookie для аутентификации».

Заключение

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