Оновлення теми WordPress може спричинити білий екран, помилку 500, зникнення стилів, проблеми з меню або повну недоступність адміністративної панелі. Найчастіше причина пов’язана з конфліктом між новою версією теми, плагінами, версією PHP або власними змінами в коді.
Якщо Сайт перестав працювати після оновлення WordPress: що робити, не поспішайте повторно оновлювати тему або видаляти файли навмання. Спершу зафіксуйте симптоми, створіть резервну копію доступних даних і лише після цього переходьте до відкату.
Ознаки конфлікту теми
Конфлікт теми зазвичай проявляється безпосередньо після оновлення. Серед типових симптомів:
- білий екран замість сайту або панелі керування;
- повідомлення «Виникла критична помилка на цьому сайті»;
- помилка сервера 500 або циклічне перенаправлення;
- порушена верстка, відсутні стилі, зображення чи меню;
- помилки JavaScript у браузері та непрацюючі форми;
- конфлікт із конструктором сторінок, плагіном кешування або модулем безпеки;
- зникнення окремих функцій, віджетів чи налаштувань кастомізації.
Перевірте, чи з’явилася проблема саме після оновлення теми, а також чи однаково вона відтворюється для звичайного відвідувача й адміністратора. Варто переглянути журнал помилок хостингу та активувати діагностику WordPress, але не виводити технічні повідомлення на доступний усім сайт.
Для цього в wp-config.php можна тимчасово використати налаштування:
define('WP_DEBUG', true); define('WPDEBUGLOG', true); define('WPDEBUGDISPLAY', false);
Файл журналу зазвичай створюється в каталозі wp-content. Він може показати назву файлу або функції, через яку виникає збій. Перед редагуванням конфігурації зробіть резервну копію файлу. Після діагностики налагодження потрібно вимкнути, оскільки журнал може містити технічні дані, а помилки не повинні бути доступними відвідувачам.
Режим відновлення WordPress
Якщо WordPress виявляє критичну помилку, він може надіслати адміністратору спеціальне посилання для входу в режим відновлення. У цьому режимі проблемний компонент тимчасово призупиняється, завдяки чому можна увійти до адміністративної панелі та деактивувати тему або конфліктний плагін.
Після входу перегляньте повідомлення про помилку й запишіть назву теми, плагіна, файлу та рядка коду, які згадуються в діагностиці. Не видаляйте компонент одразу, якщо в ньому зберігаються налаштування або дані сайту.
Якщо листа для режиму відновлення немає або панель недоступна, тему можна тимчасово вимкнути через файловий менеджер хостингу, FTP або SSH. Для цього зазвичай перейменовують каталог активної теми в wp-content/themes. WordPress спробує перейти на одну зі стандартних тем.
Перед такими діями бажано зберегти копію всієї файлової системи та бази даних. Неправильне перейменування, видалення або заміна файлів може ускладнити подальше відновлення, особливо якщо тема містить власні шаблони, дочірню тему або нестандартні інтеграції.
Відкат версії
Відкат означає повернення до попередньої версії теми, яка працювала до оновлення. Найбезпечніше виконувати його з резервної копії або через функцію хостингу, що дозволяє відновити конкретні файли. Якщо доступна лише копія всього сайту, спочатку бажано розгорнути її на тестовому середовищі та перевірити результат.
- З’ясуйте точну версію теми, що була встановлена до збою.
- Зробіть окрему копію поточних файлів теми та бази даних, навіть якщо сайт уже не працює.
- Перевірте, чи не зберігаються зміни безпосередньо у файлах основної теми.
- Замініть файли теми на попередню версію з надійного джерела або резервної копії.
- Очистьте кеш WordPress, плагіна кешування, CDN і браузера.
- Перевірте роботу головної сторінки, адміністративної панелі та ключових функцій.
Не варто завантажувати стару тему з випадкових сайтів. Такі архіви можуть містити шкідливий код, змінені файли або неповний комплект шаблонів. Також відкат теми не завжди повертає сумісність із базою даних: оновлення могло змінити структуру налаштувань, а плагіни могли вже перейти на новіший формат.
Якщо помилка зберігається після повернення попередньої версії, причина може бути не лише в темі. Перевірте версію PHP, активні плагіни, права доступу до файлів, ліміти пам’яті та серверний журнал.
Збереження налаштувань
Перед відкатом потрібно з’ясувати, де саме зберігаються налаштування сайту. Частина параметрів теми міститься в базі даних WordPress, а частина може бути записана у файлах самої теми або дочірньої теми.
- Експортуйте налаштування кастомайзера, якщо тема підтримує таку можливість.
- Збережіть CSS із розділу «Додаткові стилі».
- Скопіюйте файли дочірньої теми та власні шаблони.
- Зафіксуйте віджети, меню, налаштування шапки, підвалу й головної сторінки.
- Зробіть резервну копію бази даних перед змінами.
- Збережіть медіафайли та конфігурацію інтеграцій із платіжними системами, CRM і поштовими сервісами.
Не редагуйте базу даних вручну без розуміння структури таблиць і залежностей між параметрами. Видалення або заміна записів може призвести до втрати налаштувань, зламу серіалізованих даних чи нових помилок у панелі керування. Якщо резервна копія неповна, спершу потрібно оцінити, які дані реально можна зберегти.
Для майбутніх оновлень краще використовувати дочірню тему, а не змінювати файли основної. У такому разі оновлення зазвичай не перезаписує власні шаблони та стилі. Водночас дочірня тема не усуває проблем сумісності, тому перед оновленням усе одно потрібні резервна копія й тестування.
Повторне тестування оновлення
Не встановлюйте нову версію теми повторно одразу після відкату. Спочатку перевірте сайт у стабільному стані та переконайтеся, що резервна копія справді створюється й може бути відновлена.
Повторне тестування бажано проводити на копії сайту або staging-середовищі. Там можна оновити тему, перевірити сумісність із поточною версією WordPress, PHP і плагінами, а також переглянути журнали помилок без ризику зупинити робочий сайт.
- Створіть копію файлів і бази даних.
- Перевірте сумісність теми з версіями WordPress і PHP.
- Оновіть тестову копію та зафіксуйте всі повідомлення про помилки.
- Перевірте авторизацію, форми, пошук, кошик, оплату, мобільну версію та швидкість завантаження.
- Переконайтеся, що не з’явилися помилки в консолі браузера та серверному журналі.
- Лише після успішної перевірки заплануйте оновлення робочого сайту.
Якщо staging-середовища немає, оновлення краще виконувати в період найменшої відвідуваності та мати підготовлений план повернення. Власнику сайту не варто самостійно змінювати файли, базу даних або версію PHP, якщо помилка повторюється, відсутній доступ до резервних копій або сайт використовується для приймання замовлень.
Спеціаліст може окремо перевірити сумісність теми й плагінів, відновити доступ, проаналізувати журнали, безпечно виконати відкат і підготувати контрольоване повторне оновлення. Результат залежить від стану файлів, бази даних, резервних копій і причин збою, тому точний обсяг робіт визначається після діагностики.
Якщо відкат теми не повертає сайт до стабільної роботи або разом із дизайном зникли важливі функції, потрібне системне відновлення сайтів після невдалого оновлення. Воно починається зі збереження поточного стану, перевірки сумісності теми, плагінів і PHP та лише потім переходить до виправлення конфлікту.