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

Журнали помилок WordPress — це діагностичні записи, які фіксують помилки PHP, фатальні винятки, збої бази даних, конфлікти плагінів та несумісності тем у міру їх виникнення на вашому сервері. Доступ до цих журналів та їх інтерпретація — найшвидший спосіб визначити першопричину зламаної сторінки, білого екрану смерті або прихованої регресії продуктивності — без здогадок і почергового вимкнення плагінів.

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

Чому журнали помилок WordPress важливі

WordPress працює на PHP, який генерує кілька класів повідомлень під час виконання: фатальні помилки (виконання зупиняється), попередження (виконання продовжується, але щось не так), повідомлення (інформаційні, часто вказують на застарілий код) та повідомлення про застарілість (функції, заплановані до видалення). За замовчуванням жодне з них не записується до постійного журналу в більшості виробничих конфігурацій — вони або пригнічуються, або виводяться у браузер, що є загрозою безпеці.

Без журналу оновлення плагіна, яке спричиняє фатальну помилку, призводить лише до порожнього екрана. Неправильно налаштована бібліотека SMTP мовчки не надсилає листи. Перевищення ліміту пам’яті вбиває завантаження сторінки без жодного видимого сліду. Журнали помилок перетворюють ці невидимі збої на записи з мітками часу, посиланнями на файли та номерами рядків, на які можна негайно реагувати.

Метод 1: Увімкнення режиму налагодження WordPress через wp-config.php

WordPress постачається з вбудованою підсистемою налагодження, керованою набором PHP-констант, визначених у wp-config.php. Це найточніший метод, оскільки він фіксує специфічні для WordPress помилки, включно з тими, що генеруються API плагінів, завантажувачем тем та рівнем абстракції бази даних (wpdb).

Крок 1: Знайдіть і відкрийте wp-config.php

Підключіться до сервера через SFTP (рекомендовано замість звичайного FTP з міркувань безпеки) за допомогою клієнта на кшталт FileZilla або Cyberduck, або відкрийте файловий менеджер вашого хостинг-провайдера. Перейдіть до кореневого каталогу WordPress, зазвичай /public_html/ або /var/www/html/. Файл wp-config.php знаходиться в корені цього каталогу.

Якщо у вас є доступ SSH, ви можете редагувати його безпосередньо:

nano /var/www/html/wp-config.php

Крок 2: Налаштуйте константи налагодження

Знайдіть існуючий рядок:

define( 'WP_DEBUG', false );

Замініть весь блок наступною конфігурацією, яка вмикає журналювання без відображення помилок відвідувачам сайту:

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

Що робить кожна константа:

• WP_DEBUG — активує рушій налагодження WordPress та вмикає звітування про помилки PHP на рівні E_ALL.
• WP_DEBUG_LOG — записує всі зафіксовані помилки до файлу журналу замість (або на додаток до) екрана.
• WP_DEBUG_DISPLAY — якщо встановлено false, пригнічує виведення на екран. Це критично важливо на виробничих сайтах; без цього PHP-повідомлення витікають внутрішні шляхи до файлів та імена змінних до відвідувачів.
• display_errors — базова директива PHP; встановлення її в 0 через ini_set забезпечує другий рівень пригнічення на випадок, якщо плагін або тема перевизначить WP_DEBUG_DISPLAY.

Крок 3: Знайдіть файл журналу налагодження

Якщо WP_DEBUG_LOG встановлено в true, WordPress записує помилки до:

/wp-content/debug.log

Цей файл створюється автоматично при першій зареєстрованій помилці. Ви можете переглянути його через SFTP або SSH:

tail -f /var/www/html/wp-content/debug.log

Прапорець tail -f транслює нові записи в реальному часі, що є безцінним при інтерактивному відтворенні конкретної помилки.

Крок 4: Використовуйте власний шлях до журналу (рекомендовано з міркувань безпеки)

Шлях за замовчуванням debug.log є публічно доступним, якщо ваш веб-сервер явно не блокує його. Неправильно налаштований сервер надасть https://yourdomain.com/wp-content/debug.log будь-якому відвідувачу, розкриваючи внутрішні шляхи, префікси таблиць бази даних та імена класів.

