Відновлення WordPress: Білий екран смерті — робоче 5-крокове вирішення

Швидкий план діагностики (що перевірити спочатку)

Якщо ви на чергуванні, втомлені, і ваш Slack перетворюється на місце злочину, користуйтеся цим. Оптимізовано для часу до сигналу. Мета — ідентифікувати рівень, що є вузьким місцем: edge/кеш, веб-сервер, середовище PHP, база даних або код WordPress (плагіни/теми).

По-перше: чи справді це origin?

• Перевірте з вашого ноутбука з обходом кешу. Якщо CDN або зворотний проксі віддає закешовану порожню відповідь, ви будете ганятися за примарами на сервері.
• Зверніться безпосередньо до origin (hosts file, пряма IP з Host header, або внутрішній DNS балансувальника), щоб ізолювати проблему edge.

По-друге: це HTTP-проблема чи PHP-проблема?

• Подивіться HTTP-статус і заголовки. 200 з тілом 0 байт часто означає, що PHP впав після відправки заголовків, проблеми з буферизацією виводу або кешування віддало порожній об’єкт.
• Тайл веб- та PHP-журнали. Потрібна рядок fatal error з відміткою часу, що відповідає порожньому запиту.

По-третє: змусьте WordPress «визнати провину»

• Увімкніть WP_DEBUG + debug.log (обережно) і відтворіть один раз.
• Вимкніть плагіни масово (перейменування каталогу або WP-CLI) і повторно перевірте.
• Переключіться на дефолтну тему і повторно перевірте.

По-четверте: непрестижні речі

• Пам’ять/ліміти: PHP memory_limit, max_execution_time, opcache, права файлів, диск заповнений.
• Останні зміни: оновлення, новий плагін, нова тема, зміна версії PHP, виконання конфігураційного менеджменту, зміна політики очищення кешу.

Це план. Тепер зробимо роботу з п’ятикроковою послідовністю, яка дає відповіді, а не відчуття.

Що таке WSOD насправді (і чому він бреше)

WSOD — це не одна помилка. Це симптом: ваш запит завершився без відображення видимого виводу. Це може статися з кількох причин:

• PHP fatal error до виводу (або вивід пригнічено). Часто спричинено несумісним кодом плагіна/темою, відсутніми класами або викликом функції, яка була видалена в новішій версії PHP.
• Вичерпання пам’яті (класичне): «Allowed memory size exhausted». Іноді ви не побачите цього в браузері, бо display_errors вимкнено.
• Проблеми з буферизацією/кешуванням: шар кешування зберіг порожню відповідь і охоче повертає її як «успішну».
• Проблеми з правами або файловою системою: WordPress не може прочитати файли теми, не може записати кеш, не може автозавантажити щось; середовище зупиняється.
• Проблеми з opcode cache (менш поширено зараз, але реальні): застарілий opcache після деплою або зламані патерни інвалідації.
• Проблеми edge/CDN: це може бути не WordPress взагалі. «Біла сторінка» може бути плейсхолдером проміжного шару.

WSOD «бреше», бо браузери ввічливі. Вони не кричать про порожнє тіло; просто рендерять нічого. Ваш сервер, однак, кричав — у журналах, stderr, systemd journal — десь. Ваше завдання — знайти, куди пішов цей крик.

Одне висловлювання, яке варто пам’ятати під час інцидентів:

«Надія — не стратегія.» — Gene Kranz

Ось операції в п’яти словах: припиніть сподіватися, що «це просто кеш», і почніть доводити, який шар дає збій.

Жарт №1: Білий екран смерті — єдиний випадок, коли порожня сторінка вважається «повною прозорістю».

5-крокове вирішення, яке працює

Крок 1: Підтвердіть режим відмови (код статусу, розмір тіла, причетність кешу)

Перед тим, як чіпати WordPress, підтвердіть, що саме отримують клієнти. Якщо edge віддає закешовану порожню відповідь, ви виправите origin і все одно побачите білий екран, поки кеш не протухне.

Робіть: захопіть заголовки, код статусу, content-length та заголовки кешу. Порівняйте origin vs CDN.

Уникайте: негайного редагування wp-config.php на основі інтуїції. У продакшні інтуїції породжують другий інцидент.

Крок 2: Читайте журнали серйозно (веб + PHP-FPM + system journal)

WSOD зазвичай — PHP fatal error. Fatal потрапляє в логи PHP-FPM, лог помилок веб-сервера або system journal залежно від налаштувань стеку.

Робіть: тайл журнали під час відтворення проблеми один раз. Кореляція за часом краща за археологію.

Уникайте: читання логів триденної давності, поки балансувальник здоров’я збиває нові відмови кожну секунду.

Крок 3: Увімкніть логування WordPress без перетворення сайту на «будинок сповідань»

WordPress може логувати PHP notices/warnings/fatals у wp-content/debug.log. Це часто найчистіше джерело правди для помилок плагінів/тем.

Робіть: увімкніть логування, вимкніть відображення в браузері, відтворіть проблему, потім вимкніть.

Уникайте: увімкнення display_errors на публічному сайті. Команди безпеки мають почуття теж.

Крок 4: Швидко зменшіть складність (вимкніть усі плагіни, змініть тему)

Більшість WSOD — самостійно спричинені кодом всередині WordPress. Плагіни й теми — недовірений код з гарним UI. Тож поводьтеся з ними відповідно.

Робіть: вимкніть плагіни масово (перейменуйте каталог plugin або WP-CLI). Потім переключіться на дефолтну тему (Twenty Twenty-*). Перевіряйте після кожної зміни.

Уникайте: відключення плагінів по одному через wp-admin, коли сам wp-admin порожній. Це не діагностика; це перформанс-арт.

Крок 5: Усуньте базове обмеження (пам’ять, версія PHP, права, сховище, БД)

Коли ви знаєте тригер — несумісність плагіна, відсутній PHP-розширення, вичерпання пам’яті, повний диск — застосуйте реальне виправлення. Якщо це пам’ять, підвищте її коректно та підтвердіть; якщо це поганий деплой — відкотіться; якщо диск — звільніть місце і запобігайте повторенню. Відновлення — не те саме, що запобігання.

Тепер давайте конкретніше з командами. Не «спробуйте вимкнути і ввімкнути знову». Реальні задачі, реальні виводи, реальні рішення.

Практичні завдання: команди, виводи та рішення (12+)

Припущення для прикладів нижче:

• Linux-сервер з Nginx + PHP-FPM (згадуватимемо також Apache).
• WordPress розташований у /var/www/wordpress.
• У вас є SSH і sudo.

Завдання 1: Перевірте HTTP-статус, заголовки та розмір тіла (з шелла)

cr0x@server:~$ curl -sS -D - -o /dev/null -w "status=%{http_code} bytes=%{size_download} time=%{time_total}\n" https://example.com/
HTTP/2 200 
date: Tue, 04 Feb 2026 10:12:01 GMT
content-type: text/html; charset=UTF-8
cache-control: max-age=0, must-revalidate
cf-cache-status: HIT
status=200 bytes=0 time=0.092

Що це означає: HTTP 200, але bytes=0. Також заголовок кешу показує, що CDN віддав відповідь (HIT).

Рішення: Обійдіть кеш / зверніться безпосередньо до origin. Не чіпайте WordPress поки; можливо, ви бачите закешовану порожню відповідь.

Завдання 2: Обійдіть кеш і порівняйте відповідь

cr0x@server:~$ curl -sS -H "Cache-Control: no-cache" -D - -o /dev/null -w "status=%{http_code} bytes=%{size_download}\n" https://example.com/
HTTP/2 500 
date: Tue, 04 Feb 2026 10:12:11 GMT
content-type: text/html; charset=UTF-8
status=500 bytes=0

Що це означає: Обхід кешу виявив 500 на origin (або принаймні не кешований). Добре: тепер ви женетеся за реальною помилкою.

Рішення: Негайно переходьте до журналів і відтворіть проблему один раз.

Завдання 3: Тайл лог помилок Nginx під час відтворення

cr0x@server:~$ sudo tail -n 50 -f /var/log/nginx/error.log
2026/02/04 10:12:11 [error] 13219#13219: *918 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function get_field() in /var/www/wordpress/wp-content/themes/custom/functions.php:211" while reading response header from upstream, client: 203.0.113.15, server: example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

Що це означає: Тема викликає get_field() (Advanced Custom Fields), але функція не існує — плагін відсутній/вимкнений або підключений занадто пізно.

Рішення: Вимкніть тему або відновіть відсутній плагін. Це не проблема бази даних. Це код.

Завдання 4: Тайл лог PHP-FPM (або systemd journal) для fatal

cr0x@server:~$ sudo tail -n 50 -f /var/log/php8.2-fpm.log
[04-Feb-2026 10:12:11] WARNING: [pool www] child 22109 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function get_field() in /var/www/wordpress/wp-content/themes/custom/functions.php:211"

Що це означає: Підтверджує, що fatal походить із рантайму PHP. Тепер у вас є файл і номер рядка.

Рішення: Продовжуйте із ізоляцією теми/плагіна (Крок 4) і/або відкотіть зміну теми.

Завдання 5: Перевірте вільне місце на диску (іноді порожня сторінка означає «диск повний»)

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        80G   79G  200M 100% /
tmpfs           3.8G  2.0M  3.8G   1% /run

Що це означає: Кореневий розділ заповнений. PHP може не вміти записувати сесії, файли кешу чи логи; WordPress не зможе оновити автозавантажувані опції; усе починає поводитись дивно.

Рішення: Звільніть місце зараз (логи, старі релізи, кеш), потім налаштуйте ротацію/моніторинг. Не «підвищуйте пам’ять» для проблеми диску.

Завдання 6: Швидко знайдіть, що споживає простір

cr0x@server:~$ sudo du -xhd1 /var | sort -h
120M	/var/cache
1.8G	/var/lib
6.5G	/var/log
14G	/var/www

Що це означає: Логи великі. Це або висока навантаженість, або цикл логування, або відсутня ротація.

Рішення: Проінспектуйте /var/log і безпечно оберніть/обріжте (і виправте корінь проблеми).

Завдання 7: Визначте топ-файли, що заповнюють логи

cr0x@server:~$ sudo find /var/log -type f -printf "%s %p\n" | sort -n | tail -n 10
2147483648 /var/log/nginx/access.log
1073741824 /var/log/nginx/error.log
536870912 /var/log/php8.2-fpm.log

Що це означає: Ваші логи роздуваються. Можливо, атака ботів, цикл редиректів, або залишене налагодження.

Рішення: Обріжте файли, щоб відновити простір (короткостроково), потім виправте logrotate і шумні помилки (довгостроково).

Завдання 8: Безпечне усічення для швидкого відновлення простору

cr0x@server:~$ sudo sh -c ': > /var/log/nginx/error.log; : > /var/log/php8.2-fpm.log'

Що це означає: Файли усічено на місці (процеси зберігають дескриптори). Це дає передишку без перезапуску сервісів.

Рішення: Негайно перевірте df -h. Потім налаштуйте ротацію. І подумайте, чому error.log став 1 ГБ: це ненормально.

Завдання 9: Увімкніть логування WordPress (контрольовано)

Відредагуйте wp-config.php і встановіть ці значення ближче до кінця, перед “That’s all”:

cr0x@server:~$ sudo sed -n '1,120p' /var/www/wordpress/wp-config.php
<?php
/* ...existing config... */
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
/* That's all, stop editing! Happy publishing. */

Що це означає: Помилки йдуть у wp-content/debug.log, не в браузер.

Рішення: Відтворіть WSOD один раз, потім прочитайте debug.log. Вимкніть це після збору доказів.

Завдання 10: Прочитайте WordPress debug лог

cr0x@server:~$ sudo tail -n 60 /var/www/wordpress/wp-content/debug.log
[04-Feb-2026 10:12:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function get_field() in /var/www/wordpress/wp-content/themes/custom/functions.php:211
Stack trace:
#0 /var/www/wordpress/wp-settings.php(595): include()
#1 /var/www/wordpress/wp-config.php(95): require_once('...')
#2 /var/www/wordpress/wp-load.php(50): require_once('...')
#3 /var/www/wordpress/wp-blog-header.php(13): require_once('...')
#4 /var/www/wordpress/index.php(17): require('...')
#5 {main}
  thrown in /var/www/wordpress/wp-content/themes/custom/functions.php on line 211

Що це означає: Підтверджує fatal на рівні теми, відсутність функції плагіна. Стек показує, що збій відбувається під час bootstrap.

Рішення: Виправте залежність теми або відновіть потрібний плагін. Швидке відновлення: переключитися на дефолтну тему.

Завдання 11: Вимкнути всі плагіни через файлову систему (працює, коли wp-admin мертвий)

cr0x@server:~$ cd /var/www/wordpress/wp-content
cr0x@server:~$ sudo mv plugins plugins.disabled
cr0x@server:~$ ls -l
drwxr-xr-x  2 www-data www-data 4096 Feb  4 10:13 plugins.disabled
drwxr-xr-x 10 www-data www-data 4096 Feb  4 09:50 themes

Що це означає: WordPress не знайде плагінів; він вважатиме їх деактивованими.

Рішення: Повторно протестуйте сайт. Якщо він повернувся — довели провину плагіна. Потім вмикайте вибірково (перейменуйте назад або активуйте по черзі через WP-CLI).

Завдання 12: Переключити тему без wp-admin (перейменувати каталог активної теми)

cr0x@server:~$ cd /var/www/wordpress/wp-content/themes
cr0x@server:~$ sudo mv custom custom.disabled
cr0x@server:~$ ls -1
custom.disabled
twentytwentyfour
twentytwentythree

Що це означає: WordPress впаде до доступної дефолтної теми.

Рішення: Якщо сайт завантажується, ваша тема — винуватець. Тримайте дефолтну тимчасово; виправляйте кастомну тему офлайн.

Завдання 13: Використайте WP-CLI для масового відключення плагінів (чистіше, коли доступно)

cr0x@server:~$ cd /var/www/wordpress
cr0x@server:~$ sudo -u www-data wp plugin deactivate --all
Plugin 'akismet' deactivated.
Plugin 'advanced-custom-fields' deactivated.
Success: Deactivated 12 of 12 plugins.

Що це означає: Плагіни вимкнено на рівні WordPress (стан у БД), а не просто сховано через файлову систему.

Рішення: Якщо вимкнення вирішує WSOD, вмикайте плагіни по одному, поки не зламається. Тоді матимете винуватця.

Завдання 14: Перевірте PHP memory limit і поточну версію PHP

cr0x@server:~$ php -v
PHP 8.2.14 (cli) (built: Jan 15 2026 10:20:41) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.14, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.14, Copyright (c), by Zend Technologies
cr0x@server:~$ php -i | egrep -i "memory_limit|opcache.enable|max_execution_time" | head
memory_limit => 128M => 128M
max_execution_time => 30 => 30
opcache.enable => On => On

Що це означає: 128M часто замало для сучасних стеків WordPress з page builder-ами, важкими плагінами або великими автозавантаженими опціями.

Рішення: Якщо логи показують вичерпання пам’яті, підвищте memory_limit у конфігурації PHP-FPM або php.ini (не лише в wp-config) і повторно перевірте.

Завдання 15: Знайти fatal через вичерпання пам’яті в логах

cr0x@server:~$ sudo grep -R "Allowed memory size" -n /var/log/nginx/error.log | tail -n 3
/var/log/nginx/error.log:9921:FastCGI sent in stderr: "PHP message: PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/wordpress/wp-includes/class-wpdb.php on line 2345"

Що це означає: Це не помилка теми; це пам’ять. WordPress впав у коді бази даних, бо PHP закінчилася пам’ять.

Рішення: Підніміть ліміт пам’яті і дослідіть, що споживає RAM (цикли плагінів, величезні автозавантажені опції, гігантські запити).

Завдання 16: Швидко перевірте підключення до БД (не припускайте, перевірте)

cr0x@server:~$ mysqladmin -u wpuser -p ping
Enter password: 
mysqld is alive

Що це означає: БД доступна з наведеними обліковими даними (принаймні з цього хосту). WSOD ймовірно не «БД впала».

Рішення: Перейдіть до PHP/шляху WordPress, якщо тільки логи не показують помилок або таймаутів БД.

Завдання 17: Перевірте, що PHP-FPM працює і слухає там, де очікує Nginx

cr0x@server:~$ systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled)
     Active: active (running) since Tue 2026-02-04 09:01:22 UTC; 1h 13min ago
