Як відновити WordPress після fatal error без доступу до адмінки

Що означає fatal error у WordPress

Fatal error — це критична помилка PHP, через яку WordPress не може завершити виконання запиту. Причиною може бути несумісний плагін, помилка в темі, відсутній PHP-клас або функція, конфлікт між розширеннями, пошкоджений файл чи недостатня версія PHP.

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

Не повторюйте оновлення навмання та не видаляйте таблиці WordPress. Такі дії можуть приховати симптом, але не усунути причину й ускладнити відновлення.

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

Перший крок — перевірте Recovery Mode

У багатьох випадках WordPress надсилає адміністратору лист із повідомленням про критичну помилку та спеціальним посиланням Recovery Mode. Цей режим дає змогу увійти до адмінки, тимчасово призупинивши проблемний плагін або тему саме для вашої сесії. Інші відвідувачі при цьому можуть бачити окреме повідомлення про помилку.

Відкрийте поштову скриньку, яка вказана як адміністративна в налаштуваннях сайту, і знайдіть лист від WordPress. Перейдіть за посиланням у повідомленні, авторизуйтеся та перевірте, який компонент система визначила як проблемний.

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

• Посилання Recovery Mode може бути тимчасовим, тому використовуйте його невдовзі після отримання.
• Якщо листа немає, перевірте папку зі спамом і правильність поштової адреси адміністратора.
• Recovery Mode не виправляє код компонента — він лише допомагає отримати доступ і локалізувати проблему.

Відключення проблемного плагіна через WP-CLI

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

Параметри --skip-plugins і --skip-themes не дають WordPress завантажувати плагіни та тему під час виконання команди. Це особливо важливо, якщо помилка виникає ще на етапі запуску WordPress.

• Перевірте точний slug плагіна через список встановлених розширень.
• Після деактивації відкрийте сайт у приватному вікні та перевірте головну сторінку, кілька внутрішніх сторінок і /wp-admin.
• Якщо команда повертає помилку, збережіть її текст: він може вказати на проблему з PHP, правами доступу або самим WP-CLI.

wp plugin list --skip-plugins --skip-themes
wp plugin deactivate problematic-plugin --skip-plugins --skip-themes

Якщо проблема пов’язана з темою

Коли fatal error з’явився після зміни або оновлення теми, тимчасово активуйте стандартну тему, сумісну з вашою версією WordPress. У прикладі використано twentytwentyfour, але на сервері має бути встановлена саме та тема, яку ви вказуєте.

Якщо стандартної теми немає, її спочатку потрібно встановити з перевіреного джерела або відновити файли теми. Не копіюйте випадкову тему на робочий сайт без перевірки.

• Перед активацією переконайтеся, що потрібна стандартна тема присутня у wp-content/themes/.
• Перевірте сайт після перемикання: частина функцій і верстка кастомної теми може тимчасово зникнути.
• Не видаляйте проблемну тему, доки не збережено її файли та налаштування.

wp theme list --skip-plugins --skip-themes
wp theme activate twentytwentyfour --skip-plugins --skip-themes

Що робити, якщо WP-CLI також завершується з помилкою

Якщо WordPress падає ще до виконання команди WP-CLI, використайте файловий доступ через SSH, SFTP або файловий менеджер хостингу. Знайдіть каталог підозрілого плагіна в wp-content/plugins/ і тимчасово перейменуйте його, наприклад із problematic-plugin на problematic-plugin.disabled.

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

Якщо невідомо, який саме плагін спричинив збій, можна тимчасово перейменувати каталог plugins, наприклад на plugins.disabled. Це відключить усі плагіни. Потім поверніть назву каталогу та вмикайте розширення по одному, перевіряючи сайт після кожної активації.

• Не перейменовуйте або не видаляйте wp-content без резервної копії.
• Змінюйте назву, а не видаляйте каталог: так ви зможете швидко повернути файли.
• Якщо після відключення всіх плагінів помилка не зникає, перевіряйте тему, версію PHP та файли ядра.

cd /path/to/wordpress/wp-content/plugins/
mv problematic-plugin problematic-plugin.disabled

Діагностика: де шукати причину помилки

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

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

Для тимчасового журналювання у wp-config.php можна використати такі параметри. Не вмикайте показ помилок на робочому сайті для всіх відвідувачів: службова інформація може містити шляхи до файлів і деталі конфігурації.

• Після діагностики вимкніть WP_DEBUG або залиште журналювання лише за правилами безпеки вашого середовища.
• Не публікуйте debug.log у відкритому доступі та перевірте права на файл.
• Очистіть або архівуйте старі логи після збереження потрібних записів, щоб вони не займали весь дисковий простір.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Що перевірити на рівні сервера

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

Не змінюйте версію PHP наосліп на бойовому сайті. За можливості спочатку створіть копію або staging і перевірте сумісність ядра, теми та плагінів.

• Порівняйте поточну версію PHP з вимогами проблемного плагіна та теми.
• Перевірте ліміти memory_limit і max_execution_time, якщо помилка пов’язана з нестачею ресурсів.
• Переконайтеся, що після відновлення сайт не повертає помилки 500 або нескінченні редиректи.

Відновлення після того, як сайт знову запрацював

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

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

Після тестування оновіть проблемний компонент до виправленої версії або замініть його на підтримуване рішення. Застаріле розширення створює не лише ризик повторного fatal error, а й потенційну загрозу безпеці.

• Зробіть повну резервну копію перед повторною активацією.
• Тестуйте оновлення на staging, якщо сайт критичний для бізнесу.
• Ведіть список змін: це допоможе швидко визначити причину наступного збою.
• Не залишайте debug.log і службові повідомлення доступними публічно.