Варіант A — Перемістіть файл журналу за межі кореневого каталогу веб-сервера:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Створіть цільовий каталог і встановіть дозволи:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Варіант B — Заблокуйте шлях за замовчуванням через .htaccess (Apache):

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Варіант C — Еквівалент для Nginx у вашому блоці сервера:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Крок 5: Вимкніть режим налагодження після усунення несправностей

Ніколи не залишайте WP_DEBUG встановленим у true на живому сайті довше, ніж необхідно. Після вирішення проблеми:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Залишення режиму налагодження активним на виробничому сайті знижує продуктивність (PHP обробляє кожне E_ALL повідомлення) і може розкрити чутливі трасування стека, якщо WP_DEBUG_DISPLAY випадково встановлено в true.

Метод 2: Доступ до журналів помилок на рівні сервера через панель керування хостингом

Помилки WordPress, що виникають до завершення завантаження WordPress — наприклад, пошкоджений wp-config.php, несумісність версій PHP або невдале підключення до бази даних — ніколи не з’являться в debug.log, оскільки сам WordPress так і не завантажується. Для таких випадків вам потрібен журнал помилок PHP сервера або журнал помилок Apache/Nginx.

Хостинг на основі cPanel

Якщо ваше хостингове середовище використовує VPS з cPanel, журнал помилок доступний через інтерфейс панелі керування:

1. Увійдіть до cPanel.
2. Перейдіть до Метрики > Помилки.
3. Панель відображає останні 300 рядків журналу помилок Apache для вашого облікового запису.

Для повного файлу журналу використовуйте Файловий менеджер cPanel або підключіться через SFTP і перейдіть до:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

Точні імена файлів варіюються залежно від конфігурації сервера, але шаблон є однаковим для більшості інсталяцій cPanel.

Хостинг на основі Plesk

У Plesk перейдіть до Веб-сайти та домени > виберіть свій домен > Журнали. Ви можете фільтрувати за типом журналу (доступ, помилки, PHP) та завантажити повний файл журналу.

Прямий доступ до сервера (VPS або виділений сервер)

У середовищі VPS Хостингу або Виділеного сервера, де у вас є root-доступ, розташування журналів залежить від вашого стека:

Для моніторингу журналу PHP-FPM у реальному часі:

tail -f /var/log/php8.2-fpm.log

Для пошуку специфічних для WordPress фатальних помилок у журналі Apache:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Налаштування журналювання помилок PHP на рівні сервера

Якщо помилки PHP не записуються до журналу, перевірте конфігурацію php.ini:

php --ini | grep "Loaded Configuration"

Відкрийте визначений файл php.ini та перевірте або встановіть:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Перезапустіть PHP-FPM після змін:

systemctl restart php8.2-fpm

Крім того, перевизначте налаштування PHP для кожного сайту за допомогою файлу .htaccess (лише Apache):

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Метод 3: Використання плагіна для журналювання помилок WordPress

Для середовищ з обмеженим прямим доступом до сервера — наприклад, Спільний веб-хостинг — або для команд, де нетехнічним адміністраторам потрібно переглядати помилки без доступу SSH, плагін WordPress є прийнятною альтернативою.

Рекомендовані плагіни

• WP Log Viewer — читає існуючий файл debug.log та відображає його в адміністративній панелі WordPress з фільтрацією та пошуком.
• Error Log Monitor — додає віджет на панель приладів із відображенням останніх помилок і може надсилати сповіщення електронною поштою при появі нових помилок.
• Query Monitor — виходить за межі журналювання помилок і профілює запити до бази даних, виклики HTTP API, хуки та умовні теги. Незамінний для налагодження продуктивності.
• Health Check & Troubleshooting — офіційний плагін WordPress.org; вмикає режим усунення несправностей, який активує тему за замовчуванням і вимикає всі плагіни лише для вашого сеансу, не впливаючи на інших відвідувачів.

Встановлення та налаштування Error Log Monitor