cr0x@server:~$ sudo ss -lxn | grep php8.2-fpm.sock
u_str LISTEN 0      4096   /run/php/php8.2-fpm.sock 12345678            * 0

Що це означає: Сервіс запущено, сокет слухає. Якщо ви все ще отримуєте порожні відповіді — ймовірно, проблема на рівні застосунку або права на сокет.

Рішення: Якщо сокет пропав — перезапустіть PHP-FPM; якщо права неправильні — виправте власника/режим. Інакше продовжуйте шукати в логах.

Завдання 18: Перевірте останні зміни (пакети, деплои) без легенд

cr0x@server:~$ grep -E "upgrade|install" /var/log/dpkg.log | tail -n 8
2026-02-04 08:55:10 upgrade php8.2-fpm:amd64 8.2.13-1 8.2.14-1
2026-02-04 08:55:12 upgrade php8.2-cli:amd64 8.2.13-1 8.2.14-1
2026-02-04 08:55:15 upgrade nginx:amd64 1.24.0-1 1.24.0-2

Що це означає: PHP і Nginx недавно змінилися. Несумісність плагінів/тем з версіями PHP — частий тригер WSOD після оновлень.

Рішення: Якщо це корелює з початком інциденту — розгляньте відкат оновлення PHP або виправлення несумісного плагіна/теми.

Три корпоративні міні-історії з продакшену

Міні-історія 1: Аутедж через неправильне припущення

У середній компанії з підходом «WordPress — це просто маркетинг», платформа перемістила сайт за CDN з агресивним кешуванням. Зробили швидкий smoke test: головна сторінка завантажилась, кілька внутрішніх сторінок — і все. Вони вирішили, що 200 завжди означає «здорово».

Через два дні оновлення плагіна внесло PHP fatal error у конкретному шаблоні, що використовувався на лендингах кампаній. Origin почав повертати 500 з порожнім тілом для тих сторінок. CDN, налаштований кешувати «успішні» відповіді тільки за кодом статусу, мав баг у правилі: він кешував відповідь навіть коли тіло було порожнім через неправильно задану умову. Відвідувачі бачили чистий 200 і порожню сторінку. Моніторинг не спрацював, бо перевіряв тільки код статусу, а не довжину тіла чи ключове слово.

Інженер на чергуванні витратив годину на перезапуск сервісів, бо «це WordPress, воно повернеться». Не повернулося. Помилка була детермінована. Коли вони обійшли CDN і перевірили origin напряму, за хвилину побачили 500 і PHP fatal.

Вирішили проблему, змінивши health checks, щоб вони перевіряли контент (простий HTML-маркер), підправили правила кешування, щоб не кешувати порожні тіла, і зробили «обхід origin» кроком нуль у рукописі інциденту.

Міні-історія 2: Оптимізація, що зіграла проти

Великa організація вирішила зменшити затримки PHP, підвищивши налаштування OPCache і ввівши агресивний preloading. Зміна вийшла під час рутинного вікна обслуговування. Виглядало чудово: швидше TTFB, менше CPU. Усі святкували.

Потім почалися білі екрани — періодично. Не для кожного запиту, але достатньо, щоб зіпсувати день. Проблема була не в WordPress; вона була в механіці деплою. Процес деплою замінював PHP-файли на місці й інколи оновлював каталоги плагінів, поки PHP-FPM воркери обробляли запити. З preloading і опціями opcache, що зменшили перевірки файлів, деякі воркери виконували суміш старих і нових шляхів коду. Коли клас перемістився, автозавантаження зламалося, виникли fatal, що проявлялися як порожні сторінки.

