Debug true что это

Что такое режим отладки или “дебаг” и как его мне его включить на сайте WordPress?

Ответ

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

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

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

Во-первых, сначала режим нужно задействовать. За это отвечает следующая команда:

Приветствую вас, уважаемые!

Сегодня мы поговорим об обнаружении и устранении ошибок в WordPress на вашем сайте. Не думайте что у вас их нет – их просто не видно. И мы сейчас поговорим об этом.

Нахождение и устранение дефектов в WordPress

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

К сожалению, не все разрабы следуют этой классной просьбе потому, что они забывают о средствах отладки, встроенные в WordPress или просто не знают, как использовать их.

В этом посте я расскажу про основные доступные средства отладки и покажу вам как легко ими пользоваться.

Нахождение и устранение дефектов с помощью отладки (WP_DEBUG)

Самый важный инструмент отладки в WordPress это же конечно WP_DEBUG.

Это логическая (булева) константа, включающая режим “отладки багов” в WordPress. Она прописана в файле wp-config.php, мирно лежащей в корне вашего WP.

Если установить значение “true”, вы начнете видить сообщения об ошибках PHP и отладочные сообщения WordPress, в каких функциях и файлах найдены ошибки и их стоило бы исправить. Эти сообщения очень полезны для разработчиков.

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

Но вернемся к WP_DEBUG и вам просто нужно добавьте строчку, которая ниже в ваш файл wp-config.php

Или в этом файле просто поменяйте значени константы “false” на значени “true”. По дефолтным настройкам там прописано “false”.

Отладчик предоставляет удобный инструмент для решения проблем если что-то не так пойдет на вашем сайте.

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

WP_DEBUG_LOG – лог ошибок

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

Это очень полезная особенность если вы хотите проанализировать уведомления позже.

И возвращаясь к логу с ошибками (WP_DEBUG_LOG) просто добавьте нижеследующую строку в wp-config.php:

Убрать ошибки вашего сайта с экрана поможет константа, имя которой WP_DEBUG_DISPLAY

Не хотите показывать ошибки на страницах своего сайта воспользуйтесь WP_DEBUG_DISPLAY.

Тоже одна из полезных констант, которая позволяет контролировать отображаются ли сообщения отладки внутри HTML-кода вашего сайта.

По умолчанию прописано “true” – то есть показывать где образовываются ошибки и предупреждения. Измените на “false” и все ошибки скроются с экрана.

Используем также вместе с WP_DEBUG_LOG.

Используя эту особенность, также просто нужно добавить строку ниже во все тот же файл – wp-config.php:

Запишем все вместе

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

Не стоит забывать что WP_DEBUG для локального использования и его не надо использовать на “живом” сайте!

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

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

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

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

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

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

Сам «дебаг» режим включается константой WP_DEBUG . Все три константы могут принимать значения true или false (1 или 0). Подробнее ниже.

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

Использует три константы:

  • WP_DEBUG = false
  • WP_DEBUG_DISPLAY = true
  • WP_DEBUG_LOG = false

Все это константы определяются ранней функцией wp_initial_constants() и могут быть определены в файле wp-config.php .

Функция wp_debug_mode() устанавливает настройки PHP на основе установленных констант.

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

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

Показ ошибок всегда отключен для AJAX запросов, там увидеть ошибки можно только через лог файл. Это устанавливается в wp_debug_mode():

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

Рекомендуется использовать «дебаг режим» в процессе работы над сайтом (темой или плагином).

Рекомендуется отключать «дебаг» на рабочем сайте. В целях защиты приватной информации от третьих лиц. Проще говоря, чтобы хакеры не могли получить информацию из «дебага».

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

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

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

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

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

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

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

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

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

Зачем это надо? Допустим, мы сделали сайт и он работает, но мы периодически правим код. При правках конечно возникают разные ошибки, в том числе фатальные. Чтобы видеть в чем причина, нам нужно включить дебаг, для этого нужно открыть wp-config.php и изменить константу, по завершению работ надо вернуть все обратно. Это неудобно, удобнее включить дебаг через URL и увидеть ошибки когда это нужно.

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

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

Теперь, чтобы включить режим WP_DEBUG , нужно добавить в любой URL параметр запроса debug : http://example.com/?debug или http://example.com/?debug=1 (принудительный вывод на экран, если такой вывод отключен) или http://example.com/?debug=2 (логирование в файл).

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

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

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

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

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

Заметка: нельзя указывать 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 считается устаревшей и её нужно заменить, потому что она в любой момент может быть удалена. В таких заметках чаще всего предлагается альтернативная функция для замены.

меню

По умолчанию: 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 не изменяется!

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

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

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

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

Через WP

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

Через PHP

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

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

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

меню

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

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

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

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

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

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

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

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

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

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

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

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

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

Плагины для дебага и профилирования в 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-запросов.

  • [an error occurred while processing the directive]
    Карта сайта