WordPress отчет об ошибках

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

WordPress. Как включить отображение отчета об ошибках

Если на сайте включен WP_DEBUG, все ошибки, уведомления и предупредительные сообщения PHP будут отображаться на сайте. Можно изменить настройки PHP по умолчанию таким образом, чтобы отображались только сообщения непосредственно об ошибках.

  1. WP_DEBUG

    WP_DEBUG — это константа PHP, что используется для запуска режима «отладки»(«debug») в WordPress. По умолчанию эта настройка установлена со значением «false», и обычно меняется на «true» в файле wp-config.php:

    how to enable error reporting.4

    • Для того, чтобы включить отображение отчета об ошибках в WordPress, пожалуйста, войдите в свою панель управления на хостинге, найдите Менеджер файлов (File Manager), и откройте папку вашего сайта WordPress:

      how to enable error reporting.1

    • Найдите и откройте файл wp-config.php:

      how to enable error reporting.2

    • WP_DEBUG должен быть указан со значением true:

      define('WP_DEBUG', true);

      how to enable error reporting.3

  2. WP_DEBUG_LOG — это сопровождающая настройка для WP_DEBUG, с помощью которой записи об ошибках можно сохранять в файле debug.log, что расположен в папке /wp-content/. Это полезно, если вы хотите просмотреть все уведомления позже или нужно просмотреть уведомления, сгенерированные, но не отображенные на сайте (к примеру, уведомления, сгенерированные во время запроса AJAX или запуска wp-cron). Пожалуйста, обратите внимание, что файл debug.log не будет создан в случае отсутствия ошибок или уведомлений. Также, пожалуйста, проверьте разрешения для папок и файлов (644 — для файлов; 755 — для папок).

    define('WP_DEBUG_LOG', true);

  3. WP_DEBUG_DISPLAY — еще одна дополнительная настройка WP_DEBUG, посредством которой можно задать отображение отладочных сообщений на страницах HTML. По умолчанию этот параметр принимает значение ‘true’, что означает отображение ошибок и предупреждений сразу после их генерации. Соответственно, изменение значения этого параметра в false отключит отображение ошибок на сайте. Такое значение этой настройки следует использовать в сочетании с WP_DEBUG_LOG, чтобы позже можно было просмотреть отчет сгенерированных ошибок.

    define('WP_DEBUG_DISPLAY', false);

Вы также можете просмотреть детальный видео-туториал:

WordPress. Как включить отображение отчета об ошибках

Источник

Темы

  • WP_DEBUG
    • PHP ошибки, предупреждения, и заметки
    • Устаревшие функции и аргументы
  • WP_DEBUG_LOG
  • WP_DEBUG_DISPLAY
  • SCRIPT_DEBUG
  • SAVEQUERIES
  • Пример файла wp-config.php для отладки
  • Плагины для отладки
  • Внешние ссылки

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

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

WP_DEBUG

WP_DEBUG это константа PHP , используемая для установки режима отладки в WordPress. По умолчанию она имеет значение «false», но может быть установлена как «true» в файле конфигурации wp-config.php на сайтах, на которых проводится отладка.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG', false );

Заметка: значения true и false в примере не заключены в кавычки или апострофы, поскольку являются булевыми (правда/ложь) значениями. Не заключайте их в кавычки (например 'false'), иначе они станут восприниматься как строковые значения.

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

Наверх ↑

PHP ошибки, предупреждения, и заметки

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

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

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

Наверх ↑

Устаревшие функции и аргументы

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

Наверх ↑

WP_DEBUG_LOG

WP_DEBUG_LOG это дополнение к WP_DEBUG которое позволяет сохранять ошибки в файл debug.log. Это полезно если вы хотите посмотреть ошибки позже или посмотреть то, что не выводится на экран (например для AJAX запросов или работы wp-cron).

Заметьте, что запись в лог производится внутренней функцией PHP error_log(), она очень удобна для отладки событий AJAX.

При установке в значение true, журнал будет сохраняться как wp-content/debug.log на вашем сайте. Вы можете задать альтернативное имя, для сохранения его в другом месте.

define( 'WP_DEBUG_LOG', true );
-или-
define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );

Заметка: Для работы WP_DEBUG_LOG нужно включить WP_DEBUG (true). Вы можете независимо от этого отключить WP_DEBUG_DISPLAY.

Наверх ↑

WP_DEBUG_DISPLAY

WP_DEBUG_DISPLAY это другое дополнение для WP_DEBUG, которое контролирует вывод сообщений отладки в HTML код страницы (на экран). Значение по умолчанию — ‘true’, что позволяет видеть ошибки и предупреждения на экране, в момент их возникновения. Установка значения как false спрячет все ошибки, что можно использовать вместе с WP_DEBUG_LOG, чтобы просмотреть ошибки из файла позже.

define( 'WP_DEBUG_DISPLAY', false );

Заметка: Для работы WP_DEBUG_LOG нужно включить WP_DEBUG (true). Вы можете независимо от этого использовать WP_DEBUG_LOG

Наверх ↑

SCRIPT_DEBUG

SCRIPT_DEBUG это константа, позволяющая использовать версии для разработки CSS и JavaScript файлов ядра, вместо их оптимизированных версий, которые используются по умолчанию. Константа полезна при тестировани изменений в стандартных файлах .js и .css. По умолчанию — false.

define( 'SCRIPT_DEBUG', true );

Наверх ↑

SAVEQUERIES

Определение SAVEQUERIES будет сохранять запросы к СУБД в массив, который можно проанализировать. При определении константы как true, будут сохраняться все запросы, время исполнения, функция вызова запроса.

define( 'SAVEQUERIES', true );

Массив сохраняется в глобальном $wpdb->queries.

Заметка: Это сильно снижает производительность вашего сайта.

Наверх ↑

Пример файла wp-config.php для отладки

Следующий код в файле wp-config.php включит запись всех ошибок, предупреждений и заметок PHP в файл debug.log внутри папки wp-content. Он также отключит вывод на экран (в код страницы): 

// Включить отладку WP_DEBUG
define( 'WP_DEBUG', true );

// Включить журнал /wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// Отключить вывод на экран
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Использовать версии JS и CSS для разработчика (при тестировании изменений в них)
define( 'SCRIPT_DEBUG', true );

Заметка: Это нужно вставить перед /* Это всё, дальше не редактируем. Успехов! */ в файл wp-config.php .

Наверх ↑

Плагины для отладки

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

  • Query Monitor
  • Debug Bar
  • Log Deprecated Notices

Наверх ↑

Внешние ссылки

  • Генератор файла «wp-config.php»
  • Плагин «No White Screen»: показывает ошибку вместо белого экрана

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

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

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

Типы проблем, с которыми вы можете столкнуться, включают низкую производительность, некорректное или поврежденное содержимое, сообщения об ошибках и, что хуже всего: белый экран смерти (WSoD), который означает, что ваш сайт потерпел крах и требует немедленного внимания.

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

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

Что такое отладка?

Что такое отладка?

Отладка — это задача, которую разработчики выполняют для обнаружения и удаления ошибок (также называемых багами) из своих программ. Это делается с помощью специализированных инструментов, которые позволяют вам видеть, что происходит внутри программы во время ее выполнения.

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

Давайте посмотрим несколько вариантов.

1. WP_DEBUG

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

Чтобы включить WP_DEBUG, вам нужно выполнить некоторое кодирование, отредактировав файл wp-config.php и добавив необходимые строки, чтобы команда записала все действия в журнале. Эта задача кодирования не для всех: вам нужно быть очень осторожным при редактировании файла wp-config.php, потому что, если вы пропустите строку или даже символ, ваш сайт может перестать работать. Кроме того, сделайте резервную копию вашего сайта/файлов, прежде чем делать что-либо. Если вы все испортите, вы можете восстановить резервную копию и откатить все обратно до нормального состояния.

Чтобы отредактировать файл wp-config.php, используйте файловый менеджер вашего хостинг-провайдера или используйте FTP-клиент, чтобы загрузить файл и открыть его локально в предпочитаемом вами текстовом редакторе. Файл находится в главном каталоге вашей установки WordPress. После того, как вы откроете его, найдите строку, где определен WP_DEBUG. Это должно выглядеть так:

define('WP_DEBUG', false);

Если такой строки нет, поищите следующий комментарий:

/* That’s all, stop editing! Happy blogging. */

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

define('WP_DEBUG', true); 
define('WP_DEBUG_LOG', true); 
define('WP_DEBUG_DISPLAY', false); 
@ini_set('display_errors',0);

Сохраните измененный файл и, если вы используете FTP, загрузите его на свой сайт. Затем попытайтесь спровоцировать ошибку (или дождитесь ее появления) и проверьте файл debug.log. Вы найдете его в папке wp-content вашей установки WordPress. Вы можете открыть его с помощью текстового редактора и найти сообщения об ошибках, которые показывают, что вызывает проблемы на вашем сайте.

После этого вы должны отключить ведение журнала, изменив значения true на false во всех строках, которые вы добавили или изменили в файле wp-config.php.

2. Отчеты об ошибках WPDB

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

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

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

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

define('SAVEQUERIES', true);

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

global $wpdb; 
print_r($wpdb->queries);

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

3. Использование промежуточного сайта

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

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

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

Но если ваш хостинг-провайдер не предлагает вам такую ​​возможность, вы можете создать промежуточный сайт с помощью плагина WP Staging. Этот плагин позволяет легко клонировать ваш сайт, а затем использовать клон, как если бы он был реальным. Вы всегда будете знать, когда находитесь в рабочей среде, потому что оранжевая полоса в верхней части экрана скажет вам об этом.

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

4. Query Monitor

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

wordpressQuery Monitor

После установки и активации Query Monitor начинает отображать информацию о поведении вашего сайта наиболее полезными способами.

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

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

5. Инструменты разработчика Firefox

Ранее известный как Firebug, Инструменты разработчика Firefox — это специальная версия Firefox, созданная специально для разработчиков и предлагающая новейшие функции и инструменты для разработки. Он не является специфичным для WordPress, но оказывается очень полезным для отладки сайтов.

Инструменты разработчика Firefox неизбежно сравниваются с более популярными Chrome DevTools. При этом солидная компоновка Firefox выделяется. Например, вы можете щелкнуть правой кнопкой мыши любой элемент, чтобы открыть вкладку «Инспектор», и веб-консоль предлагает расширенный вывод при печати объектов, показывая гораздо больше информации, чем просто его имя.

Он предоставляет дополнительную информацию для определенных типов, позволяя детально изучить свойства объекта и предоставить более подробную информацию для элементов DOM.

Инструменты разработчика Firefox

С помощью инструмента «Инспектор» вы можете просматривать и изменять страницы HTML и CSS, что позволяет делать это со страницами, загруженными локально в Firefox или на удаленном устройстве, например Firefox для Android.

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

6. New Relic

Являясь одним из крупнейших игроков в отрасли APM (Application Performance Monitoring), New Relic является коммерческим продуктом, который ежедневно используют тысячи разработчиков во всем мире, чтобы получить представление о производительности своих программных продуктов. Он имеет плагиновую архитектуру, которая обеспечивает добавленную функциональность третьими сторонами, что приводит к практически бесконечному спектру технологий, которые можно отслеживать с помощью этого инструмента.

