Відкриваєш свій сайт на WordPress, а замість сторінки бачиш сухе повідомлення: «На сайті виникла критична помилка» (англійською – There has been a critical error on this website). Іноді на екрані ще й порада переглянути пошту адміністратора. Спокійно: сайт зазвичай не зламаний «назавжди», а просто один із компонентів кинув фатальну помилку PHP. Розберемося, як знайти винуватця й повернути сайт до життя.

Що означає це повідомлення

Це дружня обгортка над звичайною фатальною помилкою PHP. WordPress перехоплює її, щоб відвідувач не бачив уривків коду, і показує загальну заглушку. А що саме зламалось, треба з'ясувати окремо. Типові причини:

  • оновлення або встановлення плаґіна, який конфліктує з іншим або з версією PHP;
  • помилка в темі чи в доданому коді у functions.php (кома, дужка, дубль функції);
  • на хостингу змінили версію PHP, а старий плаґін чи тема її не підтримують;
  • не вистачає пам'яті для PHP;
  • оновлення WordPress обірвалось і залишило частково замінені файли.

Спосіб 1. Скористатися листом із режимом відновлення

WordPress сам надсилає на адресу адміністратора лист із темою на кшталт «Проблема з сайтом». У ньому є:

  • назва плаґіна чи теми, що спричинили збій;
  • спеціальне посилання для входу в режим відновлення.

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

Спосіб 2. Вимкнути плаґіни вручну через FTP або файловий менеджер

Листа немає, а адмінка не відкривається? Заходь на хостинг через FTP або файловий менеджер у панелі хостингу.

  1. Перейди в папку wp-content.
  2. Перейменуй папку plugins на plugins-off. WordPress не знайде плаґінів і вимкне їх усі.
  3. Онови сторінку сайту. Якщо помилка зникла, винуватець серед плаґінів.
  4. Поверни назву plugins. У самій папці по одному перейменовуй підпапки плаґінів (додавай, наприклад, -off), поки сайт не запрацює. Так знайдеш конкретний плаґін.
  5. Заміни або видали його, зайди в адмінку й знову активуй потрібні плаґіни: після перейменування папки WordPress вимикає їх усі.

Нічого не видаляй без потреби. Перейменування повністю оборотне, а от стерта папка плаґіна може забрати його налаштування разом із собою (деякі плаґіни зберігають їх у базі, але не всі).

Спосіб 3. Якщо винна тема

Плаґіни вимкнені, а помилка лишилась? Подивись на тему. У папці wp-content/themes перейменуй папку активної теми, наприклад, my-theme на my-theme-off. WordPress спробує перемкнутись на одну зі стандартних тем, якщо така в тебе встановлена. Якщо жодної стандартної теми в папці немає, завантаж її з офіційного сайту й розпакуй у themes.

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

Спосіб 4. Увімкнути журнал і дізнатися причину точно

Замість вгадування краще прочитати, що саме каже PHP. У файлі wp-config.php у корені сайту, вище рядка «That's all, stop editing!», додай:

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

Оновиш сторінку з помилкою, і в файлі wp-content/debug.log з'явиться запис. У ньому буде назва файлу й номер рядка, наприклад, /wp-content/plugins/назва-плаґіна/файл.php on line 42. За шляхом одразу видно, хто винен. Коли розберешся, обов'язково вимкни налагодження (WP_DEBUG поверни на false) і видали debug.log, бо в ньому можуть бути чутливі шляхи. Загальніше про налаштування журналів у PHP я писав у статті як увімкнути показ помилок у PHP.

Спосіб 5. Перевірити пам'ять і версію PHP

У журналі трапляється рядок Allowed memory size of ... bytes exhausted. Це означає, що скрипту не вистачило пам'яті. Спробуй додати у wp-config.php:

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

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

Також перевір версію PHP у панелі хостингу. Помилка могла з'явитись одразу після її зміни. Тимчасово поверни попередню версію, і якщо сайт ожив, значить, якийсь із плаґінів чи тема застаріли. Оновлюй їх або шукай заміну.

Спосіб 6. Обірване оновлення ядра

Якщо помилка з'явилась під час оновлення самого WordPress, у корені сайту може лишитись файл .maintenance. Видали його через FTP (він прихований, тож увімкни показ прихованих файлів). Якщо це не допомогло, завантаж свіжий архів WordPress і замін файли wp-admin та wp-includes цілком, не чіпаючи wp-content і wp-config.php.

Як не потрапляти в цю ситуацію

  • Перед оновленнями роби резервну копію файлів і бази: навіть проста копія з панелі хостингу врятує день.
  • Не став багато плаґінів, особливо схожих за функціями. Про це я писав на прикладі Jetpack: часто один великий комбайн не потрібен.
  • Оновлюй плаґіни не всі разом, а по одному, щоб бачити, який зламав сайт.
  • Додавай свій код у дочірню тему або окремий плаґін, а не в «рідний» файл теми, який стирається при оновленні.
  • Тестуй зміни на локальній копії сайту або на тестовому піддомені.

Що далі

Після відновлення варто навести порядок із темою та кодом: загляни в розбір створення теми WordPress з нуля та статтю про роботу з базою через об'єкт wpdb, щоб розуміти, де саме міг зламатись код. Якщо тобі потрібна локальна копія сайту для безпечних експериментів, Laragon на Windows підніме її за кілька хвилин.

Більше про це – за позначками Помилки та коди помилок та Плагіни WordPress.

А що саме у тебе поклало сайт: плаґін, тема чи оновлення PHP? Напиши в коментарях 🙂