Виправлення WordPress «Сталася критична помилка»: увімкніть WP_DEBUG і відновіть сайт

December 12, 2025 • February 3, 2026 • Читання: 5 хв • Views: 13

Було корисно?

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

Добра новина: більшість «критичних помилок» прості — невдале оновлення плагіна, функція теми, яка викликає те, чого вже немає, або брак пам’яті в PHP. Секрет у тому, щоб якомога швидше перейти від «щось зламалося» до точного стек-трейсу, не перетворивши продакшен-сервер на публічний журнал налагодження.

Що насправді означає «критична помилка» в WordPress

Цей банер — ввічлива форма повідомлення WordPress про фатальну помилку PHP. Щось кинула виключення або потрапило в фатальний стан і PHP припинив виконання. WordPress не зміг відрендерити сторінку, тож показав запасний текст про «критичну помилку». Раніше це називали «біла сторінка смерті» (WSOD). Сьогодні ви отримуєте дружніше повідомлення і, іноді, лист адміністратору з посиланням на відновлення.

У працездатній системі фатальна помилка має залишити слід: логи PHP-FPM, логи Apache/Nginx, WordPress debug log (якщо увімкнено) і іноді трасу в моніторингу продуктивності. Ваше завдання — зібрати перший корисний стек-трейс і прийняти чітке рішення: відкат, відключення, патч або відновлення.

Чим це не є

Не є проблемою входу в базу даних. Зазвичай це показує «Error establishing a database connection».
Не обов’язково збій сервера. Ваш вебсервер може бути здоровим, поки PHP падає.
Не доказ того, що WordPress «нестабільний». Це доказ того, що хтось випустив код, який не відповідає реальності (версії, залежності, припущення).

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

Коли продакшен-сайт лежить, не «починайте досліджувати». Запустіть короткий план і змусьте систему сказати вам, що сталося.

Перший: підтвердити, що це PHP fatal, і отримати точну рядок помилки

Перевірте лог вебсервера та лог PHP-FPM за останні кілька хвилин.
Якщо бачите стек-трейс із шляхом до плагіна чи теми — у вас вже є підозрюваний.
Якщо логи порожні або марні — увімкніть логування WordPress у файл тільки та перезавантажте сторінку один раз.

Другий: ізолюйте зміну, що спричинила помилку

Запитайте: що змінилося? Автоматичне оновлення плагіна, оновлення теми, апгрейд PHP, новий MU плагін, посилення безпеки?
Спершу відкотіть найсвіжішу зміну. Не робіть п’ять «виправлень», а потім не знайте, яке спрацювало.

Третій: відновіть сервіс найменш ризикованим способом

Вимкніть проблемний плагін (перейменуйте каталог або використайте WP-CLI) і підніміть сайт.
Переключіться на стандартну тему, якщо підозра падає на тему.
Якщо пошкоджені core-файли — перевстановіть core (не чіпаючи wp-content).
Якщо нічого не допомагає: відновіть із відомої доброї резервної копії, а потім обережно повторіть зміни.

Так, ви можете годину відлажувати кореневу причину. Але якщо CEO дивиться на тест завантаження головної сторінки на телефоні — спочатку зробіть так, щоб вона завантажувалася.

Кілька корисних фактів та історія (щоб припинити гадати)

WordPress ввів «режим відновлення при фатальній помилці» у 5.2 (2019), включно з листами адміністраторам і посиланням на «відновлення», коли плагін або тема викликають fatal.
Класичний WSOD часто був «просто» придушеним виводом PHP через display_errors=Off і відсутність налаштованого логування — тиша, а не відсутність помилок.
WP_DEBUG — це константа WordPress, а не налаштування PHP. Вона змінює поведінку WP (зокрема показ notice), але не замінює логування помилок PHP.
WP_DEBUG_LOG може писати в wp-content/debug.log навіть коли помилки не відображаються користувачам — корисно, але потенційно небезпечно для приватності, якщо налаштовано неправильно.
Багато критичних помилок — через невідповідність версій. Плагін вимагає PHP 8.1; сервер має PHP 7.4. Або плагін очікує хуків ядра, які з’явилися в новішій версії.
Opcode-кеш (OPcache) може робити відкат неефективним. Ви деплоїте виправлення, але старий байткод лишається до моменту скидання кешу.
Автооновлення зменшило відставання у патчах, але збільшило несподівані відмови. Особливо на сайтах, де «на стадії працювало», але не було інтеграційних тестів.
Деякі хости перехоплюють помилки PHP і показують власну дружню сторінку, що може приховувати реальну помилку, якщо не дивитися серверні логи.

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

