Далеко не всегда получается написать код сразу и без ошибок. Но для исправления ошибки, прежде всего, требуется её найти. Здесь мы рассмотрим процесс отслеживания ошибок с помощью отладочного журнала WordPress (debug log).
Сокрытие отладочных сообщений от посетителей является важнейшим элементом безопасности сайта. Даже в случае полной уверенности в том, что ваш сайт не генерирует ошибок, либо предупреждений вообще, посетителям может стать доступно нечто, что им знать не нужно.
Именно поэтому следует оставить включённой настройку WP_DEBUG, не показывая ошибок на страницах сайта, а производя их запись в особый файл «Журнал отладки» для дальнейшего анализа. Об этом и пойдет речь далее.
Настройка
Для разрешения генерации отладочной информации и записи в журнал без выведения на страницах сайта, потребуется определённое изменение файла wp-config.php.
Фатальные ошибки («белый экран смерти») при этом скрыть невозможно.
Просмотр журнала отладки
Файл, в котором содержится отладочная информация, называется debug.log. Он располагается в корневом каталоге вашего сайта. С помощью любого текстового редактора вы можете его читать и удалять из него информацию. Однако этот способ этот не слишком удобен, особенно при расположении журнала на сервере под нагрузкой.
Есть плагины, которые существенно упрощают работу с журналом отладки, но иногда (например, если сайт недоступен) нужно работать с файлом журнала напрямую.
Есть ряд инструментов, помогающих в работе с журналом отладки из административной панели сайта. Например, бесплатный плагин Log Viewer дает возможность читать и чистить журнал. В сочетании с плагином Debug Bar вы сможете работать с журналом в отладочной панели на любой странице сайта.
Панель отладки не стоит применять на рабочем сервере, однако польза её в процессе разработки неоценима. Установка плагинов Log Viewer и Debug Bar может производиться при помощи установщика плагинов, а также как часть комплексного плагина Developer.
Как выглядит журнал.
Любое событие, сгенерированное WP помечается временем в формате UTC.
Запись в журнал отладки произвольной информации
В определённых случаях оказывается полезным выводить дополнительную информацию в журнал, не сообщающую об ошибке, а просто помогающую в написании собственного кода. Для этого в PHP предусмотрена функция error_log().
Данная функция не предусматривает форматирования, поэтому можно создать собственную обёртку над error_log, форматирующую объекты и переменные, записываемые в журнал с помощью функции print_r(). Вот как она может выглядеть.
Не имеет смысла размещать данный код в файл functions.php вашей темы, поскольку при отладке сайта, возможно, произойдёт переключение темы на стандартную и потеря доступа к нему. Поэтому код следует оформить в виде плагина. Для этого нужно создать файл в вашем каталоге плагинов, добавить в него заголовок плагина и вышеприведённый код. Заголовок может выглядеть так:
Функция, только что созданная нами, имеет многочисленные варианты применения. Ее работу легко проверить, написав следующий код.
delaemsait.info
Включаем режим отладки WordPress
Шаблон блога с первых дней претерпевал изменения, обрастая новыми функциями, стилями, классами. Набрав критическую массу, он стал неповоротлив — очень сложно поддерживать рабочее состояние и высокую производительность. Невидимые, на первый взгляд, большие изменения произошли в прошлом году — начиная от новой верстки и работы с миниатюрами, заканчивая микроразметкой Schema.org.
Первым делом после преобразований открыл консоль разработчика в браузере и проверил наличие ошибок и предупреждений. Следующий шаг — отладка WordPress. Режим включается в файле конфигурации wp-config.php, найдите в нем строку:
и замените значение false
на
true. Строка должна получить вид:
При наличии ошибок на месте их появления будет отображено сообщение с описанием проблемы и затронутые файлы. Это могут быть ошибки разбора синтаксиса или устаревшие функции, которые исключены из ядра или заменены на новые.
Предупреждение основано на одном простом факте: сообщение об ошибке содержит абсолютный путь к файлу относительно корневой директории сервера. Сообщение видит не только администратор, а все пользователи. Наглядный пример:
Parse error: syntax error, unexpected ‘endif’ (T_ENDIF) in /u57109403/data/www/site.ru/wp-content/themes/default/index.php on line 23
Как видно из примера, значение u57109403 может являться логином доступа к серверу и злоумышленникам остается только подобрать пароль. Будьте бдительны.
webliberty.ru
Отладка с помощью WP_DEBUG
Основное средство разработки, о котором вам нужно знать — WP_DEBUG.
WP_DEBUG — это константа типа boolean, которая включает режим отладки в WordPress. Она находится в файле wp-config.php в вашей папке WordPress.
Если ее значение установлено «true», вы увидите извещения PHP на страницах сайта (не столько ошибки, сколько полезные для разработчиков сообщения и WordPress сообщения, в частности информация об устаревших функциях).
Устаревшие функции содержатся во многих релизах WordPress. Важно знать, используете ли вы устаревшую функцию в теме или плагине, над которыми вы работаете, чтобы найти ее замену.
Чтобы включить WP_DEBUG, просто добавьте следующий код в ваш файл wp-config.php:
define( 'WP_DEBUG', true );
Чтобы отключить режим, просто замените «true» на «false». Для WP_DEBUG по умолчанию установлено значение false. WP_DEBUG предоставляет удобный способ поиска решения проблем, если что-то с вашим сайтом пошло не так.
Важно помнить, что WP_DEBUG не должен использоваться на живом сайте. Эта возможность удобна при разработке, но может быть опасной на живом сайте, поскольку текст в уведомлениях PHP может показать детали вашего кода, пути к файлам и другую информацию вашим посетителям.
Записи ошибок с помощью WP_DEBUG_LOG
Другой удобный инструмент — WP_DEBUG_LOG, который может использоваться в сочетании с WP_DEBUG для сохранения всех ошибок в файл debug.log, размещенный в папке /wp-content/ вашего сайта.
Это очень удобная штука, если вы хотите потом просмотреть сообщения.
Чтобы включить запись логов отладки, просто добавьте в ваш файл wp-config.php следующий код:
define('WP_DEBUG_LOG', true);
Выключение отображения ошибок на сайте с помощью WP_DEBUG_DISPLAY
Если вы не хотите, чтобы ошибки отображались на вашем сайте, вы должны использовать WP_DEBUG_DISPLAY.
Это еще одна полезная константа, которая позволяет вам выбирать, будут ли отладочные сообщения отображаться внутри HTML вашего сайта.
По умолчанию установлено значение «true», то есть все ошибки и предупреждения отображаются. Изменив значение на «false», вы спрячете все ошибки.
Эта константа должна быть использована в сочетании с WP_DEBUG_LOG.
Чтобы использовать эту возможность, просто добавьте в код вашего файла wp-config.php следующую строку:
define('WP_DEBUG_DISPLAY', false);
Все вместе
Эти три константы легко использовать вместе, если вы хотите включить отладку и запись логов сообщений об ошибках, но хотите скрыть уведомления на вашем сайте:
// Turn debugging on define('WP_DEBUG', true); // Tell WordPress to log everything to /wp-content/debug.log define('WP_DEBUG_LOG', true); // Turn off the display of error messages on your site define('WP_DEBUG_DISPLAY', false); // For good measure, you can also add the follow code, which will hide errors from being displayed on-screen @ini_set('display_errors', 0);
Не забывайте, что WP_DEBUG используется для локальной разработки и не должен использоваться на живых сайтах.
hostenko.com
У меня APP_DEBUG=true
в файле
.env :
APP_ENV=local APP_DEBUG=true APP_LOG_LEVEL=debug APP_URL=http://test.dev
Я намеренно использовал неправильный неправильный URL (например: test.dev/asdsadsa ), который не содержится в файле маршрута web.php.
- Создать список с запятыми из массива в laravel / blade?
- Вызов неопределенного метода Illuminate Database Query Builder :: lists () при посеве после обновления до Laravel 5.3
- Как я могу установить один Laravel PHP с несколькими проектами?
- Как я могу сделать дополнительный запрос в laravel красноречивее?
- Параболические паспорта Laravel и пассы api
Я ожидал получить ошибку отладки laravel, когда маршрут не существует
Sorry, the page you are looking for could not be found. NotFoundHttpException in RouteCollection.php line 161:
Однако он продолжает показывать страницу ошибок 404 (views / errors / 404.blade.php), даже для APP_DEBUG установлено значение true.
То, что я пробовал:
1 – Я даже проверял, чтобы laravel мог читать файл .env:
Route::get('/', function() { dd(env('APP_DEBUG')); });
return true
2 – php artisan config:cache
не исправил.
3 – chmod -R 777 storage не исправило его.
ruphp.com
Множество параметров для короткого кода Для автоматического входа в систему требуется обновление страницы сохраняйте переменную, заданную в header.php, вплоть до footer.php Получать пользовательскиC.
#x43F;ределами WordPress Как перенаправить теги с старого сайта Joomla на новый сайт WordPress? Проблема с Ajax в WordPress jQuery | JJ Карусельный плагин – Невозможно установить скорость Как создать новые страницы контента для моего настраиваемого типа сообщений? Будет ли current_user больше не глобальным? Дешифрование и удаление таблиц стилей из плагина и установка таблицы стилей для детей Следующая / предыдущая связь не отображается с сообщениями 2 Сообщения Query Top Set Пользовательская таксономия в заданный период времени Сделать индивидуальные вложения частными? Плагин как пользовательская страница
www.wordpressask.com
If you have ever performed website optimization then it is likely you have read this article here. This article discusses the impact of having the debug set to true in your production application. In another one of my blogs on C#, I made the comment once about «what is a technical blog without a comparison of String vs. Stringbuilder» so I thought that same here on my IIS blog that «what is a technical blog without a debug=true entry». Therefore, here goes! Be warned, that this is an article about how to find the value in your configuration and not a discussion about the impact of it.
One important concept to understand is the Configuration Hierarchy and Effective Configuration. In summary, it means that any setting at a lower level override that same setting made at a higher level. So if you set debug=false in the machine.config file for a given .NET version, but the debug value is set to true in a web.config of the website, then for that website, debug=true. Figure 1 shows the configuration hierarchy for IIS 7+.
Figure 1 — IIS 7, IIS 7.5 and IIS 8 configuration hierarchy
There are a number of places where you can set the value of debug. Review this article which describes the compilation element and the location in which it can be set. Here is the link. Figure 2 shows how the setting exists in a websites web.config file.
Figure 2, setting the debug=true in the web.config file
You can also check the value of this setting in the Configuration Editor on the specific website, as shown in Figure 3. Notice the ‘Section’ and ‘From’ values.
Figure 3, Configuration Editor showing the compilation element for viewing the debug value
If you have some memory dumps of this process you can also review them in WinDbg. In WinDbg, a command I always execute when I review a memory dump is !findDebugTrue. Figure 4 shows the output of the command when the value is true.
Figure 4, WinDbg output for !findDebugTrue when value is true
Finally, Figure 5 shows the output from the same command when the value is false.
Figure 5, WinDbg output for !findDebugTrue when value is false
There you have it, the debug=true blog. But really, use this only for your testing environments and change the value when migrating it to production. It does have some performance impact.
NOTE: When debug=true, asp.net requests will not time out. httpRuntime settings do not apply to asynchronous handlers, only synchronous ones. ASP.NET is synchronous while MVC and Web APIs are asynchronous.
blogs.msdn.microsoft.com
От автора: для разработчика крайне важно уметь отлаживать код. В этом уроке я расскажу вам про 11 способов по отладке WordPress и ошибок PHP. Первым в списке стоит знаменитый WP_Debug, после чего мы переключимся на более продвинутые методы.
Сначала давайте приведем типы распространенных ошибок в PHP:
1 – константа WP_DEBUG
В WP существует глобальная константа, с помощью которой можно производить отладку на определенном уровне – WP_DEBUG. Вместе с этой константой идут и две другие не менее важные — WP_DEUBG_DISPLAY и WP_DEBUG_LOG.
С помощью WP_DEBUG можно включать и выключать режим отладки. WP_DEUBG_DISPLAY прячет и показывает ошибки. WP_DEBUG_LOG сохраняет ошибки в wp-content/debug.log. Задать true или false для этих трех констант можно в файле wp-config.php:
2 – метод is_wp_error()
Также для отладки в WP можно воспользоваться методом is_wp_error();. Данный метод проверяет передаваемое значение на тип WP_Error. WP_Error – объект, который можно получить в случае неудачного выполнения метода. Пример:
Код выше пытается добавить новую статью с помощью метода wp_insert_post(). Если метод не отработает, нам вернется объект WP_Error. Данный объект можно поймать и вытянуть из него сообщение об ошибке.
3 – плагин Debug Bar
Для отладки ошибок в WP можно воспользоваться плагином Debug Bar. С помощью этого полезного инструмента можно получить информацию по всем страницам сайта.
После установки у вас появится новая кнопка для отладки. По клику на нее можно провести анализ запросов, шаблонов, PHP установок и т.д.
4 – тестовый сайт
Крайне важно иметь несколько копий сайта: настоящую, тестовую и для разработки. У меня обычно есть две установки WP на один сайт. Это очень важно, ведь вы не хотите, чтобы ваши скрипты прекращали работу, как только вы включили сообщения об ошибках.
5 – плагин Simply Show Hooks
Simply Show Hooks – плагин, показывающий все хуки, которые есть на странице. Если у вас возникла такая ситуация, когда все отчеты не находят ошибку, то вам придется вылавливать все запущенные хуки.
С помощью данного плагина можно посмотреть все запущенные на странице экшены и фильтры. Код каждого хука можно проанализировать и отладить. Также плагин позволяет определить приоритет хуков.
6 – отчет об ошибках WPDB
Если для работы с базой данных вы используете класс wpdb, вам понадобится отчет об ошибках. Не важно, будет ли это просто проверка правильности работы запросов или отображение сообщений об ошибках. Пример:
7 – логи ошибок сервера
На каком-то этапе ни WP ни PHP не смогут отловить ошибки в коде. К примеру, если скрипт превысил максимальное время выполнения, PHP не выдаст ошибку. А вот Apache (или другой сервер) выдаст что-то типа «Internal Server Error». В такой ситуации нужно открыть файл логов с ошибками и посмотреть, где же закралась ошибка: в PHP или в WP. Узнать, где хранятся логи можно у провайдера хостинга. Обычно папка называется logs.
8 – логи ошибок PHP
В PHP есть свой уровень сообщений об ошибках. Очень полезная штука, особенно если запускается что-то не из WP и вызывает ряд каких-то проблем. Включить логи об ошибках и указать место их хранения можно в файле php.ini.
Строки выше включают отчеты об ошибках и задают специальный путь для хранения. Также можно запустить функцию phpinfo() и проверить error_log.
9 – проверка синтаксиса PHP
Если ваш хостинг-провайдер ограничил доступ к файлу php.ini, или у вас нет доступа к логам ошибок, ситуация немного усложняется. Однако в сети полно инструментов для решения проблемы, когда перед вами пустая страница, а ошибок нет. Один из таких инструментов — PHP Code Checker.
PHP Code Checker – инструмент для проверки ошибок синтаксиса. Он находит пропущенные точки с запятой и фигурные скобки – очень удобная штука.
10 – PHP IDE
Если PHP Code Checker не нашел ошибок в синтаксисе, нужно прибегнуть к более мощному инструменту. Мощная среда разработки типа PhpStorm подойдет для более продвинутой отладки и разобьет ваш код на части.
Эта IDE помогает в таких ситуациях, когда вы пытаете распечатать переменную, в которой хранится какая-то строка, но ничего не происходит. Быть может, где-то в коде вы переписываете эту переменную. Очень важно работать в мощной среде разработки типа PhpStorm, Eclipse или другой.
11 – отключение кэша браузера
Если вы работаете на front-end’е сайта, тогда вам нужно отключить кэш в браузере. Это обязательный шаг, так как если вы работаете с JS кодом, а он не обновлен или обновлен, но не показывает ошибок, что еще хуже, вам придется отключить кэш.
Отключение кэша говорит браузеру, чтобы тот больше не работал со старыми файлами сайта, которые хранятся на вашем жестком диске. Это относится к файлам CSS и JS.
Чтобы отключить кэш в браузере Chrome, откройте панель разработчика, кликнув правой кнопкой мыши по любому элементу страницы. Перейдите во вкладку сеть. Поставьте галочку на пункте Disable Cache вверху.
webformyself.com
В предыдущей части мы создали WordPress-проект и приступили к редактированию кода. Теперь поговорим о том, как выявить и исправить ошибки в созданном коде.
Рабочий публичный сервер должен быть настроен так, чтобы сообщения об ошибках вообще не выводились — из соображений безопасности, да и просто из эстетических соображений. Вывод ошибок можно запретить на уровне сервера (в php.ini), а также на уровне скрипта (с помощью функций ini_set() и error_reporting()). Например, чтобы гарантировано подавить вывод ошибок на вашем WordPress-сайте в независимости от настроек сервера, в wp-config.php надо добавить:
define('WP_DEBUG', false); @ini_set('display_errors', 0);
Теперь в случае ошибки посетитель увидит страницу Internal Server Error.
При разработке же все наоборот — вывод ошибок очень важен и полезен. Поэтому на сервере, используемом для разработки, вывод ошибок обязательно включаем (php.ini : display_errors = 1). В Zend Server вывод ошибок включается через панель управления Server Setup -> Directives -> Error Handling and Logging -> display_errors поставить On. Там же устанавливаем значение директивы error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT (вывод всех ошибок и предупреждений, кроме уведомлений). E_NOTICE и E_STRICT — это некритичные уведомления о соблюдении стандартов кодирования, они не влияют на работоспособность кода. Подробнее об уровнях ошибок.
Теперь возвращаемся к wp-config.php. По умолчанию режим отладки отключен:
define('WP_DEBUG', false);
Но это не значит, что ошибки не выводятся.
На самом деле error_reporting = E_ALL & ~E_NOTICE & ~E_USER_NOTICE.
Включение режима отладки:
define('WP_DEBUG', true);
означает error_reporting = E_ALL (вывод вообще всех ошибок и уведомлений), также на экран будут выводиться ошибки SQL-запросов.
Итак, что в итоге?
Для вывода фатальных ошибок и предупреждений достаточно значения по умолчанию:
define('WP_DEBUG', false);
Если вывод ошибок отключен на уровне сервера, то его можно включить на уровне скрипта:
@ini_set('display_errors', 1);
Когда нужен вывод ошибок SQL, и для устранения мелких погрешностей кода (вот здесь будут полезны уведомления), используем режим отладки:
define('WP_DEBUG', true);
Отключение вывода ошибок на экран, но при этом запись ошибок в лог-файл (wp-content/debug.log):
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0);
Еще один момент, который стоит учитывать — некоторые WordPress-плагины могут без всякого предупреждения вмешаться в процесс вывода ошибок. Например известный плагин WP-SpamFree полностью подавляет вывод ошибок не смотря на значение константы WP_DEBUG. Явный симптом error_reporting(0) — белый экран, вместо сообщения об ошибке.
Явные ошибки — найти и устранить легче всего. В тексте ошибки обычно указывается имя файла и номер строки, где произошла ошибка. Другое дело, когда явных ошибок нет, но код работает не так как вы планировали. Вот здесь уже нужен отладчик (debugger). Читайте далее: Отладка кода WordPress-проетка с помощью Zend Debugger и Eclipse PDT.
www.q2w3.ru