Як увімкнути режим відлагодження (дебагу) WordPress

Привіт:) Відлагодження коду використовують, щоб знайти та виправити помилки в роботі сайту, для його оптимізації та прискорення, при додаванні чи доопрацюванні функціоналу. У цій замітці покажу, як увімкнути режим відлагодження WordPress.

Що таке відлагоджувач (debug) і для чого потрібний

Це набір інструментів, які дозволяють переглянути зсередини роботу сайту. Відлагодження можна порівняти з рентгеном або аналізом крові, які допомагають дізнатися причину хвороби.

Debug-режим найчастіше використовують, щоб з'ясувати, чому не працює (або працює не так, як потрібно) той чи інший функціонал. Наприклад, що робити, якщо після оновлення теми чи плагіну не вдається увійти до адмін-панелі?

Під час роботи сайту часто трапляються помилки. Це може статися через збій на хостингу, додавання нових або зміни старих функцій, оновлення WP, плагінів. Тому важливо завжди бути в курсі цих помилок, щоб вчасно їх виправити і забезпечити безперебійну роботу веб-ресурсу.

Ще відлагодження необхідне під час розробки плагінів і тем ВордПрес. Воно "примушує" програмістів дотримуватися рекомендованих стандартів, щоб у результаті програмний код був максимально якісним.

до змісту ↑

Як увімкнути режим відлагодження WordPress

У ядрі WordPress вже вбудований відлагоджувач, але за замовчуванням він вимкнений. Розберу, як із ним працювати.

Зазвичай повідомлення про помилки не повинні виводитися на екрані в користувацькій частині сайту. Це відволікає відвідувачів та ставить під загрозу злому. Зручно список та опис помилок (якщо вони є) отримувати в окремому файлі, доступ до якого має лише адміністратор.
Перед подальшими діями рекомендую створити повну резервну копію сайту.
  1. Перейдіть до кореневого каталогу свого сайту та відкрийте файл wp-config.php.
  1. У рядку
define( 'WP_DEBUG', false );

значення false замініть на true.

Повідомлення про всі помилки з'являтимуться на веб-сайті. Щоб їх приховати від користувачів і зручно помістити в один файл, додайте нижче рядки

define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
  1. Щоб усі повідомлення про помилки (логи) збиралися в одному файлі, додайте код
define( 'WP_DEBUG_LOG', true );
  1. Якщо необхідно логувати всі SQL запити, то наступна директива зберігатиме їх у змінну $wpdb->queries як масиву. У цьому масиві можна буде подивитися всі SQL запити сторінки, а також дані про те, скільки часу зайняв запит і якою функцією він був викликаний.
define( 'SAVEQUERIES', true );
SQL-запити зможете повитися за допомогою коду:

global $wpdb;
print_r($wpdb->queries);
  1. Збережіть зміни.

Тепер їх усі можна переглянути у /wp-content/debug.log.

Шлях /wp-content/debug.log для розміщення лог-файлу заданий за замовчуванням. Якщо він не влаштовує, то рядок

define( 'WP_DEBUG_LOG', true );

замініть на

define( 'WP_DEBUG_LOG', '/home/public_html/wp-content/wp-errors.log' );

В останньому параметрі задайте власний шлях до файлу помилок.

Повний код:

// Увімкнути режим відлагодження
define( 'WP_DEBUG', true );
// Заборонити виведення помилок на екран
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
// Увімкнути логування помилок у файлі /wp-content/debug.log
define( 'WP_DEBUG_LOG', true );
// Логувати SQL запити
define( 'SAVEQUERIES', true );

У готовому варіанті це виглядає приблизно так:

Більш детально із відлагодженням WordPress можете ознайомитися в оф. документації.
до змісту ↑

Якщо не працює WP_DEBUG

Іноді директива WP_DEBUG у wp-config.php може не працювати, і помилки не відображатимуться. Причиною може бути перевизначення десь у коді плагінів чи тем параметрів їх показу. Наприклад, помилки можуть бути вимкнені ini-директивами PHP:

error_reporting(0); // вимкнення повідомлень про помилки
ini_set('display_errors', 0); // вимкнення виведення помилок на екран

У цьому випадку режим відлагодження (дебагу) WordPress "перебиваються", і він перестає працювати.

Для вирішення проблеми найкраще знайти де змінюються налаштування та видалити такі рядки, щоб далі працювати лише з константою WP_DEBUG.

Якщо неможливо знайти місце перевизначення, можна спробувати ще раз "перебити" параметри виведення помилок, вказавши їх знову:

error_reporting(E_ALL); // увімкнення повідомлень про помилки
ini_set('display_errors', 1); // увімкнення виведння помилок на екран
до змісту ↑

Плагіни для відлагодження в CMS ВордПрес

Щоб спростити завдання виявлення проблем і помилок у WordPress, можна скористатися окремими готовими рішеннями.

Debug Bar та режим розробника

Це безкоштовний WP-модуль, який додає до верхньої панелі адміністратора (адмін-бар) зручне меню. Його функції дозволяють оцінити продуктивність, побачити SQL-запити до бази даних, скільки пам'яті витрачають скрипти, стан об'єктного кешу WordPress. Цим інструментом часто користуються, щоб з'ясувати ресурсомісткі запити до бази даних, які "гальмують" роботу сайту.

Для нормальної роботи плагіну в файлі wp-config.php мають бути такі рядки:

define( 'WP_DEBUG', true );
// SQL-запити
define( 'SAVEQUERIES', true );

Після встановлення та активації в адмін-барі з'являється пункт меню Debug з декількома розділами.

  • Queries. Детальна інформація про всі виконані запити до бази даних MySQL (час роботи кожного запиту та функція, яка його виконала). Також містить запити користувача, виконані через об'єкт $wpdb.
  • WP Query. Усі дані основного запиту WP_Query (його аргументи, і навіть файл-шаблон теми, що використовується для виведення результату).
  • Request. Розділ потрібен, якщо ви працюєте зі своїми правилами WP_Rewrite. Тут виводяться правила, за якими ВордПрес відніс адресу поточної відкритої сторінки до списку аргументів до об'єкта WP_Query.
  • Object Cache. WordPress має вбудоване кешування об'єктів, щоб прискорити роботу сайту. Ця вкладка містить інформацію про стан об'єктного кешу, включаючи розміри всіх груп. Корисно використовувати, якщо працюєте з плагінами для зовнішнього кешування об'єктів (наприклад, Memcached).
Рекомендую використовувати файл debug.log для виведення помилок. Це найзручніший спосіб логування.
Після того, як ревізія коду та роботи з розробки ВордПрес завершені, плагін краще вимкнути.

Михайло Петров
Михайло Петров

Мене звати Михайло. Я — WordPress-розробник. Створюю візитки, корпоративні сайти, блоги на WordPress.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *