Білий екран смерті WordPress: пояснення
Білий екран смерті — це фатальна помилка PHP, яку ви не бачите. WordPress наштовхнувся на невиправну помилку посеред рендерингу, PHP зупинився, і оскільки вивід помилок
Опубліковано
Білий екран смерті — це фатальна помилка PHP, яку ви не бачите. WordPress наштовхнувся на невиправну помилку посеред рендерингу, PHP зупинився, і оскільки вивід помилок на робочих серверах вимкнено, замість причини сторінка повернулася порожньою. Виправлення майже ніколи не зводиться до вгадування: увімкніть журнал налагодження, відкрийте wp-content/debug.log і прочитайте останній рядок із фатальною помилкою. Він називає точний файл — майже завжди це плагін або шаблон — і саме цей один рядок і є всім ремонтом.
Чому екран порожній
У PHP є налаштування під назвою display_errors. На машині розробника воно зазвичай увімкнене, тож фатальна помилка виводить трасування стека на екран. На реальному хостингу воно вимкнене за замовчуванням, бо витік шляхів до файлів і помилок відвідувачам — це проблема безпеки. Тож коли щось спричиняє фатальну помилку — виклик функції, якої вже не існує, клас, який не завантажено, синтаксична помилка в оновленні плагіна — PHP аварійно завершується і не надсилає нічого. Ваш браузер відображає порожній документ. Це і є «білий екран».
Починаючи з WordPress 5.2 існує обробник фатальних помилок (WP_Fatal_Error_Handler), який намагається їх перехопити. Коли він спрацьовує, ви не бачите порожньої сторінки — ви бачите «На сайті виникла критична помилка», а також лист на адресу адміністратора, який часто містить власне помилку та посилання на режим відновлення (Recovery Mode). По-справжньому порожній екран зазвичай означає, що помилка виникла раніше, ніж цей обробник встиг спрацювати: помилка розбору/синтаксису (перехоплюється на етапі компіляції), зламаний must-use плагін або фатальна помилка у файлі functions.php активного шаблону. У будь-якому разі причина десь записана. Вам просто треба увімкнути запис.
Виправляємо по порядку
1. Увімкніть журнал. Відредагуйте wp-config.php через SFTP і додайте це над рядком /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_DISPLAY зі значенням false тримає помилки поза публічною сторінкою, тоді як WP_DEBUG_LOG записує їх у wp-content/debug.log. Перезавантажте зламану сторінку один раз, щоб згенерувати свіжий запис.
2. Прочитайте останню фатальну помилку. Відкрийте wp-content/debug.log і подивіться в самий низ:
tail -n 30 wp-content/debug.logВи шукаєте рядок на кшталт цього:
[14-Jul-2026 09:12:44 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88Шлях називає винуватця: plugins/some-addon. Це і є ваша відповідь. Якщо трасування довге або повідомлення незрозуміле (Allowed memory size exhausted, Cannot redeclare, назва класу, якої ви не впізнаєте), вставте його в наш декодер журналу помилок — він прибирає шум, каже, на який плагін чи шаблон вказує шлях, і пояснює, що означає конкретний тип помилки.
3. Вимкніть названий компонент. Ви не можете дістатися до /wp-admin, тож зробіть це через SFTP. Перейменуйте теку проблемного плагіна, наприклад some-addon → some-addon.off. WordPress не може завантажити теку, якої не може знайти, тож він деактивує плагін, і сайт повертається до життя. Якщо журнал вказує на ваш шаблон, перейдіть на стандартний шаблон, перейменувавши теку активного шаблону — WordPress повернеться до вбудованого twentytwentysomething.
4. Якщо журнал не записується, значить wp-content недоступний для запису, або помилка на рівні сервера. Тоді перевірте журнал помилок PHP хостингу:
find . -name "error_log" -newermt "-1 hour"Та сама інформація, інший файл. Стеки cPanel/Apache часто скидають error_log у корінь сайту або в теку, де стався збій.
Чого не варто робити
Не варто просто піднімати ліміт пам’яті. Найпоширеніша порада в мережі — підняти WP_MEMORY_LIMIT до 256M або 512M. Це виправить WSOD лише тоді, коли журнал справді каже Allowed memory size of N bytes exhausted. Якщо помилка — Call to undefined function, більше пам’яті нічого не дасть — ви навмання змінили налаштування, а екран усе одно білий. Спершу прочитайте журнал, і лише потім піднімайте пам’ять, якщо проблема саме в пам’яті.
Не варто чистити кеш і вважати це діагнозом. Білий екран — це коли PHP аварійно завершується на сервері ще до того, як з’явиться будь-який HTML. Застарілий кешований ресурс не може спричинити порожній документ. (А от зламаний плагін кешування може — але журнал його назве, у чому й суть.)
Не варто редагувати чи перевстановлювати ядро WordPress. Фатальна помилка майже ніколи не в wp-includes чи wp-admin; вона в плагіні або шаблоні, на який вказує журнал. Перевстановлення ядра повільне, ризиковане і лікує симптом, який ви не підтвердили.
Не варто вимикати всі плагіни й наосліп вмикати їх по одному. Метод поділу навпіл працює, але це повільний шлях. Журнал вказує на точну теку за один крок. Беріться за метод «вимкнути все» лише тоді, коли жодної читабельної помилки взагалі немає.
Не варто залишати display_errors увімкненим у продакшені. Щойно сайт повернувся до життя, приберіть налагоджувальні define (або поверніть WP_DEBUG назад на false). Помилки, виведені відвідувачам, розкривають ваші шляхи.
Досі не виходить?
Якщо журнал називає плагін, але його вимкнення не прибирає екран, значить під першою фатальною помилкою є друга — увімкніть журнал знову і прочитайте новий останній рядок; фатальні помилки нашаровуються. Якщо стіною стало саме повідомлення, вкиньте його в декодер журналу помилок і нехай він перекладе тип помилки та шлях до файлу за вас. Білий екран лишається загадкою лише поки журнал вимкнено.