Правила безпеки перед тим, як чіпати WP_DEBUG

Налагодження — це те місце, де добрі наміри перетворюються на витоки даних. Дійте свідомо.

Ніколи не вмикайте публічний вивід помилок у продакшені. Це означає: тримайте WP_DEBUG_DISPLAY вимкненим, тримайте PHP display_errors вимкненим.
Логуйте у файл, а не в браузер. Вивід у браузер може розкрити секрети, шляхи та токени всім, включно зі сканерами.
Припускайте, що логи містять персональні дані. Пошти, куки, іноді заголовки запитів — залежить від того, що викидають плагіни.
Обмежте час. Увімкніть логування, відтворіть помилку один раз, зафіксуйте стек-трейс, потім вимкніть або ротируйте логи.
Не «chmod 777» щоб вирішити проблему. Ви виправите помилку й створите більшу.

Жарт №1: Увімкнути WP_DEBUG_DISPLAY у продакшені — це як оголосити ваші паролі через стадіонний мікрофон: технічно ефективно, соціально катастрофічно.

Правильне увімкнення WP_DEBUG (і як зафіксувати реальну помилку)

Ви вмикаєте три речі в wp-config.php: режим налагодження, логування у файл і відсутність виводу. Опціонально: вкажіть кастомний шлях до лога поза web root (краще). Також розгляньте вимкнення конкатенації скриптів, що може допомогти при налагодженні адмінських JS-проблем, але це рідко стосується «критичної помилки».

Після фікса зафіксуйте налаштування — вимкніть

Режим налагодження не є способом життя. Це діагностичний інструмент. Якщо його залишити увімкненим, логи розростуться, шляхи витечуть, і впаде продуктивність через надмірну кількість notice.

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

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

Завдання 1: Перевірити, чи сайт справді падає так, як бачать користувачі

cr0x@server:~$ curl -I https://example.com/
HTTP/2 500
date: Thu, 26 Dec 2025 12:11:09 GMT
content-type: text/html; charset=UTF-8

Значення: HTTP 500 підтверджує помилку на сервері (не проблема кешу в браузері).

Рішення: Перейдіть одразу до серверних логів; не марнуйте час на wp-admin, який не завантажиться.

Завдання 2: Перевірити Nginx error log у проміжку інциденту

cr0x@server:~$ sudo tail -n 80 /var/log/nginx/error.log
2025/12/26 12:10:58 [error] 2211#2211: *184 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_environment_type() in /var/www/html/wp-content/plugins/acme-cache/acme-cache.php:91
Stack trace:
#0 /var/www/html/wp-settings.php(526): include_once()
#1 /var/www/html/wp-config.php(102): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-blog-header.php(13): require_once('...')
#4 /var/www/html/index.php(17): require('...')
#5 {main}
  thrown in /var/www/html/wp-content/plugins/acme-cache/acme-cache.php on line 91" while reading response header from upstream, client: 203.0.113.44, server: example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "example.com"

Значення: Маємо доказ: плагін acme-cache викликає функцію WordPress, яка відсутня в цій версії core.

Рішення: Спершу вимкніть цей плагін, щоб відновити сервіс, а потім вирішуйте питання сумісності версій.

Завдання 3: Перевірити лог PHP-FPM (якщо Nginx показує недостатньо)

cr0x@server:~$ sudo tail -n 60 /var/log/php8.1-fpm.log
[26-Dec-2025 12:10:58] WARNING: [pool www] child 3112 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_environment_type() in /var/www/html/wp-content/plugins/acme-cache/acme-cache.php:91"

Значення: Підтверджує, що це не помилка парсингу Nginx; це PHP, який падає.

Рішення: Продовжуйте з відключенням плагіна; немає потреби вмикати WP_DEBUG, якщо логи вже містять трейсу.

Завдання 4: Увімкнути логування WP (тільки файл), коли логи мовчать

cr0x@server:~$ sudo grep -n "WP_DEBUG" -n /var/www/html/wp-config.php

Значення: Пустий вивід означає, що константи відлагодження не встановлені.

Рішення: Додайте безпечні для продакшену налаштування відлагодження. Якщо вивід показує конфліктні визначення — виправте дублікати (перше визначення перемагає і може вести себе неочікувано).

Завдання 5: Створити безпечний каталог логів поза web root

cr0x@server:~$ sudo install -d -o www-data -g www-data -m 0750 /var/log/wordpress

Значення: Каталог створено, належить веб-користувачу і доступний лише власнику/групі.

Рішення: Використовуйте /var/log/wordpress/debug.log як ціль для WP_DEBUG_LOG.

Завдання 6: Редагувати wp-config.php безпечно і перевірити синтаксис

cr0x@server:~$ sudo php -l /var/www/html/wp-config.php
No syntax errors detected in /var/www/html/wp-config.php

Значення: Ваше редагування не внесло помилок парсингу. Так, люди це роблять опів на другу ночі.

Рішення: Якщо бачите «Parse error», відкотіть негайно; parse error заблокує все, включно з режимом відновлення WP.

Завдання 7: Викликати один запит і перевірити WordPress debug log

cr0x@server:~$ curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
500

cr0x@server:~$ sudo tail -n 80 /var/log/wordpress/debug.log
[26-Dec-2025 12:12:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_environment_type() in /var/www/html/wp-content/plugins/acme-cache/acme-cache.php:91

Значення: Debug log підтверджує файл/рядок, де відбувається помилка.

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

Завдання 8: Вимкнути плагін без wp-admin, перейменувавши каталог

cr0x@server:~$ cd /var/www/html/wp-content/plugins
cr0x@server:~$ sudo mv acme-cache acme-cache.disabled

Значення: WordPress не зможе завантажити плагін; він буде позначений як неактивний.

Рішення: Перезавантажте сайт. Якщо він поверне 200 — ви відновили сервіс; потім розберіться із сумісністю та стратегією оновлень.

Завдання 9: Використати WP-CLI для списку плагінів і чистої деактивації (переважно)

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo -u www-data wp plugin list --status=active
+-------------------+----------+--------+---------+
| name              | status   | update | version |
+-------------------+----------+--------+---------+
| woocommerce       | active   | none   | 8.2.1   |
| acme-cache        | active   | none   | 3.4.0   |
+-------------------+----------+--------+---------+

cr0x@server:~$ sudo -u www-data wp plugin deactivate acme-cache
Plugin 'acme-cache' deactivated.

Значення: WP-CLI може звертатися до вашої інсталяції WordPress; це хороший знак, що DB доступна і core завантажується частково.

Рішення: Віддавайте перевагу деактивації через WP-CLI замість перейменування директорій для чистішого стану — якщо тільки фатал не заважає WP-CLI завантажитися.

Завдання 10: Перевірити поточну версію WordPress core і порівняти з вимогами плагіна

cr0x@server:~$ sudo -u www-data wp core version
5.6.14

Значення: Core застарілий. Багато сучасних плагінів припускають наявність новіших функцій.

Рішення: Плануйте контрольоване оновлення core у staging, а не панічний апгрейд у продакшені — хіба що безпека вимагає негайного кроку.

Завдання 11: Перемкнути тему на стандартну, щоб виключити помилки теми

cr0x@server:~$ sudo -u www-data wp theme list
+------------------+----------+--------+---------+
| name             | status   | update | version |
+------------------+----------+--------+---------+
| twentytwentyfour | inactive | none   | 1.2     |
| custom-corp      | active   | none   | 9.7     |
+------------------+----------+--------+---------+

cr0x@server:~$ sudo -u www-data wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

Значення: Якщо сайт повернеться — тема винна (зазвичай functions.php або кастомний include).

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

Завдання 12: Підтвердити версію PHP і модулі (поширена пастка сумісності)

cr0x@server:~$ php -v
PHP 8.1.2 (cli) (built: Jan 15 2025 10:22:01) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.2, Copyright (c), by Zend Technologies

Значення: CLI PHP — 8.1. Це не завжди те ж саме, що FPM-версія, але підказка важлива.

Рішення: Також перевірте, який PHP-FPM сокет використовується в налаштуваннях Nginx/Apache. Невідповідність між CLI і FPM породжує абсурдні сесії відладки.

Завдання 13: Визначити PHP-FPM бекенд, що використовує сайт

cr0x@server:~$ sudo grep -R "fastcgi_pass" -n /etc/nginx/sites-enabled | head
/etc/nginx/sites-enabled/example.conf:42: fastcgi_pass unix:/run/php/php8.1-fpm.sock;

Значення: Nginx явно використовує php8.1-fpm.

Рішення: Якщо сокет вказує на іншу версію PHP, вирівняйте це. Багато «критичних помилок» — просто «не та версія PHP».

Завдання 14: Перевірити проблеми з лімітом пам’яті (фатали, що виглядають випадково)

cr0x@server:~$ sudo -u www-data wp eval 'echo ini_get("memory_limit"), PHP_EOL;'
128M

Значення: Ліміт пам’яті — 128M. Для сучасного WooCommerce + конструктора сторінок це може бути замало.

Рішення: Якщо логи показують «Allowed memory size exhausted», підвищте memory_limit у PHP-FPM пулі або php.ini і повторіть тест. Не ставте сліпо 2G; знайдіть і виправте споживача.

Завдання 15: Перевірити місце на диску та inode (так, це ламає WordPress)

cr0x@server:~$ df -h /var/www /var/log
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   38G  1.2G  97% /

cr0x@server:~$ df -i /var/www
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 2620000   1440  100% /

Значення: Inode-ів практично не лишилося. PHP може не вміти писати сесії, кеші, завантаження, логи. Помилки множаться.

Рішення: Очистіть масиви дрібних файлів (каталоги кешу, старі бекапи, debug-логи), а потім розгляньте перенесення uploads/cache на окреме сховище.

Завдання 16: Перевірити доступність бази даних через WP-CLI

cr0x@server:~$ sudo -u www-data wp db check
Success: Database checked.

Значення: БД доступна і таблиці в порядку на базовому рівні.

Рішення: Якщо це не вдається, припиніть звинувачувати плагіни; спершу виправте облікові дані БД, доступність MySQL або права.

Завдання 17: Очистити OPcache (коли ви впевнені, що деплой правильний, але поведінка ні)

cr0x@server:~$ sudo systemctl reload php8.1-fpm

Значення: Reload зазвичай скидає OPcache і перезапускає воркери бережно (залежить від конфига).

Рішення: Використовуйте reload після змін у коді, коли симптоми не збігаються з файлами. Якщо потрібний жорсткий скидання — рестартуйте, але подумайте про конкуренцію і трафік.

Шляхи відновлення: плагіни, теми, core, PHP

Шлях A: Оновлення плагіна зламало сайт

Це найпоширеніше. Моделі відмови: плагін припускає існування функції/класу, або ввів синтаксичну помилку, або тепер вимагає новішої версії PHP.

Зробіть це:

Вимкніть плагін (WP-CLI deactivate або перейменуйте каталог).
Підніміть сайт.
Потім вирішіть: оновити core/PHP до вимог плагіна, або відкотити плагін до сумісної версії.

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

Шлях B: Тема викликає fatal (functions.php — місце злочину)

Теми часто вбудовують «міні-фреймворк» код. Особливо кастомні теми люблять викликати функції з плагінів, які вони припускають активними. Потім хтось відключає плагін — і тема падає.

Переключіться на стандартну тему через WP-CLI.
Якщо WP-CLI не вмикається, перейменуйте wp-content/themes/custom-theme, і WordPress відкотиться до дефолтної.
Коли стабільно — виправте тему так, щоб вона коректно обробляла відсутність залежностей.

Шлях C: Невідповідність або пошкодження core

Іноді «критична помилка» виникає через відсутні файли core (помилковий деплой) або змінені файли (компроміс або плагін, що щось перезаписав).

Виправлення: перевстановіть core WordPress, не торкаючись wp-content і wp-config.php.

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo -u www-data wp core verify-checksums
Warning: File should not exist: wp-includes/some-stray-file.php
Error: Checksum verification failed.

Рішення: Якщо контрольні суми не сходяться, перевстановіть core (wp core download --force) і перевірте ще раз. Якщо виявлені неочікувані файли — розглядайте це як інцидент безпеки, поки не доведете протилежне.

Шлях D: Оновлення PHP зламало плагін (або виправило його і оголило старі баги)

Оновлення PHP — чудо доти, поки не виявиться проблемою. Застарілі функції стають фатальними, сувора типізація загострює помилки, бібліотеки поводяться інакше.

Стратегія:

Підтвердьте, яка версія PHP використовується веб-обробником (FPM) і порівняйте з тим, що підтримують WordPress та плагіни.
Якщо треба тимчасово відкотитися — зробіть це чисто (змініть FPM-сокет, перезавантажте вебсервер), а не редагуючи випадкові симлінки.
Довгостроково: оновіть плагіни/теми до сумісних версій; не тримайте PHP на старій версії вічно. Це закінчиться тим, що ви будете керувати музейним експонатом в інтернеті.

Шлях E: Витрачання ресурсів (пам’ять, диск, CPU) спричиняє каскадні відмови

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

Виправте платформу спершу: звільніть місце, ротируйте логи, скоригуйте ліміти пам’яті, додайте swap як тимчасовий вихід, і зменшіть кількість PHP-FPM воркерів, якщо вони “трешать” машину.

Жарт №2: Єдина річ, що росте швидше за плагіни WordPress — це debug.log, який ви забули ротувати.

Три корпоративні історії з практики

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

Середня по розміру роздрібна компанія використовувала WordPress для маркетингових сторінок і окрему платформу для чек-ауту. Хтось додав плагін продуктивності, який «вимагає WordPress 5.8+», але сайт давно був закріплений на 5.6 через сумісність з застарілим конструктором сторінок. Ніхто не помітив вимогу, бо плагін встановився, а стаджинг був новішим за продакшен.

У понеділок вранці автооновлення підтягнули мажорну версію плагіна. Він почав викликати функцію ядра, яка з’явилася після 5.6. Результат — негайний fatal на кожен запит. Моніторинг аптайму заголосив, маркетинг голосніше, а інфраструктурна команда отримала звинувачення у «проблемах сервера», бо сайт повертав HTTP 500.

Виправити було просто: перейменували каталог плагіна, відновили сервіс і вирівняли середовища. Реальний урок був гірший: staging тихо відійшов від production. Всі припускали «staging рівний production», бо так звучить професійно. Це не було правдою.

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

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

Великий внутрішній сайт комунікацій був повільний в адмінці. Інженер увімкнув агресивний об’єктний кеш і перемістив сесії в файлову систему «для простоти». Також налаштував PHP-FPM більше воркерів, бо графік CPU «не здавався високим». Це класичний крок: оптимізувати вимірювану метрику і ігнорувати ту, яку не вимірювали.

За кілька днів сервер почав показувати переривчасті критичні помилки. Не постійно — гірше. Користувачі оновлювали сторінку, і іноді вона працювала. Логи містили змішані повідомлення: «Allowed memory size exhausted», «failed to open stream» і періодичні таймаути бази даних. Спочатку звинувачували WordPress, потім MySQL, потім мережу — бо це емоційно задовольняє.

Коренева причина: вичерпання inode і конкуренція диска через кеш, що писав тисячі маленьких файлів, разом із занадто великою кількістю PHP-FPM воркерів, що бились за IO. Коли FS не могла створити нові файли кешу/сесій, виклики PHP падали в несподіваних місцях, а плагіни погано обробляли помилки — вели до fatals.

Вони відкотили файловий кеш, перейшли на нормальний in-memory кеш і зменшили кількість PHP-FPM воркерів до рівня, що відповідає IO-можливостям. Продуктивність покращилася і «випадкові» критичні помилки зникли. Мораль: вузьке місце, яке ви ігноруєте, обере час, щоб вас навчити.

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

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

Одного вечора контент-редактор встановив плагін на staging для попереднього перегляду функції. Добре. Але рутіна деінсталяції у вендора плагіна була багована і залишила MU-плагін у wp-content/mu-plugins. Той файл потрапив у релізний артефакт і був задеплойнений у продакшен під час вікна обслуговування.

Сайт одразу потрапив у критичну помилку через відсутню залежність, яку MU-плагін припускав. Інженер на чергуванні дотримався рубрики: підтвердив фатал у логах, вимкнув MU-плагін переміщенням файлу, перезавантажив PHP-FPM, перевірив 200. Сервіс швидко відновили.

Потім нудна практика принесла користь: вони задеплоїли виправлення і використали утиліту diff, щоб точно показати, що змінилося. Ніяких містерій, ніяких «можливо це була база». Звіт по інциденту був коротким, фактичним і корисним — і це найкращий варіант.

Поширені помилки: симптом → корінна причина → виправлення

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

1) Симптом: «Критична помилка» тільки на певних сторінках

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

Виправлення: Вдарте по тій URL, що падає, одночасно підглядаючи логи. Вимкніть компонент плагіна/теми, що підключається до цього маршруту. Якщо це контент (шорткод), відредагуйте допис у базі або через WP-CLI, щоб тимчасово видалити шорткод.

2) Симптом: Сайт лежить, wp-admin теж недоступний, WP-CLI падає з фаталом

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

Виправлення: Перевірте wp-content/mu-plugins. Перемістіть файли по одному. Також перевірте advanced-cache.php і object-cache.php в wp-content (drop-in плагіни).

3) Симптом: Ви увімкнули WP_DEBUG і тепер відвідувачі бачать сирі помилки

Корінна причина: WP_DEBUG_DISPLAY або PHP display_errors увімкнено.

Виправлення: Встановіть define('WP_DEBUG_DISPLAY', false); і переконайтеся, що в конфігах PHP display_errors=Off. Перезавантажте PHP-FPM. Перевірте тестовий запит; помилки мають йти лише в лог.

4) Симптом: Ви «пофіксили» плагін, а помилка не зникла

Корінна причина: OPcache видає старий байткод, або ви редагували неправильний сервер (мульти-нод, неправильний контейнер, неправильний том).

Виправлення: Reload/restart PHP-FPM, підтвердьте вміст файлу на хості, що обслуговує трафік, і перевірте налаштування балансувальника. Не довіряйте лише SSH-промту; перевіряйте.

5) Симптом: Критична помилка після міграції хосту

Корінна причина: Відсутні PHP-розширення (mbstring, intl), неправильні права файлів/власність або несумісна версія PHP.

Виправлення: Порівняйте список модулів і версію PHP; виправте власність під веб-користувача; переконайтеся, що WordPress може читати/писати потрібні директорії (wp-content/uploads, каталоги кешу).

6) Симптом: «Allowed memory size exhausted» у логах

Корінна причина: Низький memory_limit у PHP, runaway-плагін або величезна кількість автозавантажених опцій у базі.

Виправлення: Підвищіть пам’ять до розумного рівня (256M часто підходить), потім профілюйте. Використайте WP-CLI, щоб перевірити autoload-опції і обрізати тих, хто насідає.

7) Симптом: debug.log швидко росте і заповнює диск

Корінна причина: WP_DEBUG залишений увімкненим; плагін постійно викидає notices/warnings; немає ротації логів.

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

8) Симптом: Критична помилка з’являється, зникає, потім повертається

Корінна причина: Один вузол у кластера має інший набір плагінів, інший файловий простір або іншу версію PHP.

Виправлення: Порівняйте вузли: каталоги плагінів, контрольні суми, версії PHP-FPM, змонтовані томи. Робіть деплої іммутабельними та узгодженими.

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

Чекліст негайного відновлення (ціль: до 15 хвилин)

Підтвердіть код статусу і масштаб: одна URL, всі URL, адмін також.
Хвостіть Nginx/Apache error log та PHP-FPM log за точною фатальною помилкою.
Якщо логи мовчать: увімкніть WP_DEBUG з WP_DEBUG_LOG і WP_DEBUG_DISPLAY=false.
Визначте, чи фатал посилається на плагін або тему.
Вимкніть підозрілий плагін/тему (WP-CLI переважно; перейменування директорії/файлу при потребі).
Перезавантажте PHP-FPM, щоб очистити OPcache, якщо поведінка не відповідає файловій системі.
Повторно перевірте: curl на 200, потім відкрийте головну в браузері, потім кілька ключових маршрутів (вхід, checkout, контактна форма).
Зафіксуйте стек-трейс і запишіть зміну, що спричинила інцидент.
Вимкніть WP_DEBUG (або принаймні припиніть детальне логування), коли маєте доказ.

Чекліст RСA і уникнення повтору (ціль: того ж дня)

Порівняйте версії: WordPress core, PHP-FPM, активні плагіни, тема.
Перегляньте недавні зміни: автооновлення, деплои, зміни конфігурації, міграції хостів.
Відтворіть у staging з тими ж версіями.
Визначте стратегію: оновити core/PHP, закріпити версії плагінів або замінити плагін.
Додайте захисний механізм: відключіть автооновлення для ризикових плагінів або дозволяйте оновлення лише через CI.
Впровадьте ротацію логів для WordPress debug і веб/PHP логів.
Додайте smoke-test: перевірка головної + кілька ключових маршрутів після деплоя.