New Relic

При цене от 9,37$ до 200$ за хост в месяц он предназначен для профессиональной отладки. Он также несет в себе расширенную кривую обучения, поэтому помимо затрат денег на решение, вам также нужно потратить время, чтобы научиться его использовать. Пользователи New Relic ценят тот факт, что он легко интегрируется в приложения для APM и мониторинга инфраструктуры.

7. Debug Bar

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

Основной плагин, Debug Bar, предоставляет базовую функциональность, расширенную остальными плагинами. Он работает со встроенными в WordPress флагами отладки, такими как WP_DEBUG и SAVEQUERIES. Когда эти флаги активны, панель отладки добавляет полезную информацию об отладке, такую ​​как предупреждения PHP и запросы MySQL, избавляя вас от необходимости искать и читать файлы журнала.

Debug Bar

Каждый параметр в меню панели отладки предоставляет свою долю мощности отладки. В консоли, например вы можете запускать произвольный PHP-код, который отлично подходит для тестирования содержимого переменных (среди прочего).

Cron отображает информацию о запланированных событиях WordPress, такую ​​как время следующего события, количество запланированных событий, список пользовательских запланированных событий и т. Д. Действия и фильтры — еще одна опция для отображения хуков, прикрепленных к текущему запросу. На вкладке «Действия» отображаются действия, связанные с текущим запросом, а на вкладке «Фильтры» отображаются все теги фильтров, а также функции, прикрепленные к каждому из них.

Заключение

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

Также рекомендуем прочитать:

  1. 10 способов SEO оптимизации WordPress и производительности контента
  2. 7 способов, как увеличить скорость загрузки вашего сайта
  3. Что такое черный список URL-адресов и как от него защититься?
  4. Увеличить производительность WordPress с помощью этих плагинов

Запуск сайта на ВордПресс — задача, требующая немало сил и времени. И одно дело, если нужно разработать простой лендинг, а другое, когда создаётся крупный многофункциональный ресурс. Во втором случае, когда к сайту подключается много дополнительных инструментов, работающих совместно, разработчик наверняка столкнется с массой трудностей и ошибок. Последние могут быть связаны с совместимостью, недоработками в коде, неправильной установкой или настройкой плагинов, и другими обстоятельствами.

Обнаружить причину появления ошибки может быть сложно. Особенно, начинающему пользователю WordPress.Тем более, что иногда могут появляться ошибки, которые внешне никак не проявляются, но при этом отрицательно влияют на успешность проекта. Например, негативно сказываясь на скорости загрузки страниц. В связи с этим возникает необходимость вовремя находить и устранять ошибки разного рода.

Самостоятельно проверять весь код, подключенные инструменты и т.д. — долго и сложно. Проще и быстрее использовать бесплатные плагины для поиска ошибок ВордПресс. Эти инструменты комплексно анализируют весь сайт. Порой они находят недоработки, которые вы сами бы не заметили, даже при очень внимательном изучении результата своей работы.

Для вашего удобства, мы собрали топ-7 лучших плагинов для поиска ошибок WP в одну статью. В неё вошли только полезные инструменты, проверенные временем и другими вебмастерами. А их бесплатность позволяет использовать их без ограничений, даже если у вас много проектов.

Health Check & Troubleshooting

Один из самых популярных плагинов для поиска ошибок в ВордПресс. Он регулярно обновляется и используется на более чем 200 тысячах сайтов. Для русскоязычных вебмастеров инструмент особенно удобен, благодаря наличию перевода на русский. Health Check & Troubleshooting имеет открытый исходный код, поэтому:

  • проверка вашего проекта с его помощью абсолютно безопасна;
  • опытные программисты могут доработать инструмент под свои потребности, расширив его функциональность.

Плагин для WordPress в автоматическом режиме проверит:

  • наличие общеизвестных проблем, часто возникающих на большом количестве сайтов;
  • есть ли ошибки в конфигурации;
  • целостность файлов WP;
  • совместимость с будущими обновлениями PHP;
  • функционал электронной почты;
  • защищенность соединения;
  • работоспособность функции JSON;
  • работоспособность запланированных событий (например, отложенных публикаций).

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

Debug This

Ещё один бесплатный инструмент, который будет полезен разработчикам WP. В отличие от предыдущего, он не имеет перевода на русский язык, а также реже обновляется. Тем не менее, он пользуется популярностью и очень эффективен. Его главное достоинство — поиск и вывод всей необходимой информации в один клик. В неё входят сведения о:

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

Debug This позволяет быстро провести отладку. Вы потратите меньше времени на поиск ошибки, из-за которой возникла проблема, ведь получите общую информацию сразу обо всём, в виде 60 отчётов. При этом просмотреть необходимые сведения можно прямо из панели администратора. А когда ошибка будет обнаружена, вы сможете либо устранить её самостоятельно, либо обратиться за помощи в службу поддержки ВордПресс, темы или другого продукта, с которым она связана.

Query Monitor

Как становится понятно из названия, данный инструмент предназначен для мониторинга и отладки запросов разного рода. Например, к базе данных или редактору блоков. Его используют в более чем 100 тысячах проектов на ВордПресс, что подтверждает его полезность. Query Monitor имеет перевод на русский язык, поэтому подойдет даже не знающим английского языка вебмастерам.

