Після оновлення теми WordPress сайт може перестати відкриватися, показувати білий екран або повідомлення на кшталт «There has been a critical error on this website». Найчастіше причина пов’язана з конфліктом коду теми, плагіна, версії PHP або змінами у файлах дочірньої теми.
Не варто одразу повторно запускати оновлення чи видаляти файли навмання. Якщо доступ до сайту ще зберігається, спершу створіть резервну копію файлів і бази даних. Якщо сайт повністю недоступний, перевірте, чи є актуальна копія в хостингу або системі резервного копіювання. Відновлення без діагностики може призвести до втрати змін, налаштувань або контенту.
Додаткові типові причини та підходи до усунення проблем описані в матеріалі Ремонт сайту на WordPress: найчастіші проблеми та способи їх вирішення.
Читання повідомлення про помилку
Фатальна помилка зазвичай містить важливу технічну інформацію: назву файлу, номер рядка та компонент, у якому виник збій. Наприклад, у повідомленні може згадуватися файл теми, функція, клас або конкретний плагін.
- Назва файлу теми вказує, що проблема може бути в шаблоні, функціях або додатковому коді теми.
- Згадка про плагін часто свідчить про конфлікт між оновленою темою та розширенням.
- Помилка синтаксису може виникнути через пошкоджений файл, несумісний фрагмент коду або невдале ручне редагування.
- Повідомлення про невідому функцію чи клас іноді пов’язане з несумісною версією PHP або відсутньою залежністю.
Якщо WordPress показує посилання на режим відновлення, перевірте електронну пошту адміністратора сайту. У листі може бути тимчасове посилання для входу та назва компонента, який спричинив критичну помилку.
За відсутності зрозумілого повідомлення перегляньте журнали помилок у панелі хостингу або активуйте журналювання WordPress. Робити це краще на копії чи після створення резервної копії, оскільки журнали можуть містити технічні дані про структуру сайту та шляхи до файлів.
Перемикання на стандартну тему
Найбезпечніший спосіб перевірити, чи винна саме тема, — тимчасово активувати стандартну тему WordPress, наприклад одну з тем Twenty Twenty. Якщо після перемикання сайт починає працювати, проблема, імовірно, пов’язана з оновленою темою або її взаємодією з іншими компонентами.
Якщо доступна адміністративна панель:
- Відкрийте розділ «Вигляд» → «Теми».
- Активуйте встановлену стандартну тему.
- Перевірте головну сторінку, кілька внутрішніх сторінок, форми та адміністративну панель.
- Зафіксуйте, які функції відновилися, а які залишилися недоступними.
Коли вхід до адмінпанелі неможливий, тему можна перемкнути через файловий менеджер хостингу або FTP. Перед зміною назв каталогів потрібно зробити резервну копію. Зазвичай тимчасове перейменування папки активної теми змушує WordPress перейти до іншої доступної теми, але результат залежить від конфігурації сайту.
Не видаляйте активну тему одразу. Вона може містити налаштування, шаблони, медіазапити або важливі зміни, яких немає в резервній копії.
Відкат змін
Якщо помилка з’явилася одразу після оновлення, доцільно розглянути відкат до попередньої версії. Найкраще робити це не на робочому сайті, а на копії або тестовому середовищі. Відкат може усунути несумісність, але не вирішить проблему, якщо одночасно змінилися версія PHP, плагіни, база даних або користувацький код.
Можливі джерела попередньої версії:
- резервна копія хостингу;
- архів теми, збережений перед оновленням;
- репозиторій розробника теми;
- система керування версіями, якщо сайт підключений до Git.
Перед відкатом збережіть поточний стан файлів і бази даних. Не завжди достатньо замінити лише папку теми: оновлення могло змінити налаштування, віджети, структуру даних або пов’язані плагіни. Після відновлення перевірте журнал помилок і переконайтеся, що сайт не залишився на застарілій та вразливій версії.
Якщо резервна копія неповна або невідомо, які саме файли були змінені, ручний відкат може погіршити ситуацію. У такому разі безпечніше спочатку зняти копію поточного стану та провести порівняння файлів.
Перевірка дочірньої теми
Дочірня тема дає змогу зберігати власні зміни окремо від батьківської теми. Проте після оновлення батьківської теми старі перевизначення шаблонів або функцій можуть стати несумісними.
Перевірте:
- чи не містить дочірня тема застарілих копій файлів шаблонів;
- чи немає помилок у файлі
functions.php; - чи відповідають підключені стилі та скрипти новій версії батьківської теми;
- чи не дублюються функції або класи, які тепер оголошує батьківська тема;
- чи не використовує код дочірньої теми функції, видалені або змінені в новій версії.
Для діагностики можна тимчасово активувати батьківську тему без дочірніх змін. Якщо сайт запрацює, потрібно поетапно перевірити код дочірньої теми, а не просто копіювати всі файли назад.
Особливу увагу приділіть файлам шаблонів, які WordPress або сама тема позначає як застарілі. Їх слід адаптувати до нової структури, але перед редагуванням обов’язково збережіть копію. Помилка в PHP-коді може знову заблокувати сайт.
Підготовка безпечного оновлення
Щоб зменшити ризик повторної фатальної помилки, оновлення теми варто проводити за контрольованою послідовністю:
- Створіть окремі резервні копії файлів і бази даних та перевірте, чи вони справді доступні для відновлення.
- Зафіксуйте поточні версії WordPress, PHP, теми та плагінів.
- Перевірте вимоги нової версії теми та сумісність із вашою версією PHP.
- Оновіть тему спочатку на тестовій копії сайту.
- Перевірте головну сторінку, типові записи, форми, пошук, кошик або особистий кабінет, якщо вони використовуються.
- Перегляньте журнали помилок і консоль браузера.
- Лише після перевірки виконайте оновлення на робочому сайті у період мінімального навантаження.
Не рекомендується одночасно оновлювати тему, WordPress, PHP і десятки плагінів: у разі збою буде складно визначити джерело проблеми. Краще змінювати компоненти по черзі та фіксувати результат після кожного кроку.
Допомога спеціаліста потрібна, якщо немає доступу до адмінпанелі й хостингу, відсутня перевірена резервна копія, помилка пов’язана з базою даних або сервером, сайт містить ознаки зараження, чи після перемикання теми проблема не зникає. У таких випадках спершу проводять діагностику, визначають безпечний спосіб відновлення та лише потім змінюють файли або базу даних.