Ви завжди пишете код з першого разу без помилок? Я – ні. Але визнання помилок – перший крок до їх виправлення. А для того, щоб виправити помилку, її спочатку потрібно знайти. Ця стаття допоможе простим смертним відстежити їх помилки за допомогою налагоджувального журналу WordPress (debug log):

Я вже згадував про налаштування налагодження WordPress у своїй недавній статті «Файл конфігурації WordPress: wp-config.php». Я розповів про те, як показати помилки в середовищі розробки і приховати їх на публічному сервері.

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

Саме з цієї причини непогано було б залишити WP_DEBUG включеним, але не показувати помилки на сторінках сайту, а записувати їх для подальшого аналізу в особливий файл – журнал налагодження. У цій статті я опишу різні способи налаштування і читання журналу. А ще я розповім, як записувати інформацію в журнал програмним способом.

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

Налаштування

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

Щоб дозволити генерацію налагоджувальної інформації і записувати її в журнал, але не виводити на сторінках сайту, вам слід змінити файл wp-config.php наступним чином:

define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_DISPLAY’, ‘false’);
define( ‘WP_DEBUG_LOG’, true );

Зауважимо, що фатальні помилки (так званий «білий екран смерті») приховати неможливо.

Перегляд журналу налагодження

Файл з налагоджувальною інформацією називається debug.log і розташовується в тому ж каталозі, що і контент вашого сайту. Можна читати його і видаляти з нього застарілу інформацію за допомогою будь-якого текстового редактора, проте це не дуже зручний спосіб, особливо якщо журнал розташований на віддаленому сервері, що знаходиться під навантаженням.

Існують плагіни, помітно спрощують роботу з журналом налагодження. Проте в ряді випадків (наприклад, при недоступності сайту) необхідно працювати з файлом журналу безпосередньо.

Існує цілий ряд інструментів, що дозволяють працювати з журналом налагодження через інтерфейс адміністратора сайту. Мій улюблений інструмент – Log Viewer. Цей безкоштовний плагін дозволяє читати і очищати журнал через панель управління сайтом, пункт меню «Tools» («Інструменти»).

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

Зрозуміло, панель налагодження не варто використовувати на робочому сервері, але в процесі розробки вона дуже корисна. Обидва плагіна (Log Viewer і Debug Bar) можуть бути встановлені через інсталятор плагінів як самі по собі, так і в складі комплексного плагіна Developer.

Ось як може виглядати ваш журнал:

Використання журналу налагодження WordPress

Як бачите, кожна подія, згенероване WordPress, зазначається в журналі міткою часу UTC.

Запис довільної інформації в журнал налагодження

В деяких випадках буває корисним виводити в журнал додаткову інформацію, яка не повідомляє про помилку, а лише допомагає в написанні власного коду. Для таких випадків в PHP є функція error_log(), яка виводить повідомлення в журнал.

Ця функція не має опцій форматування, тому я рекомендую створити власну обгортку над error_log, яка б форматировала записуються в журнал змінні та об’єкти за допомогою функції print_r(). Ось так може виглядати ця функція-обгортка:

if ( ! function_exists(‘write_log’)) {
function write_log ( $log ) {
if ( is_array( $log ) || is_object( $log ) ) {
error_log( print_r( $log, true ) );
} else {
error_log( $log );
}
}
}

Поміщати цей код у файл functions.php вашої теми не має сенсу, так як при налагодженні сайту ви, швидше за все, переведіть тему на стандартну і втратите доступ до нього. Оформіть цей код у вигляді плагіна. Для цього створіть файл у вашому каталозі плагінів, додайте в нього заголовок плагіна і вище наведений код. Заголовок плагіна може виглядати так:

/*
Plugin Name: Error Log
*/

У створеній нами функції є безліч варіантів застосування. Хочете дізнатися, чи викликається дана рядок? Напишіть:

write_log( __LINE__ );

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

add_action( ‘wp_head’, ‘slug_log_post_view’ );
function slug_log_post_view() {
//set the ID of the post you want to track here:
$post_to_track = 42;
//get the current post’s ID & make sure it’s a valid ID and it matches our ID
$id = get_queried_object_id();
if ( intval( $id ) > 0 && $post_to_track === $id ) {
//check if current user is logged in and if so get the user ID
if ( is_user_logged_in() ) {
$user_id = get_current_user_id();
$user_id = ‘a user with the ID’ . $user_id;
}
else{
$user_id = ‘a user that was not logged in.’;
}
//log the information
write_log( «The post {$post_to_track} was accessed by {$user_id}» );
}
}

Звичайно, написаний нами код не є серйозним аналітичним інструментом, але він цілком може допомогти простежити за окремим постом, позначених змінної $post_to_track. Щоб стежити за всіма постами, ви можете видалити з коду, наведеного вище, перевірку ідентифікатора поста $id на рівність $post_to_track.

Налагодження – це здорово!

Сподіваюся, моя невелика стаття допоможе вам оволодіти такою необхідною, але часто упускати з виду можливістю WordPress. Але не забувайте, що помилками в PHP-коді налагодження не обмежується. Проблеми з JavaScript допоможе виявити JavaScript-консоль вашого браузера, але це – тема для іншої статті.

Переклад статті «Using The WordPress Debug Log» був підготовлений дружною командою проекту Сайтостроение від А до Я.