В процессе поиска ошибок плагин проверяет и обнаруживает:

  • иерархию шаблонов и их составляющих, показывая, есть ли незагруженные или конфликтующие элементы;
  • запросы к базе данных, которые будут выведены отфильтрованными по типу и ответственному компоненту (вы будете четко видеть, какие запросы относятся к конкретному плагину или шаблону);
  • проблемы с файлами перевода сайта на разные языки;
  • доступ обычных посетителей вашей странички на ВордПресс к тем разделам, которые должны быть для них закрыты;
  • ошибки PHP, с указанием ответственных компонентов;
  • недочеты в настройках сценариев и стилей, с учетом всех зависимостей и их нарушений;
  • значения условных функций ВордПресс, таких как is_single() и подобных;

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

Query Monitor может работать в автоматическом режиме, и когда поиск ошибок оказывается успешным, отображать в админ-панели соответствующие уведомления. При этом инструмент не хранит собираемые данные на сторонних серверах и не отправляет их третьим лицам, что легко проверяется изучением его открытого исходного кода. Поэтому его применение безопасно даже в проекте, где важна конфиденциальность данных.

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

Black Bar

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

К сожалению, с последними версиями ВордПресс инструмент не тестировался. Его корректная работа гарантируется только если у вас WP до 5.1.4 версии. Поэтому он подойдёт не всем вебмастерам. Если у вас более поздний выпуск WordPress — попробовать плагин можно, но не факт, что он поможет вам обнаружить ошибки.

Функции Black Bar:

  • отображение появляющихся в процессе загрузки страниц ошибок PHP;
  • проверка глобальных переменных, таких как POST, COOKIE, SESSION, GET, SERVER;
  • показывает совершенные запросы MySQL и сколько времени было потрачено на их реализацию;
  • отладка плагинов и шаблонов ВордПресс через консоль.

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

BulletProof Security

Данный плагин проводит поиск ошибок в плане безопасности вашего проекта на WordPress. Он высоко оценён вебмастерами и часто обновляется. На форуме поддержки разработчики помогают пользователям решать возникающие проблемы. Приятный бонус — перевод BulletProof Security на русский язык, делающий его использование комфортнее для начинающих. Что делает данный инструмент:

  • сканирует проект на наличие вредоносного кода;
  • выполняет функцию файрвола;
  • защищает форму авторизации от проникновения посторонних;
  • создает резервную копию базы данных;
  • помогает устранить недоработки, позволяющие работать на сайте спамерам;
  • ведёт журналы безопасности и ошибок HTTP;
  • предоставляет подробную информацию о ВордПресс и подключенных инструментах.

BulletProof Security имеет 3 темы оформления, позволяет обслуживать как внешний, так и внутренний интерфейс проекта, и вообще очень дружественен к пользователям. Если для вас важна безопасность, тогда данный плагин для WordPress поможет её улучшить, а также найти ошибки, которые потенциально ей вредят.

У инструмента есть PRO-версия, расширяющая её функциональность. Но её стоит рассматривать только опытным вебмастерам, которые убедились в том, что им подходит основная, но для решения всех задач нужны дополнительные возможности.

Media Cleaner

Еще один полезный плагин, однако, находящий совсем другой тип ошибок, нежели представленные в начале нашего топа инструменты. Media Cleaner сканирует вашу «Библиотеку медиафайлов», с целью обнаружения файлов и записей, которые:

  • засоряют ваш ВордПресс и не используются;
  • повреждены;
  • работают неправильно.

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

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

Media Cleaner доступен на русском и английском языках. Он тестировался на разных версиях ВордПресс, в том числе и на последних выпусках. Он совместим с любыми шаблонами, плагинами и записями медиафайлов. Если у вас многофункциональный сайт с большим количеством подключенных дополнительных инструментов, тогда для полноценной очистки может потребоваться Pro-версия, цена которой (на 1 год, для 1 сайта) составляет $24.

WP Safe Mode

Инструмент используется для включения в ВордПресс так называемого «безопасного режима». В нём вы сможете отключать и включать определённые плагины и менять темы, чтобы проверить, как работает сайт в видоизменённом варианте. Это дает возможность разобраться, из-за какого именно дополнения возникла та или иная ошибка.

Установить WP Safe Mode можно через FTP, что особенно выручает в ситуациях, когда доступ к сайту был потерян из-за ошибок PHP. К примеру, при возникновении «белого экрана смерти» или пустых экранов. Иногда это единственный способ восстановить работоспособность проекта WordPress, потому что без активации безопасного режима с отключением дополнений, разобраться с проблемой и причинами её появления как-то по-другому невозможно.

Другие достоинства плагина:

  • включить безопасный режим можно только для своего IP-адреса, благодаря чему вы сможете заниматься отладкой, пока посетители сайта пользуются им также, как и до начала технических работ;
  • установка в автоматическом режиме;
  • назначение сочетания клавиш админ-панели, которое будет включать и отключать безопасный режим.

WP Safe Mode не доступен на русском языке, поэтому у не знающих английский пользователей ВордПресс могут возникнуть незначительные трудности с его применением.

Подведём итоги

Собранный в этой статье топ-7 плагинов для поиска ошибок будет полезен каждому вебмастеру, работающему с ВордПресс. Особенно начинающим пользователям, которые ещё не сталкивались с распространенными проблемами и не знают пути их решения. Если на вашем сайте появились ошибки, то в первую очередь, для обнаружения их причин, используйте именно эти плагины, потому что они:

  • бесплатные и доступны всем желающим;
  • имеют открытый исходный код и полностью безопасны;
  • проверены опытом других работающих с WordPress мастеров.

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

Отладка WordPress: 11 хороших советов и техник

От автора: для разработчика крайне важно уметь отлаживать код. В этом уроке я расскажу вам про 11 способов по отладке WordPress и ошибок PHP. Первым в списке стоит знаменитый WP_Debug, после чего мы переключимся на более продвинутые методы.

Сначала давайте приведем типы распространенных ошибок в PHP:

A. Замечание: сообщение об ошибке с самым низким уровнем важности в PHP. Не факт, что ваш код неправильный, просто в каких-то местах его можно переписать. Пример: в функцию, которая ожидает строку, передано null.

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

C. Фатальная ошибка: опасный индикатор того, что что-то пошло действительно не так, и скрипт был остановлен. Пример: вызов несуществующей функции.

Бесплатный курс «Создание тем на WordPress. Быстрый старт»

Изучите курс и узнайте, как создавать уникальные темы на WordPress с нестандартной структурой страниц

Скачать курс

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:

define(«WP_DEBUG», true);

define(«WP_DEBUG_DISPLAY», true);

define(«WP_DEBUG_LOG», true);

2 – метод is_wp_error()

Также для отладки в WP можно воспользоваться методом is_wp_error();. Данный метод проверяет передаваемое значение на тип WP_Error. WP_Error – объект, который можно получить в случае неудачного выполнения метода. Пример:

$post = array(

    ‘post_title’    => ‘Test post’,

    ‘post_content’  => ‘This is my post.’,

    ‘post_status’   => ‘publish’,

    ‘post_author’   => 1

);

$result = wp_insert_post( $my_post );

if(is_wp_error($result)){

    echo $return—>get_error_message();

}

Код выше пытается добавить новую статью с помощью метода wp_insert_post(). Если метод не отработает, нам вернется объект WP_Error. Данный объект можно поймать и вытянуть из него сообщение об ошибке.

3 – плагин Debug Bar

Для отладки ошибок в WP можно воспользоваться плагином Debug Bar. С помощью этого полезного инструмента можно получить информацию по всем страницам сайта.

После установки у вас появится новая кнопка для отладки. По клику на нее можно провести анализ запросов, шаблонов, PHP установок и т.д.

4 – тестовый сайт

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

5 – плагин Simply Show Hooks

Simply Show Hooks – плагин, показывающий все хуки, которые есть на странице. Если у вас возникла такая ситуация, когда все отчеты не находят ошибку, то вам придется вылавливать все запущенные хуки.

С помощью данного плагина можно посмотреть все запущенные на странице экшены и фильтры. Код каждого хука можно проанализировать и отладить. Также плагин позволяет определить приоритет хуков.

Бесплатный курс «Создание тем на WordPress. Быстрый старт»

Изучите курс и узнайте, как создавать уникальные темы на WordPress с нестандартной структурой страниц

Скачать курс

6 – отчет об ошибках WPDB

Если для работы с базой данных вы используете класс wpdb, вам понадобится отчет об ошибках. Не важно, будет ли это просто проверка правильности работы запросов или отображение сообщений об ошибках. Пример:

global $wpdb;

// перед посылкой запроса:

$wpdb—>show_errors = TRUE;

$result = $wpdb—>get_results(«SELECT field_value FROM table_name»);

if(! $result){

    $wpdb—>print_error();

    // или можно показывать последнюю попытку.

    echo $wpdb—>last_query;

}

7 – логи ошибок сервера

На каком-то этапе ни WP ни PHP не смогут отловить ошибки в коде. К примеру, если скрипт превысил максимальное время выполнения, PHP не выдаст ошибку. А вот Apache (или другой сервер) выдаст что-то типа «Internal Server Error». В такой ситуации нужно открыть файл логов с ошибками и посмотреть, где же закралась ошибка: в PHP или в WP. Узнать, где хранятся логи можно у провайдера хостинга. Обычно папка называется logs.

8 – логи ошибок PHP

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

error_reporting = E_ALL | E_STRICT

error_log = /var/log/php_error.log

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

Заключение

Эти 11 советов – ваше руководство по отладке. Сама отладка может быть очень утомительной в большинстве случаев, но эти советы сделают этот процесс проще. Пишите свои советы по отладке WP в комментариях!

Автор: Loai Nagati

Источник: //www.sitepoint.com/

Редакция: Команда webformyself.

Бесплатный курс «Создание тем на WordPress. Быстрый старт»

Изучите курс и узнайте, как создавать уникальные темы на WordPress с нестандартной структурой страниц

Скачать курс

Изучите курс и узнайте, как создать тему на WordPress

Смотреть

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

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

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

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

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

  • пример исправления скорости загрузки сайта через профилирование слабых мест с помощью xDebug + phpStorm.

  • Profiling WordPress Sites (видео)

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

  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

Константы обычно определяются в файле wp-config.php.

wp_initial_constants() определяет дефолтные значения констнат, если они не установлены вручную. Функция срабатывает на раннем этапе загрузки WordPress.

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

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

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

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

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

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

Важно отключать «дебаг» на рабочем сайте.

Как включить «дебаг» (показ ошибок в 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 (логирование в файл).

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

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

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 ); // дебаг включен

Заметка: нельзя указывать false в кавычках — ‘false’. В этом случае дебаг будет включен, потому что значение равно строке false, а не логическому — нет.

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

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

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

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

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

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

WP_DEBUG_DISPLAY

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

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

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

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

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

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

WP_DEBUG_LOG

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

Еще один компонент дебага. Включает запись ошибок в файл /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`

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

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-запросов.

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

Например, вы разрабатываете тему или плагин, допустили ошибку в коде. Естественно сайт «упал». А из-за чего не понятно — WordPress показывает стандартное сообщение о технических неполадках.

Вот тут то нам и пригодится показ ошибок PHP.

Для того, чтобы включить показ ошибок, необходимо добавить одну запись в файл wp-config.

Файл wp-config содержит основные параметры и настройки вашего сайта на WordPress. Он хранит такие важные данные как: настройки подключения к Базе Данных, префикс для таблиц БД и адрес для входа в админку, если WordPress установлен в подкаталог.

Добавьте следующий код в файл wp-config:

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

Возможно, эта строка уже присутствует в файле со значением FALSE. В таком случае не нужно дублировать ее, просто измените FALSE на TRUE.

С помощью этого кода вы переведете WordPress в режим отладки (debug mode). Нужно быть готовым к тому, что при включении режима отладки WordPress начнет отображать все предупреждения и ошибки на сайте в самом верху страницы как в админке, так и на самом сайте.

Поэтому, после завершения всех работ либо удалите эту строчку, либо отключите показ ошибок следующей записью:

define( 'WP_DEBUG', false );

В предыдущей части мы создали 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.

Источник

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

В первую очередь, следует понимать, что ошибки бывают разной степени “критичности”. Чаще всего вы встретите так называемые предупреждения “Warnings“, а также фатальные ошибки “Fatal errors“.

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

Во втором случае вы можете просто видеть белый экран вместо какой-то из страниц.

Как отключить вывод ошибок

Следующий код выключает вывод ошибок на страницах сайта. Его необходимо добавить в файл wp-config.php, находящийся в корне вашего сайта. Проще всего найти в этом файле текст define ( 'WP_DEBUG ", false); и вместо него добавить:

error_reporting(0); // выключаем вывод информации об ошибках
ini_set('display_errors', 0); // выключаем вывод информации об ошибках на экран
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

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

Как включить вывод ошибок?

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

error_reporting(E_ALL); // включаем вывод ошибок
ini_set('display_errors', 1); // включаем вывод ошибок на экран
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);

Разместить этот код необходимо один в один как и предыдущий в файле wp-config.php

Плагины для поиска ошибок в WordPress (дебаг и профилирование)

Для WordPress есть несколько замечательных плагинов, которые позволят более глубоко погрузиться в процесс поиска ошибок и их причин. Вот несколько популярных из них:

  • Query Monitor – выводит в футере довольно много полезной информации, в частности о запросах, выполненных во время генерации текущей страницы. Среди всей выводимой информации приведены время генерации страницы, сколько было SQL запросов, какие именно и время их выполнения, сколько памяти потрачено, какие хуки использованы и другое.
  • Debug Bar – набор плагинов для дебага. Это основной плагин, к которому можно подключать дополнительные, расширяющие функциональность основного.
  • Log Deprecated Notices – записывает информацию о наличии устаревших функций в WordPress или их параметров, работа плагина не зависит от значений константы WP_DEBUG, то есть работает всегда.
  • WordPress mu-plugin for debugging – альтернативный плагин на базе библиотеки Kint.
  • Clockwork для WordPress – интересный плагин для отладки через консоль браузеров Google Chrome или Firefox, есть возможность отладки AJAX-запросов.

Еще интересное:

Акции, скидки на хостинг и домены

Скидка на домены .CITY

Скидка на домены .CITY

Новое акционное предложение уже доступно для вас – скидка 70% на регистрацию домена .CITY Только до конца июня покупайте #домен #city по […]

Подробнее

Акции, скидки на хостинг и домены

Подарки за отзывы

Подарки за отзывы

Почему? Каждый из нас знает, что позитивные отзывы оставляют единицы, в первую очередь просто из-за лени 🙂 . А для […]

Подробнее

Источник

No one likes to see errors on their website. Not only do they look bad to visitors and potential customers, but they also indicate that something’s wrong. But they’re, unfortunately, an inevitable part of running a site. The good news is that following a few best practices and being proactive can dramatically reduce the number of errors you experience. 

One way to monitor potential site issues — or troubleshoot existing ones — is to keep and review an error log. Let’s dive into this a bit more.

What is error logging and why is it important?

Error logging is the process of tracking and monitoring issues that occur on a website. This is usually done with a record of simple text files that live on your web server and are updated whenever an error occurs. Error logs are used to identify the number of problems that occur, provide details about each one, and show when it took place.

How to enable error logging

To enable error logging on your WordPress site, you’ll need sFTP access, available with WordPress.com plugin-enabled plans. This allows you to edit your website files remotely. In this case, you’ll be working with the wp-config.php file, which holds the basic configuration settings for your website.

A word of warning: you should only use sFTP and edit your wp-config.php file if you feel comfortable doing so. Mistakes can cause catastrophic errors on your website. If you don’t have experience changing these types of files, you may want to hire a developer or reach out to WordPress.com support for help.

1. Connect to your website via sFTP

You’ll need to start by enabling sFTP on your site. Go to My Site(s) → Settings → Hosting Configuration and click the Enable SFTP button.

Then, you’ll see your sFTP login details: URL, Port Number, Username, and Password. You’ll need to input these into FTP software, like FileZilla, to access your site. Follow these detailed instructions to connect to your WordPress.com website.

2. Find and download your wp-config.php file

Navigate to your wp-config.php file. This sits in the root directory of your file structure, alongside folders such as wp-content. Download this file, so you have a backup copy on hand.

3. Edit the wp-config.php file

Edit your wp-config.php file using a text editor such as Notepad.

Look for define( ‘WP_DEBUG’, false ); and replace this text with the following:

define( ‘WP_DEBUG’, true );

if ( WP_DEBUG ) {

        @error_reporting( E_ALL );

        @ini_set( ‘log_errors’, true );

        @ini_set( ‘log_errors_max_len’, ‘0’ );

        define( ‘WP_DEBUG_LOG’, true );

        define( ‘WP_DEBUG_DISPLAY’, false );

        define( ‘CONCATENATE_SCRIPTS’, false );

        define( ‘SAVEQUERIES’, true );

}

You’ve now successfully enabled error logging. You should only have this feature turned on while troubleshooting. Otherwise, it can leave your site more vulnerable to hacking attempts. To disable logging, simply delete the code you just added and restore the following:

define( ‘WP_DEBUG’, false );

How to view the error log manually

Once the log is enabled, you’ll need to load your website to trigger any error codes. Those codes are stored in a file called debug.log, which you can access via sFTP by following the same steps as above. 

You can find the debug.log file inside of the wp-content folder. If there are errors, the file will appear. However, if there aren’t any errors, then you won’t see it at all — congratulations!

Once you find the file, download it to your computer to view the full log, using a text editing software like Notepad. It will look something like this:

This file will provide valuable information that will point you, or your developer, to the source of your problem. 

How to view the error log using a plugin 

Using a plugin to find your error log can be an easier and faster method, depending on your level of experience. In the WordPress dashboard, click on Plugins → Add New. Search for “Error Log Monitor” and click Install → Activate.

This plugin installs a widget on your WordPress dashboard that allows you to access your error log. If you haven’t enabled error logging correctly, the widget will display instructions on how to do so. However, you should ignore these instructions, as they’re incorrect for a WordPress.com installation. Instead, use the ones listed above.

If you can’t see the dashboard widget, click on the Screen options tab at the top of the WordPress dashboard and ensure that “PHP error log” is checked.

How to find the plugin or theme that’s causing an error

Error logs are not inherently easy to read, but they do give insightful information into the cause of an error.

Typically, each line in your error log will display a message, alongside the date and time it happened and the file in which the error occurred. It also lists the line number where the error is located. For example:

Apr 20, 15:08:59

Notice: Undefined index: fg2 in /wordpress/themes/pub/varia/functions.php on line 166

Let’s break this down. First of all, there’s the date and time of the error: April 20, 15:08:59. This helps you determine if this was a one-off glitch or a recurring issue.

Then, you can see the type of error that’s been logged. Here are a few common types of error you may see here:

  • Notice. These are more warnings than errors, as they don’t actually stop your website code from executing. While you should still address a notice, your site will most likely still function, although potentially not as designed.
  • Parse error. This is typically the result of a mistake in the syntax of the underlying PHP code of the website (often in a theme or plugin). Parse errors include things like missing semicolons, parentheses, and other similar mistakes. A parse error will stop executing code when it hits the problem, so your site may look visibly broken or not function as intended.
  • Fatal error. This is often caused by undefined functions or classes, like a typo or poor coding practice. You can avoid it by using high-quality code, along with functions such as class_exists or function_exists.

In this case, the error is a notice.

Next, we see the error itself. In the example above the error is “undefined index.” This is followed by the specific location of the problem. In the above example, the error is occurring with the functions.php file of the Varia theme.

How to fix errors

Now that you can see your errors, it’s time to troubleshoot. Here’s a few things you can try:

  • If you’re a developer and the error is in your custom code, go to the line number in the log entry and work to debug.
  • If the error is within a theme or plugin, start by checking for any available updates. Keeping your plugins and themes up to date is critical for avoiding bugs and maintaining website security. Once you’ve applied any updates, re-check the error log to see if there are any new entries. If the error still exists, reach out to the plugin author or consider switching to an alternative. 
  • The error may also be caused by a conflict between two plugins. Try using the WordPress troubleshooting mode to fix this problem.
  • If the problem occurred immediately after installing or updating a plugin, deactivate it to see if the error persists. If it doesn’t, the plugin is the likely cause and you may want to find an alternative. If the error occured after a core update, you may need to manually deactivate plugins to find the source.

Troubleshooting with the WordPress error log

WordPress, like any software, may occasionally run into problems. It may seem confusing to find and fix those problems, but the error log can be a huge help! It enables you to learn valuable information that can help you troubleshoot and solve site errors in a timely manner.

To avoid errors, always use well-maintained plugins and themes, and keep on top of updates. Need more help? If you have a WordPress plugin-enabled plan, you benefit from world-class Happiness Engineers that can provide guidance.

Источник

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

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

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

Типы проблем, с которыми вы можете столкнуться, включают низкую производительность, некорректное или поврежденное содержимое, сообщения об ошибках и, что хуже всего: белый экран смерти (WSoD), который означает, что ваш сайт потерпел крах и требует немедленного внимания.

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

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

Что такое отладка?

Что такое отладка?

Отладка — это задача, которую разработчики выполняют для обнаружения и удаления ошибок (также называемых багами) из своих программ. Это делается с помощью специализированных инструментов, которые позволяют вам видеть, что происходит внутри программы во время ее выполнения.

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

Давайте посмотрим несколько вариантов.

1. WP_DEBUG

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

Чтобы включить WP_DEBUG, вам нужно выполнить некоторое кодирование, отредактировав файл wp-config.php и добавив необходимые строки, чтобы команда записала все действия в журнале. Эта задача кодирования не для всех: вам нужно быть очень осторожным при редактировании файла wp-config.php, потому что, если вы пропустите строку или даже символ, ваш сайт может перестать работать. Кроме того, сделайте резервную копию вашего сайта/файлов, прежде чем делать что-либо. Если вы все испортите, вы можете восстановить резервную копию и откатить все обратно до нормального состояния.

Чтобы отредактировать файл wp-config.php, используйте файловый менеджер вашего хостинг-провайдера или используйте FTP-клиент, чтобы загрузить файл и открыть его локально в предпочитаемом вами текстовом редакторе. Файл находится в главном каталоге вашей установки WordPress. После того, как вы откроете его, найдите строку, где определен WP_DEBUG. Это должно выглядеть так:

define('WP_DEBUG', false);

Если такой строки нет, поищите следующий комментарий:

/* That’s all, stop editing! Happy blogging. */

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

define('WP_DEBUG', true); 
define('WP_DEBUG_LOG', true); 
define('WP_DEBUG_DISPLAY', false); 
@ini_set('display_errors',0);

Сохраните измененный файл и, если вы используете FTP, загрузите его на свой сайт. Затем попытайтесь спровоцировать ошибку (или дождитесь ее появления) и проверьте файл debug.log. Вы найдете его в папке wp-content вашей установки WordPress. Вы можете открыть его с помощью текстового редактора и найти сообщения об ошибках, которые показывают, что вызывает проблемы на вашем сайте.

После этого вы должны отключить ведение журнала, изменив значения true на false во всех строках, которые вы добавили или изменили в файле wp-config.php.

2. Отчеты об ошибках WPDB

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

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

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

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

define('SAVEQUERIES', true);

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

global $wpdb; 
print_r($wpdb->queries);

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

3. Использование промежуточного сайта

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

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

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

Но если ваш хостинг-провайдер не предлагает вам такую ​​возможность, вы можете создать промежуточный сайт с помощью плагина WP Staging. Этот плагин позволяет легко клонировать ваш сайт, а затем использовать клон, как если бы он был реальным. Вы всегда будете знать, когда находитесь в рабочей среде, потому что оранжевая полоса в верхней части экрана скажет вам об этом.

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

4. Query Monitor

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

wordpressQuery Monitor

После установки и активации Query Monitor начинает отображать информацию о поведении вашего сайта наиболее полезными способами.

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

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

5. Инструменты разработчика Firefox

Ранее известный как Firebug, Инструменты разработчика Firefox — это специальная версия Firefox, созданная специально для разработчиков и предлагающая новейшие функции и инструменты для разработки. Он не является специфичным для WordPress, но оказывается очень полезным для отладки сайтов.

Инструменты разработчика Firefox неизбежно сравниваются с более популярными Chrome DevTools. При этом солидная компоновка Firefox выделяется. Например, вы можете щелкнуть правой кнопкой мыши любой элемент, чтобы открыть вкладку «Инспектор», и веб-консоль предлагает расширенный вывод при печати объектов, показывая гораздо больше информации, чем просто его имя.

Он предоставляет дополнительную информацию для определенных типов, позволяя детально изучить свойства объекта и предоставить более подробную информацию для элементов DOM.

Инструменты разработчика Firefox

С помощью инструмента «Инспектор» вы можете просматривать и изменять страницы HTML и CSS, что позволяет делать это со страницами, загруженными локально в Firefox или на удаленном устройстве, например Firefox для Android.

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

6. New Relic

Являясь одним из крупнейших игроков в отрасли APM (Application Performance Monitoring), New Relic является коммерческим продуктом, который ежедневно используют тысячи разработчиков во всем мире, чтобы получить представление о производительности своих программных продуктов. Он имеет плагиновую архитектуру, которая обеспечивает добавленную функциональность третьими сторонами, что приводит к практически бесконечному спектру технологий, которые можно отслеживать с помощью этого инструмента.

New Relic

При цене от 9,37$ до 200$ за хост в месяц он предназначен для профессиональной отладки. Он также несет в себе расширенную кривую обучения, поэтому помимо затрат денег на решение, вам также нужно потратить время, чтобы научиться его использовать. Пользователи New Relic ценят тот факт, что он легко интегрируется в приложения для APM и мониторинга инфраструктуры.

7. Debug Bar

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

Основной плагин, Debug Bar, предоставляет базовую функциональность, расширенную остальными плагинами. Он работает со встроенными в WordPress флагами отладки, такими как WP_DEBUG и SAVEQUERIES. Когда эти флаги активны, панель отладки добавляет полезную информацию об отладке, такую ​​как предупреждения PHP и запросы MySQL, избавляя вас от необходимости искать и читать файлы журнала.

Debug Bar

Каждый параметр в меню панели отладки предоставляет свою долю мощности отладки. В консоли, например вы можете запускать произвольный PHP-код, который отлично подходит для тестирования содержимого переменных (среди прочего).

Cron отображает информацию о запланированных событиях WordPress, такую ​​как время следующего события, количество запланированных событий, список пользовательских запланированных событий и т. Д. Действия и фильтры — еще одна опция для отображения хуков, прикрепленных к текущему запросу. На вкладке «Действия» отображаются действия, связанные с текущим запросом, а на вкладке «Фильтры» отображаются все теги фильтров, а также функции, прикрепленные к каждому из них.

Заключение

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

Также рекомендуем прочитать:

  1. 10 способов SEO оптимизации WordPress и производительности контента
  2. 7 способов, как увеличить скорость загрузки вашего сайта
  3. Что такое черный список URL-адресов и как от него защититься?
  4. Увеличить производительность WordPress с помощью этих плагинов
Источник

Возможно, вам также будет интересно:

  • Word при сохранении пишет ошибка файла
  • Wordpress на сайте возникла критическая ошибка при редактировании
  • Word при сохранении normal ошибка
  • Wordpress выдает ошибку 500
  • Word при выполнении экспорта произошла неожиданная ошибка word

    • Понравилась статья? Поделить с друзьями:
    0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии