«На сайті виникла критична помилка»: що це означає і як це виправити

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

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

Що насправді відбувається

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

Саме тому ви бачите це замість старого білого екрана смерті. Це крок уперед, але водночас це означає, що діагностична інформація за замовчуванням прихована. Повідомлення існує у двох варіантах:

Що ви бачите	Де	Про що це говорить
«На сайті виникла критична помилка.»	Публічна частина, без входу в систему	Сталася фатальна помилка, жодних подробиць не показано
Той самий рядок плюс «Дізнайтеся більше про усунення несправностей WordPress»	Публічна частина або wp-admin	Та сама помилка, WordPress пропонує вам сторінку довідника
«…Перевірте поштову скриньку адміністратора сайту, щоб отримати інструкції.»	Публічна частина	Обробник вважає, що надіслав лист для відновлення

Третій варіант — найкорисніший. Він означає, що WordPress приписав збій конкретному плагіну або шаблону і спробував дати вам спосіб зайти всередину.

Крок 1: перевірте лист про режим відновлення

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

Лист містить довге посилання, яке закінчується приблизно на ?action=enter_recovery_mode. Відкривши його, ви потрапляєте в wp-admin у режимі відновлення, де проблемний плагін чи шаблон призупинено і позначено червоним сповіщенням угорі. Звідти його можна вимкнути звичайним способом.

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

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

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Крок 2: прочитайте справжню помилку

Саме цей крок перетворює зламаний сайт на п’ятихвилинний ремонт. Додайте ці рядки у wp-config.php, вище рядка, який просить припинити редагування:

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

WP_DEBUG_DISPLAY зі значенням false тут принципова річ — вона тримає помилку поза браузером, але дозволяє записати її на диск, тож ви не розкриваєте шляхи відвідувачам, поки шукаєте причину.

Перезавантажте зламану сторінку один раз, а потім відкрийте wp-content/debug.log. Останній запис виглядатиме приблизно так:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Шлях до файлу і є відповіддю. Якщо він веде у wp-content/plugins/, причина в цьому плагіні. Якщо у wp-content/themes/ — винен шаблон, і дуже часто це щось нещодавно вставлене у functions.php.

Якщо debug.log не з’явився, тека може бути недоступна для запису, або плагін безпеки переніс журнал в інше місце. Тоді зверніться до журналу помилок PHP вашого хостингу — майже в кожній панелі керування є розділ «Error Log» чи «Логи», і та сама фатальна помилка буде там разом із міткою часу.

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

Видаліть ці рядки налагодження, коли закінчите. Залишений увімкненим WP_DEBUG на робочому сайті забиває диск, а якщо WP_DEBUG_DISPLAY колись повернуть у true — почне публічно друкувати серверні шляхи.

Крок 3: поверніться в wp-admin

Якщо wp-admin теж не працює, а листа для відновлення не було, вимкніть усі плагіни на рівні файлової системи. Підключіться через SFTP (або файловий менеджер хостингу) і перейменуйте одну теку:

mv wp-content/plugins wp-content/plugins-off

WordPress не знаходить плагінів, тому вимикає їх усі, і доступ до адмінки майже завжди повертається. Далі:

1. Перейменуйте теку назад на plugins. Усе залишиться вимкненим — WordPress записав плагіни як неактивні.
2. Вмикайте плагіни по одному, щоразу відкриваючи публічну частину сайту.
3. Той, який повертає помилку, і є вашим винуватцем.

Якщо сайт залишається зламаним із усіма вимкненими плагінами, підозрюваний — шаблон. Перейменуйте теку активного шаблону в wp-content/themes/, і WordPress перемкнеться на стандартний шаблон, якщо він встановлений.

Три причини, які варто знати

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

Невідповідність версії PHP. Хостинги оновлюють PHP за графіком, іноді майже без попередження. Код, написаний під старіший PHP, на новій версії може взагалі не розбиратися. Характерна ознака: з вашого боку нічого не змінювалося, а зламалося все й одразу. Відкат PHP на одну мінорну версію в панелі хостингу — нормальний діагностичний крок, але сприймайте його як спосіб виграти час, а не як виправлення. Старі версії PHP більше не отримують патчів безпеки.

Вичерпання пам’яті. У журналі буде «Allowed memory size of X bytes exhausted». Підняти ліміт у wp-config.php — цілком розумно:

define( 'WP_MEMORY_LIMIT', '256M' );

Але будьте чесні щодо того, що це дає: ви прибираєте стелю, а не усуваєте те, що з’їдає 256 МБ на рендеринг однієї сторінки. Якщо ліміт доводиться піднімати знову і знову, справжня проблема в чомусь іншому — зазвичай в імпорті, конструкторі сторінок або кепсько написаному запиті.

Поради, які можна спокійно проігнорувати

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

«Перевстановіть ядро WordPress». Файли ядра рідко бувають причиною, а їх заміна з’їдає час, який можна витратити на читання одного рядка журналу.

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

«Очистіть кеш». Фатальна помилка стається в PHP ще до того, як плагін кешування встигає щось віддати. Якщо ж віддається закешована копія сторінки з помилкою, очищення допоможе після усунення причини — але ніколи замість нього.

Досі не виходить?

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