Виправлення було нудним: припинити заміну файлів на місці. Деплой робити в новий каталог релізу, а потім атомарно перемикати symlink. Також підлаштували параметри OPCache під їхній патерн деплою замість копіювання «кращих налаштувань» з блогу-бенчмарку.

Покращення продуктивності реальні, але «швидко», що інколи помиляється, — це просто інший вид даунтайму.

Міні-історія 3: Нудна практика, що врятувала день

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

Коли WSOD виник після оновлення теми, інженер на чергуванні не панікував. Він подивився панель: витрата бюджету помилок, сплески PHP-FPM fatals і чіткий рядок у логах, що вказував на відсутню функцію. Вони відкотилися до попереднього релізу за секунди, перевернувши symlink і перезавантаживши PHP-FPM. Сайт повернувся миттєво.

Потім, у світлий час доби, вони відтворили проблему у staging з тією ж версією PHP і набором плагінів, виправили перевірки залежностей теми (обгортання викликів функцій плагінів перевірками), і повторно задеплоїли коректно. Постмортем був коротким, бо факти вже були в логах і хроніці змін.

Це не героїзм. Це тиха компетентність: бекапи, відкатні шляхи і телеметрія, яка не зникає, коли вона потрібна.

Типові помилки: симптом → корінь → виправлення

Діагностика WSOD зазвичай провалюється передбачуваними способами. Ось звичні пастки з конкретними ремедіаціями.

1) Симптом: головна сторінка — біла, але деякі глибокі URL працюють

Корінь: шаблон теми або хук front-page викликає fatal; іноді це шорткод page builder-а на головній.

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

2) Симптом: wp-admin білий, фронтенд нормальний (або навпаки)

Корінь: плагін тільки для адмінки, mu-plugin або адмінний хук викликає fatal. Або плагін можливостей ламає ініціалізацію адмінки.

Виправлення: Вимкніть усі плагіни і протестуйте wp-admin окремо. Перевірте wp-content/mu-plugins на must-use плагіни; вони не відключаються як звичайні.

3) Симптом: HTTP 200 з пустим тілом, тільки через CDN

Корінь: закешована порожня відповідь, неправильна конфігурація правила edge або origin повертає chunked відповідь, що обробляється неправильно.

Виправлення: Обійдіть CDN і порівняйте. Прочистіть кеш для уражених шляхів. Оновіть правила кешування, щоб не зберігати порожні тіла, і перевіряйте відповіді origin.

4) Симптом: білий екран після оновлення версії PHP

Корінь: плагін/тема використовує застарілі або видалені фічі, строгі типи або несумісні залежності.

Виправлення: Ідентифікуйте рядок fatal; оновіть або замініть плагін/тему; за потреби тимчасово відкотіть версію PHP. Не «просто піднімайте пам’ять».

5) Симптом: WSOD з’являється під навантаженням, зникає при зниженні трафіку

Корінь: виснаження PHP-FPM воркерів, повільні запити до БД, дедлоки або таймаути зовнішніх API призводять до довгих запитів і каскаду відмов.

Виправлення: Перевірте налаштування пулу PHP-FPM і slow логи; перевірте slow query log в БД; додайте таймаути; кешуйте зовнішні виклики. Масштабуйте тільки після розуміння насичення.

6) Симптом: WSOD після увімкнення плагіна кеш/мінімізації

Корінь: зламані мініфіковані JS/CSS не дають WSOD (вони ламають верстку). Але кеш-плагіни можуть генерувати порожній HTML або об’єктний кеш може отруїти результати.

Виправлення: Очистіть кеш плагіна, вимкніть плагін кешу і видаліть згенеровані кеш-директорії. Підтвердіть байти відповіді і HTML-контент, а не «інколи виглядає нормально».

7) Симптом: WSOD бачать тільки залогінені користувачі

Корінь: хук для конкретних користувачів, admin bar, конфлікт персоналізованого кешу або проблема з сесіями (диск повний, права).

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

8) Симптом: WSOD після «невеликої зміни конфігу» в wp-config.php

Корінь: синтаксична помилка (відсутня лапка/крапка з комою), кодування/пробіли перед <?php або дублювання визначень констант.

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