Мінімальна безпечна конфігурація WP_DEBUG — чекліст

WP_DEBUG true лише під час діагностики.
WP_DEBUG_LOG у захищений шлях.
WP_DEBUG_DISPLAY false.
PHP display_errors off.
Контроль доступу, щоб лог-файли не були доступні з вебу.

Одна операційна цитата, яку варто мати під рукою

Парафразована ідея (атрибутовано W. Edwards Deming): Без даних ви просто ще одна людина з думкою.

WP_DEBUG, якщо його використовувати правильно, перетворює простій з «думок» на «ось точний рядок, що зламався».

FAQ

1) Чому WordPress показує «Сталася критична помилка» замість реальної помилки?

Тому що показ сирих помилок PHP користувачам — ризик для безпеки та приватності. WordPress ховає деталі і очікує, що ви подивитесь у серверні логи або ввімкнете безпечне логування.

2) Чи буде увімкнення WP_DEBUG гальмувати мій сайт?

Може. Це збільшує кількість логів і виявляє notice, які деякі плагіни генерують постійно. Використовуйте його коротко, логуючи у файл, потім вимикайте. Для довготривалої видимості використовуйте структуроване логування і моніторинг.

3) Чи безпечний `wp-content/debug.log`?

Іноді. Залежить від правил вебсервера. Якщо сервер може обслуговувати файли з wp-content напряму (поширено), є ризик витоку лога. Захищений шлях типу /var/log/wordpress безпечніший.

4) Я не можу зайти в wp-admin. Як відключити плагіни?

Використайте WP-CLI, якщо воно завантажується. Інакше перейменуйте каталог плагіна в wp-content/plugins або перемістіть файл з mu-plugins. WordPress пропустить те, чого не знайде.

5) Що робити, якщо відключення всіх плагінів не допомагає?

Перегляньте тему, MU-плагіни і drop-ins (object-cache.php, advanced-cache.php). Якщо і це не допомагає, перевірте контрольні суми core, версію/модулі PHP та стан файлової системи (диск/inode).

6) Як визначити, чи це проблема пам’яті PHP?

Ваші логи покажуть «Allowed memory size exhausted». Не гадуйте. Підтвердьте memory_limit через WP-CLI або phpinfo (обережно), підніміть його помірно, а потім шукайте плагін/тему, що споживає.

7) Чому помилка трапляється тільки іноді?

Перервні відмови зазвичай означають, що один вузол у кластері відрізняється, або ресурсна проблема періодична (cron, бекапи, перебудова кешу), або OPcache дає застарілий код на деяких воркерах.

8) Чи варто негайно відновлювати з бекапу?

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

9) Чи можна «полагодити» це перевстановленням WordPress?

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

10) Як запобігти цього класу відмов?

Припиніть вважати продакшен інтеграційним середовищем: фіксуйте версії, тестуйте оновлення у staging, деплойте через CI і тримайте процедуру відкату/відновлення, яку ви реально відпрацьовували.

Висновок: наступні кроки, щоб запобігти повторенню

«Сталася критична помилка» — WordPress каже вам: «PHP помер, будь ласка, прочитайте чеки». Ваш найшвидший шлях послідовний: перевірте серверні логи, увімкніть WP_DEBUG логування безпечно за потреби, ізолюйте проблемний плагін/тему, відновіть сервіс, а потім виправляйте невідповідність версій або баг у контрольованому порядку.

Зробіть наступне:

Вимкніть WP_DEBUG, якщо ви його ввімкнули, або принаймні припиніть детальне логування після отримання стек-трейсу.
Запишіть тригер: яке оновлення, який деплой, яка зміна конфігурації.
Зробіть staging схожим на production (версії, PHP-обробник, плагіни). Дрейф — це те, як ви опиняєтесь у світі відладки вигадок.
Додайте один автоматичний smoke-test після оновлень: головна + вхід + ключовий бізнес-маршрут. Дешево й ефективно.
Ротируйте логи і слідкуйте за диском/inode. Відмови через повний диск — не «містичні», просто принизливі.

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