Де лежить debug.log у WordPress і як перенести його в безпечне місце

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

Три константи і що робить кожна

Усі три йдуть у wp-config.php, вище рядка /* That's all, stop editing! Happy blogging. */. Усе, додане нижче цього рядка, виконується вже після завантаження WordPress і не має жодного ефекту.

Константа	Значення за замовчуванням	Що робить
WP_DEBUG	false	Головний вимикач. Підвищує рівень звітування PHP, щоб показувати повідомлення, попередження та застарілі виклики. Без неї не працює ніщо інше з цього списку.
WP_DEBUG_LOG	false	Надсилає помилки у файл. true означає wp-content/debug.log. Рядок трактується як шлях до файлу, у який писати.
WP_DEBUG_DISPLAY	true	Виводить помилки в HTML сторінки, де їх бачить кожен відвідувач.

Саме із залежністю між ними найчастіше й помиляються. WP_DEBUG_LOG зчитується всередині гілки WP_DEBUG у стартовому коді WordPress. Якщо WP_DEBUG дорівнює false, встановлення WP_DEBUG_LOG у true не дає взагалі нічого — ні файлу, ні помилки, ні попередження. Якщо ви додали WP_DEBUG_LOG, а журнал не з’явився, спершу перевірте WP_DEBUG.

Робоча конфігурація для живого сайту:

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

Якщо WP_DEBUG уже визначено вище у файлі — а зазвичай так і є, зі значенням false, — відредагуйте той наявний рядок, а не додавайте другий define(). Повторне визначення тієї самої константи спричиняє попередження PHP, яке на сайті з увімкненим виводом опиняється просто вгорі сторінки.

Чому WP_DEBUG_DISPLAY має бути false на робочому сайті

З увімкненим виводом помилки PHP друкуються прямо у HTML-відповідь. Одного повідомлення про застарілий виклик із шаблону досить, щоб показати кожному відвідувачу абсолютний шлях на вашому сервері. Помилка бази даних покаже назви таблиць і фрагменти запитів. Гірше того, вивід, який з’являється до надсилання заголовків, ламає перенаправлення, ламає відповіді REST і AJAX, що очікують чистий JSON, і може дати той самий білий екран, у якому потім звинувачують плагін.

Одна тонкість, яку варто знати: встановити WP_DEBUG_DISPLAY у null — це не те саме, що false. null каже WordPress не чіпати налаштування display_errors у PHP і успадкувати те, що налаштовано на сервері. false активно вимикає вивід. На робочому сайті використовуйте false і додайте наведений вище рядок з ini_set як подвійну страховку, бо плагін може повернути display_errors пізніше під час запиту.

Стандартне розташування доступне ззовні

wp-content/debug.log лежить усередині кореня сайту. Ніщо у стандартній установці WordPress не блокує прямі запити до нього. На типовій конфігурації Apache чи nginx адреса https://yoursite.com/wp-content/debug.log повертає файл звичайним текстом. Журнали налагодження містять абсолютні шляхи на сервері, внутрішні деталі плагінів і шаблонів, помилки бази даних із реальним текстом запитів, а іноді й значення, передані у функції, що збоять. Це безкоштовна розвідка для кожного, хто вгадає URL, — і одна з перших адрес, які пробують автоматичні сканери.

Із цим можна впоратися двома способами. Кращий — перенести журнал.

Перенесення журналу через шлях

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

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Для цього шляху діють три правила. Використовуйте абсолютний шлях — відносний розв’язується відносно робочої теки PHP, яка змінюється від запиту до запиту й від сервера до сервера, тож ви просто загубите файл. Тека вже має існувати: PHP її не створить, а якщо не зможе відкрити файл — мовчки нічого не зробить. І тека має бути доступною для запису користувачеві PHP, який на спільному хостингу не збігається з обліковим записом, під яким ви заходите через SFTP.

Якщо хостинг замикає вас у корені сайту і писати вище просто нікуди, залиште стандартний шлях і натомість заблокуйте доступ на рівні сервера. Для Apache:

<Files "debug.log">
  Require all denied
</Files>

Це має йти у файл .htaccess усередині wp-content, а не в кореневий: WordPress переписує кореневий .htaccess, коли ви зберігаєте постійні посилання, і може стерти ваше доповнення. На nginx .htaccess не робить нічого взагалі — там потрібен блок location у конфігурації сервера, а на керованому хостингу це зазвичай означає звернення до підтримки.

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

Як читати файл і стежити за ним

Через SSH можна дивитися журнал наживо, поки ви відтворюєте помилку:

tail -f wp-content/debug.log

Відтворіть помилку в іншій вкладці — і нові рядки з’являтимуться в міру запису. Щоб побачити лише те, що сталося нещодавно, або відфільтрувати за одним плагіном:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

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

За допомогою WP-CLI константи можна перемикати без ручного редагування файлу:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Прапорець --raw тут принциповий: без нього значення запишеться як рядок "true", а не як булеве значення. Для варіанта зі шляхом навпаки — приберіть --raw, щоб значення записалося як рядок у лапках.

Немає SSH? Завантажте файл через SFTP або відкрийте у файловому менеджері хостингу. Уникайте плагінів, які показують журнал усередині wp-admin, якщо не довіряєте їм цілком: ви даєте плагіну доступ на читання файлу, повного внутрішніх даних сервера.

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

Вимкніть журналювання, коли закінчите

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

Щоб очистити файл, не видаляючи його:

: > wp-content/debug.log

Коли журнал лишається порожнім

Пройдіться по цьому списку в такому порядку. WP_DEBUG має значення false — найпоширеніша причина, яка мовчки вимикає все інше. Константа стоїть нижче рядка про припинення редагування у wp-config.php. Права доступу — PHP не може писати у wp-content або у вказану вами власну теку. Фатальна помилка ще до завершення завантаження wp-config, наприклад синтаксична помилка в самому файлі конфігурації, стається надто рано, щоб журналювання WordPress її перехопило: такі помилки йдуть у власний журнал помилок PHP на сервері. Хостинг перевизначає налаштування — деякі керовані платформи жорстко задають параметр error_log у PHP або направляють журнали у власну панель, і тоді ваші константи виставлені правильно, а вивід просто в іншому місці. Перевірте переглядач журналів хостингу, перш ніж вирішувати, що ваша конфігурація зламана.