Жарт №2: Ніщо не кричить «чудо-корпорація», як продакшен-аутедж через відсутню крапку з комою в файлі wp-config.php.

Чек-листи / покроковий план

Чек-лист інциденту: спочатку відновіть сервіс, потім виправляйте правильно

1. Зберіть докази: код статусу + заголовки + розмір тіла з клієнта і з origin. Збережіть у нотатках інциденту.
2. Тайл логів під час відтворення: веб-сервер + PHP-FPM. Отримайте рядок fatal.
3. Тимчасово увімкніть WP_DEBUG_LOG, якщо журнали не дають достатньо деталей.
4. Вимкніть плагіни масово (перейменуйте каталог plugins або WP-CLI). Повторно перевірте.
5. Переключіться на дефолтну тему (перейменуйте каталог кастомної теми). Повторно перевірте.
6. Виправте обмеження: пам’ять/диск/права/несумісність версії PHP тощо.
7. Відкат при потребі: поверніть останній деплой або відновіть останню відому робочу резервну копію.
8. Вимкніть debug логування і приберіть тимчасові зміни.
9. Запишіть корінь проблеми і захисний механізм, щоб запобігти повторенню (моніторинг, тести, зміна процесу деплою).

Чек-лист ізоляції плагінів (швидкий, безпечний спосіб)

1. Вимкніть усі плагіни.
2. Переконайтеся, що сайт завантажується (фронтенд і wp-admin).
3. Повторно вмикайте плагіни по одному, тестуючи після кожного.
4. Коли зламається — знайшли тригер. Тримайте його вимкненим.
5. Пошукайте сумісне оновлення; інакше замініть плагін.

Чек-лист ізоляції теми

1. Переключіться на дефолтну тему.
2. Якщо сайт завантажується, кастомна тема — підозрювана.
3. Шукайте у коді теми прямі виклики функцій плагінів; обгорніть їх у function_exists().
4. Виправляйте у staging з тією ж версією PHP і набором плагінів.

Чек-лист запобігання (SRE-нативні речі, які часто пропускають)

1. Health checks перевіряють контент, а не лише HTTP 200.
2. Бекапи тестуються (відновлювальні вправи), а не просто «увімкнені».
3. Деплои атомарні (symlink releases), а не заміна файлів на місці.
4. Існує ротація логів і алерти по диску спрацьовують ще до 95% заповнення.
5. Staging відповідає продакшену по версії PHP і критичним розширенням.
6. Оновлення плагінів фіксуються або принаймні групуються з нотатками про відкат.

Цікаві факти та історія (бо це не почалося вчора)

• WordPress почався у 2003 році як форк b2/cafelog; екосистема плагінів швидко росла, як і площа уразливості стороннього PHP-коду.
• Термін «White Screen of Death» старший за WordPress і був популяризований в інших екосистемах (зокрема ранні Windows і консольні крахи), але веб-розробники використали його для порожніх сторінок без помилок.
• Раніше WordPress часто працював з увімкненим display_errors у shared hosting; сучасні стеки зазвичай ховають помилки в браузері, що безпечніше, але робить WSOD «тихим».
• Реліз PHP 7 (2015) був значним зрушенням продуктивності; він також виявив проблеми сумісності в старих плагінах/темах, що часто викликало WSOD під час оновлень.
• PHP 8 приніс більшу суворість і змінив поведінку помилок; код, який «працював випадково», може почати фатально падати, особливо в старих темах.
• Порядок завантаження плагінів у WordPress важливий: mu-plugins завантажуються раніше звичайних плагінів, і теми можуть виконувати код рано через functions.php — зручно, але разом з тим джерело аутеджів.
• Кешування може зробити відмови стійкими: коли пусту відповідь закешовано на edge, ви можете «полагодити» origin і все одно віддавати білі сторінки, поки не очистите кеш або не завершиться TTL.
• Інциденти через заповнений диск трапляються непропорційно часто у середовищах WordPress через медіа-завантаження, локально збережені резервні копії і вербозні логи при помилках.
• WSOD не завжди означає WordPress: неправильно налаштовані PHP-FPM сокети, неправильні fastcgi параметри або відмови SELinux/AppArmor можуть проявлятися як порожня сторінка.