1. В адміністративній панелі WordPress перейдіть до Плагіни > Додати новий.
2. Знайдіть Error Log Monitor і натисніть Встановити зараз, потім Активувати.
3. Перейдіть до Налаштування > Error Log Monitor.
4. Вкажіть шлях до файлу журналу. Якщо ви перемістили debug.log за межі кореневого каталогу веб-сервера, введіть тут абсолютний шлях до сервера.
5. Налаштуйте частоту сповіщень електронною поштою, якщо хочете отримувати повідомлення про нові типи помилок.

Плагін читає той самий файл debug.log, до якого записує WP_DEBUG_LOG. Він не створює окремого механізму журналювання — він є переглядачем. Це означає, що WP_DEBUG та WP_DEBUG_LOG все одно мають бути увімкнені в wp-config.php, щоб плагін щось відображав.

Критичне обмеження: Плагіни завантажуються після завантаження WordPress. Будь-яка помилка, що перешкоджає завантаженню WordPress (збій підключення до бази даних, пошкоджений основний файл, несумісна версія PHP), не буде видима в жодному переглядачі журналів на основі плагінів. Для таких сценаріїв єдиним варіантом є Метод 2.

Порівняння: три методи журналювання помилок WordPress

Читання та інтерпретація записів журналу помилок WordPress

Необроблений запис debug.log виглядає так:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

Як це читати:

• Мітка часу вказана в UTC — за потреби конвертуйте до місцевого часового поясу вашого сервера.
• PHP Fatal error означає, що виконання зупинилося. Сторінка, яка спричинила це, повернула помилку 500 або порожній екран.
• Call to undefined function get_field() означає, що плагін Advanced Custom Fields або деактивовано, або завантажено після того, як functions.php теми спробував його викликати.
• Трасування стека показує точний файл і номер рядка. Починайте налагодження з рядка 47 файлу functions.php.

Поширені шаблони помилок та їх причини:

• PHP Warning: require(): Failed opening required — шлях до файлу неправильний або файл відсутній. Часто спричиняється плагіном, який посилається на видалений файл.
• PHP Deprecated: Function _register_controls is deprecated — плагін або тема використовує застарілий API. Не фатально, але вказує на плагін, який не оновлювався для поточної версії WordPress/Elementor.
• WordPress database error ... for query — запит wpdb завершився невдачею. Перевірте невідповідності префіксів таблиць або пошкоджені таблиці.
• Maximum execution time of 30 seconds exceeded — скрипт виконувався надто довго. Поширено при великих імпортах, неоптимізованих запитах або зовнішніх викликах API, що перевищують час очікування.
• Allowed memory size of X bytes exhausted — PHP досяг ліміту пам’яті. Збільшіть memory_limit у php.ini або визначте плагін, що спричиняє витік пам’яті.

Найкращі практики управління журналами помилок WordPress

Ротуйте журнали для запобігання вичерпанню дискового простору. Завантажений сайт WordPress під атакою або з повторюваною помилкою може генерувати сотні мегабайт даних журналу на день. На серверах Linux налаштуйте logrotate:

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Ніколи не додавайте debug.log до системи контролю версій. Додайте його до .gitignore:

wp-content/debug.log

Перевіряйте wp-config.php після кожної міграції сервера. Міграції хостингу часто скидають WP_DEBUG до false або вводять новий шаблон wp-config.php, який перезаписує ваші константи.

Використовуйте SAVEQUERIES для налагодження на рівні бази даних. Додайте цю константу поряд з WP_DEBUG для журналювання кожного SQL-запиту, який виконує WordPress:

define( 'SAVEQUERIES', true );

Потім перевірте $wpdb->queries у власному шаблоні або через Query Monitor. Вимкніть його одразу після використання — він зберігає кожен запит у пам’яті та значно збільшує споживання RAM.

Зіставляйте мітки часу журналів з подіями розгортання. Якщо з’являється новий тип помилки, перевірте, чи збігається він з оновленням плагіна, оновленням ядра WordPress або зміною версії PHP на сервері. Більшість панелей керування хостингом реєструють зміни версій PHP в окремому журналі аудиту.

Матриця рішень: який метод використовувати

Технічний контрольний список ключових висновків

• Встановіть WP_DEBUG_DISPLAY в false перед увімкненням WP_DEBUG_LOG на будь-якому сайті з живим трафіком.
• Перемістіть debug.log за межі кореневого каталогу веб-сервера або заблокуйте його через правила сервера — шлях за замовчуванням є публічно доступним.
• Використовуйте tail -f для файлу журналу при інтерактивному відтворенні помилок; це усуває необхідність вручну оновлювати файл.
• Журнали PHP та Apache/Nginx на рівні сервера є єдиним джерелом правди для помилок, що виникають до завантаження WordPress.
• Переглядачі журналів на основі плагінів потребують активного WP_DEBUG_LOG — вони є читачами, а не записувачами.
• Впровадьте ротацію журналів на будь-якому сервері, де WP_DEBUG_LOG увімкнено більше ніж на кілька годин.
• Ніколи не залишайте SAVEQUERIES увімкненим у виробничому середовищі; це навантаження на пам’ять і продуктивність.
• Після вирішення проблеми встановіть усі константи налагодження назад у false та перевірте за допомогою запиту браузера, що в джерелі сторінки не з’являються PHP-повідомлення.

—

Часті запитання

Де за замовчуванням знаходиться файл журналу налагодження WordPress?

WordPress записує журнал налагодження до /wp-content/debug.log відносно кореневого каталогу WordPress. Цей шлях створюється лише після першої зареєстрованої помилки і лише коли і WP_DEBUG, і WP_DEBUG_LOG встановлені в true у wp-config.php. Ви можете перевизначити шлях, передавши рядок з абсолютним шляхом до файлу як значення WP_DEBUG_LOG замість true.

Чи безпечно вмикати WP_DEBUG на живому виробничому сайті?

Це безпечно лише якщо WP_DEBUG_DISPLAY явно встановлено в false та display_errors встановлено в 0. Без цих двох налаштувань помилки PHP — включно з внутрішніми шляхами до файлів та іменами таблиць бази даних — відображаються безпосередньо в HTML-джерелі кожної сторінки. Завжди поєднуйте WP_DEBUG true з WP_DEBUG_DISPLAY false на будь-якому сайті з публічним трафіком.

Чому мій файл debug.log порожній, хоча WP_DEBUG увімкнено?

Найпоширеніші причини: процес веб-сервера не має дозволу на запис до каталогу /wp-content/; WP_DEBUG_LOG встановлено в false або відсутній у wp-config.php; або помилка виникає на рівні сервера до завантаження WordPress, тобто вона з’явиться в журналі Apache або PHP-FPM, а не в debug.log. Перевірте дозволи каталогу за допомогою ls -la wp-content/ та переконайтеся, що константи визначені в правильному порядку у wp-config.php.

У чому різниця між WP_DEBUG_LOG та журналом помилок PHP сервера?

WP_DEBUG_LOG — це константа рівня WordPress, яка направляє помилки, зафіксовані власним обробником помилок WordPress, до debug.log. Журнал помилок PHP сервера (налаштований через error_log у php.ini) фіксує всі помилки PHP на рівні інтерпретатора, включно з тими, що виникають до ініціалізації WordPress. На правильно налаштованому сервері обидва журнали активні одночасно та доповнюють один одного.

Чи можна увімкнути журналювання помилок на спільному хостингу без доступу SSH?

Так. Ви можете редагувати wp-config.php через файловий менеджер вашого хостинг-провайдера в cPanel або Plesk, увімкнути WP_DEBUG та WP_DEBUG_LOG, а потім читати debug.log через той самий інтерфейс файлового менеджера. Для журналів на рівні сервера на Спільному веб-хостингу використовуйте розділ Помилки в розділі Метрики в cPanel. Якщо вам потрібен більш детальний контроль над конфігурацією PHP та шляхами до журналів, перехід на план VPS Хостингу надає прямий доступ до php.ini та повний доступ SSH до всіх файлів журналів.