Как в wordpress отключить показ сайта?
В разработке необходимо владеть возможность глядеть где промах, когда что-то вдруг сломалось. В WordPress для этого кушать особый порядок «дебаг» (порядок отладки). В этой заметке разберем его на доли и посмотрим что это за константа такая WP_DEBUG.
Содержание статьи
Зачем необходим «дебаг порядок»?
Положим, вы изменили код файла functions. php темы и сайт перестал трудиться. Вместо него белоснежный экран — ничего не удобопонятно. «дебаг» поможет разобраться, он покажет промах и произнесёт в какой она строке какого файла.
«Дебаг» выводит не лишь промахи, из-за каких сайт перестает трудиться, но и заметки. Заметки могут создаваться самим PHP (так, когда неверно используется переменная) или кодом PHP скрипта (так, WP создает такие заметки, если сайт использует устаревшую функцию WordPress, или устаревший параметр функции).
Кушать два варианта порядка «дебаг»:
- Показ промахов на экран — константа WP_DEBUG_DISPLAY .
- Запись промахов в лог файл — константа WP_DEBUG_LOG .
Сам «дебаг» порядок подключается константой WP_DEBUG .
Все три константы могут принимать смыслы true или false.
По умолчанию константы дебага имеют такие смыслы:
- WP_DEBUG = false (true при ‘development’ === wp_get_environment_type() )
- WP_DEBUG_DISPLAY = true
- WP_DEBUG_LOG = false
Все константы могут быть установлены в файле wp-config. php и определяются функцией wp_initial_constants(), какая срабатывает на раннем этапе загрузки WordPress.
WP_DEBUG_DISPLAY и WP_DEBUG_LOG активируются, лишь если включена константа WP_DEBUG .
Включение WP_DEBUG не меняет смысл иных констант. Т. е. при WP_DEBUG=true WP_DEBUG_DISPLAY и WP_DEBUG_LOG сохранят свои дефолтные смыслы и на основе этих смыслов будут выставлены PHP настройки показа и логирования промахов.
Функция wp_debug_mode() устанавливает настройки PHP на основе введённых констант.
Показ промахов вечно отключен для AJAX запросов, там увидать промахи можно лишь сквозь лог файл. Это устанавливается в wp_debug_mode():
Как включить показ промахов в AJAX запроса сморите в заметках в статье про AJAX.
Рекомендуется использовать «дебаг порядок» в процессе труды над сайтом (темой или плагином).
Значительно отключать «дебаг» на пролетарии сайте.
Для управления окружением разработки используйте функцию wp_get_environment_type().
Как включить «дебаг» (показ промахов в 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 кушать различные степени промахов. Если не вклиниваться в детали, то степени значимости такие:
- errors — положительная промах, какая приводит к остановке скрипта. PHP прерывает труд.
- warnings — не промах, а предупреждение о чем-либо. PHP не прерывает труд.
- 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.
В качестве иного решения можно отведать еще раз перебить настройки вывода промахов, показав их опять:
Функции WP для дебага
- wp_debug_backtrace_summary() — Получает трассировку с наименованиями функций — список наименований всех функций/методов, какие бывальщины потребованы для того, чтобы добраться до льющегося пункты в коде (откуда была потребована эта функция).
Плагины для дебага и профилирования в WordPress
В каталоге WP кушать несколько неплохих плагинов, какие расширяют возможности «дебага» и подают добавочную информацию для выявления немощных пунктов кода. Популярные из них:
Query Monitor — выводит в подвале груду здоровой информации о льющемся запросе. Сколько поре затрачено, сколько SQL запросов, какие требования, сколько поре взял любой запрос, сколько памяти затрачено, какие хуки использовались и т. д.
Debug Bar — комплекс плагинов по дебагингу и профилированию. Это основной плагин, после его установки к нему можно подключать еще иные плагины, какие расширяют возможности профилирования. Но я его как-то не оценил.
Log Deprecated Notices — вписывает в лог все заметки о присутствии устаревших функций WordPress или их параметров и т. д. Не зависит от WP_DEBUG — трудится с отключенным WP_DEBUG.
WordPress mu-plugin for debugging — альтернативный дебаггер на базе библиотеки Kint.
Дебаг в WordPress.
Для защиты, параметр debug рекомендую изменить, показать что-то негустое и популярное лишь вам.
При таком включении промахи и заметки будут выводиться на экран, но ничего логироваться не будет.