Питання й відповіді

1) Чому моя сторінка WordPress повністю біла без помилки?

Тому що в продакшні помилки зазвичай не відображаються. PHP, ймовірно, отримав fatal error або вичерпав пам’ять, і вивід не відрендерився. Дивіться веб/PHP логи або тимчасово увімкніть WP_DEBUG_LOG.

2) Чи WSOD завжди через плагін?

Ні. Плагіни часті, але теми, mu-plugins, оновлення версії PHP, повний диск та шари кешування також можуть давати той самий симптом: нічого.

3) Який найшвидший спосіб відновити, коли wp-admin теж порожній?

Вимкніть плагіни, перейменувавши wp-content/plugins, потім переключіть тему, перейменувавши каталог активної теми. Це обходить wp-admin повністю.

4) Чи варто увімкнути WP_DEBUG у продакшні?

Тимчасово — так, з WP_DEBUG_DISPLAY вимкненим і WP_DEBUG_LOG увімкненим. Захопіть помилку і вимкніть. Тривале увімкнення debug може відкривати чутливі шляхи і заповнювати диск логами.

5) Я отримую HTTP 200, але сторінка пуста. Як так?

Коди статусу можуть брехати через упущення. Реверс-проксі може повернути 200 з порожнім тілом з кешу, або PHP міг відправити заголовки перед крахом. Перевірте розмір тіла відповіді та заголовки кешу, а потім порівняйте origin vs edge.

6) Я підняв пам’ять у wp-config.php, але WSOD лишається. Чому?

Бо ефективний ліміт часто встановлюється у конфігурації PHP-FPM pool або php.ini. Також не всі WSOD пов’язані з пам’яттю. Підтвердіть у логах повідомлення «Allowed memory size exhausted» перед тим, як змінювати ліміти.

7) Чи може проблема з базою даних спричинити WSOD замість «Error establishing a database connection»?

Так. Повільні запити, заблоковані таблиці або таймаути можуть призвести до насичення PHP-FPM і порожніх відповідей. Але в логах все одно повинні бути таймаути. Перевірте стан БД і slow логи, якщо проблема пов’язана з навантаженням.

8) Що робити, якщо вимкнення плагінів і зміна теми не допомогли?

Тоді проблема, ймовірно, нижче за рівнем WordPress: PHP-FPM впав, несумісність сокета, проблеми з правами/SELinux, відсутні PHP-розширення, диск повний або регресія конфігурації веб-сервера. Поверніться до статусів сервісів і логів.

9) Як зрозуміти, чи це Cloudflare (або інший CDN) чи мій сервер?

Порівняйте відповіді з заголовками обходу кешу і зверніться до origin напряму, якщо можливо. Якщо origin повертає нормальний HTML, а CDN — порожній, проблема на edge — очистіть кеш або виправте правила кешування.

10) Після відновлення, який один крок запобігання має найкращий ROI?

Перевірки здоров’я, що валідують контент, плюс процес деплою з можливістю швидкого відкату. Ці два кроки перетворюють «загадкову білу сторінку» на швидко обмежений інцидент.

Наступні кроки, які варто зробити

WSOD здається, ніби WordPress драматизує. Насправді це ваш стек говорить: «Я впав, і ви не підключили вивід помилок туди, де зручно». Виправлення — не один магічний прапорець; це повторювана послідовність.

1. Зараз: виконайте швидкий план діагностики. Захопіть статус/байти, обійдіть кеш, тайл логів, відтворіть один раз.
2. Відновіть сервіс: вимкніть плагіни масово, переключіться на дефолтну тему або відкотіть останній деплой.
3. Виправте корінь: запатчіть/замініть проблемний плагін/тему, виправте несумісність версії PHP, підвищуйте пам’ять тільки після доказу, вирішіть проблеми з диском/правами.
4. Запобігання: додайте health checks, що перевіряють контент, забезпечте ротацію логів і алерти по диску, та прийміть атомарні деплои з легким відкатом.

Вам не потрібні героями. Вам потрібні докази, ізоляція і дисципліна припиняти «оптимізувати» те, чого не виміряли.