Безпечне логування помилок WordPress у production

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

Налаштування `WP_DEBUG_DISPLAY` відповідає за показ повідомлень PHP і WordPress у відповіді сторінки. Якщо воно ввімкнене, на сайті можуть з’явитися попередження, шляхи до файлів теми або плагінів, назви функцій, фрагменти SQL та інші внутрішні дані.

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

На production не слід використовувати debug-режим як постійний спосіб моніторингу. Його вмикають на обмежений час, відтворюють проблему, аналізують записи та повертають безпечну конфігурацію.

• Не використовуйте `WP_DEBUG_DISPLAY` зі значенням `true` на публічному сайті.
• Не надсилайте користувачам повні stack trace та тексти SQL-помилок.
• Не залишайте детальне логування активним без контролю розміру й доступу до файлу.

Як увімкнути логування без виводу помилок

Відкрийте `wp-config.php` і додайте налаштування перед рядком `That's all, stop editing! Happy publishing.` або його локалізованим аналогом. Важливо не створювати дублікати констант: якщо вони вже є у файлі, змініть наявні значення замість додавання нових рядків нижче.

Базова конфігурація для тимчасової діагностики виглядає так:

• `WP_DEBUG` вмикає режим діагностики WordPress.
• `WP_DEBUG_LOG` записує повідомлення у файл логу.
• `WP_DEBUG_DISPLAY` забороняє показ діагностичних повідомлень у браузері.
• `display_errors` додатково вимикається на рівні PHP для поточного запиту.

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

Куди записується лог

За стандартної конфігурації WordPress записує діагностичні повідомлення у `wp-content/debug.log`. У деяких конфігураціях `WP_DEBUG_LOG` можна замінити на шлях до іншого файлу, наприклад до окремого каталогу для службових логів. Такий шлях потрібно узгодити з правами файлової системи та налаштуваннями хостингу.

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

Як перевірити проблему та прочитати debug.log

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

Для перегляду останніх рядків на сервері Linux можна використати:

• Шукайте час події, назву файлу, номер рядка та компонент, який спричинив повідомлення.
• Порівнюйте записи до і після конкретної дії, щоб відокремити актуальну помилку від старих повідомлень.
• Перевіряйте не лише `Fatal error`, а й `Warning`, `Notice`, `Deprecated` та повідомлення про помилки бази даних.
• Якщо файл не оновлюється, перевірте фактичний шлях, права на запис і журнали PHP-FPM, вебсервера або хостингу.

tail -f wp-content/debug.log

Що саме аналізувати в записі

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

Не редагуйте код без резервної копії та не виправляйте production навмання за одним рядком логу. За можливості спочатку відтворіть проблему на staging-середовищі.

Як захистити файл із помилками

Файл `wp-content/debug.log` часто розташований у каталозі, доступному з вебсервера. Якщо сервер віддає його за прямим URL, будь-хто може завантажити технічні записи. У логах інколи опиняються email-адреси, ідентифікатори користувачів, SQL-фрагменти, токени або дані запитів.

Найкращий варіант — зберігати production-лог поза публічним web root, якщо це підтримує ваша конфігурація. Якщо файл має залишатися в `wp-content`, обмежте доступ на рівні вебсервера та перевірте захист окремим запитом у приватному вікні браузера.

• Для Apache використовуйте правило заборони доступу до конкретного файлу або каталогу, узгоджене з конфігурацією сервера.
• Для Nginx додайте окреме правило `location`, яке повертає заборону доступу до `debug.log`.
• Не покладайтеся лише на приховування URL або нестандартну назву файлу.
• Права файлової системи мають дозволяти запис користувачу вебсервера, але не робити файл доступним для всіх користувачів системи.
• Після налаштування перевірте доступ і через HTTP, і безпосередньо через SSH.

Ротація, розмір і приватність логів

Помилки можуть повторюватися на кожному запиті, тому `debug.log` здатен швидко збільшуватися. Великий файл займає дисковий простір і ускладнює пошук потрібної події. Для production-сервера варто налаштувати ротацію на рівні операційної системи або панелі хостингу.

Під час аналізу ставтеся до логу як до конфіденційних технічних даних. Не публікуйте його повністю в чатах або тикетах. Перед передаванням розробнику приберіть паролі, токени, cookie, email-адреси, IP-адреси та інші персональні дані.

Якщо в коді плагіна або теми вручну записуються дані через `error_log()`, перевірте, щоб туди не потрапляли паролі, ключі API, повні тіла запитів чи платіжна інформація. WordPress-логування не робить такі дані безпечними автоматично.

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

Як вимкнути debug-режим після діагностики

Коли причина помилки знайдена й перевірена, поверніть production-конфігурацію. Зазвичай це означає вимкнення всіх чотирьох налаштувань або видалення тимчасових рядків із `wp-config.php`.

• Переконайтеся, що `WP_DEBUG` має значення `false`.
• Вимкніть `WP_DEBUG_LOG`, якщо постійне логування не потрібне для вашої системи моніторингу.
• Залиште `WP_DEBUG_DISPLAY` вимкненим на production.
• Перевірте сайт у браузері та перегляньте журнали PHP або вебсервера після зміни.
• Захищено видаліть або заархівуйте старий `debug.log`, якщо він більше не потрібен.

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

Якщо помилка потрібна для довготривалого моніторингу

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

Якщо production-середовище підтримує змінні оточення або окрему конфігурацію для staging, зберігайте діагностичні налаштування поза репозиторієм і не переносіть їх випадково на робочий сайт.