Зміна версії PHP часто виконується для підвищення безпеки, швидкодії та сумісності із сучасними компонентами сайту. Проте після такого переходу сайт може перестати відкриватися, показувати білий екран, повертати помилку 500 або працювати частково: наприклад, головна сторінка доступна, а вхід до адміністративної панелі — ні.
Найчастіше причина полягає не в самій новій версії PHP, а в тому, що тема, плагін або власний код сайту використовує застарілі функції. До відновлення роботи важливо не вносити хаотичні зміни. Якщо доступ до файлів і бази даних ще є, спочатку створіть резервну копію. Деякі виправлення можуть призвести до втрати даних або ускладнити подальшу діагностику.
Якщо сайт уже недоступний і ви не впевнені, як безпечно діяти, корисно ознайомитися з матеріалом Як врятувати сайт після невдалого оновлення PHP.
Несумісність коду з PHP
Після переходу на новішу версію PHP сервер починає суворіше обробляти застарілий або некоректний код. Це може проявлятися такими симптомами:
- білий екран замість сторінки;
- повідомлення «500 Internal Server Error»;
- помилки про невизначені функції, класи або методи;
- зникнення окремих блоків, форм чи меню;
- неможливість увійти до WordPress;
- циклічне перенаправлення або помилки під час виконання запитів.
Джерелом проблеми може бути плагін, тема, фрагмент коду у файлі functions.php, самописний модуль або застаріла бібліотека. Іноді несумісність виникає через різницю між версіями PHP: код, який працював на PHP 7.4, не обов’язково коректно працює на PHP 8.1 чи 8.2.
Не варто одразу змінювати багато налаштувань. Спочатку потрібно зафіксувати симптоми, перевірити доступ до панелі хостингу та з’ясувати, чи працюють файли, база даних і сам вебсервер.
Перевірка журналу помилок
Найточніше джерело інформації про причину збою — журнали сервера та PHP. Їх можна знайти в панелі хостингу, у розділі статистики або логів, а іноді — у файлах на сервері. Для WordPress додатково можна ввімкнути журналювання помилок у файлі wp-config.php, попередньо створивши резервну копію.
Типовий запис у журналі містить шлях до проблемного файлу, номер рядка та опис помилки. Особливу увагу слід звернути на повідомлення:
Fatal error— критична помилка, через яку виконання PHP припинилося;Call to undefined function— виклик функції, якої немає у поточному середовищі;Class not found— відсутній клас або необхідна бібліотека;Deprecated— застарілий код, який може стати причиною збоїв залежно від налаштувань сервера;Memory exhausted— перевищення доступного ліміту пам’яті PHP.
Якщо в журналі вказано файл конкретного плагіна або теми, це ще не завжди означає, що компонент потрібно видалити. Причиною може бути конфлікт із версією WordPress, іншим розширенням або налаштуваннями сервера. Після діагностики важливо зберегти копію журналу, оскільки деякі хостинги автоматично очищають старі записи.
Тимчасове повернення версії
Якщо сайт критично важливий для роботи бізнесу, тимчасове повернення на попередню версію PHP може відновити доступ і дати час на виправлення. Зазвичай це робиться в панелі керування хостингом або через звернення до технічної підтримки.
Такий крок не є остаточним ремонтом. Стара версія PHP може не отримувати актуальних оновлень безпеки, а хостинг може припинити її підтримку. Тому її варто використовувати лише як тимчасовий захід для діагностики та підготовки сумісного оновлення.
- Перевірте, чи є актуальна копія файлів і бази даних.
- Зафіксуйте поточну та попередню версію PHP.
- Збережіть записи з журналу помилок.
- Поверніть попередню версію PHP через панель хостингу.
- Перевірте головну сторінку, адміністративну панель, форми, кошик і ключові бізнес-функції.
Якщо навіть після повернення версії сайт не запрацював, проблема може бути пов’язана з пошкодженими файлами, базою даних, конфігурацією вебсервера, правами доступу або шкідливим кодом. У такій ситуації повторні зміни без резервної копії підвищують ризик втрати даних.
Оновлення теми й плагінів
Після тимчасового відновлення доступу потрібно визначити компонент, який не підтримує нову версію PHP. Почніть із перевірки оновлень WordPress, активної теми та всіх плагінів. Оновлення слід виконувати не наосліп, а після створення резервної копії та перевірки сумісності.
Якщо адміністративна панель не відкривається, проблемний плагін можна тимчасово вимкнути через файловий менеджер або базу даних. Наприклад, перейменування каталогу плагіна може деактивувати його, але перед цим необхідно зберегти резервну копію файлів. Видаляти компонент одразу не варто: у ньому можуть зберігатися налаштування, медіафайли або дані, потрібні для подальшого відновлення.
Окремо перевірте:
- дату останнього оновлення плагіна та теми;
- заявлену підтримку потрібної версії PHP;
- наявність конфліктів між компонентами;
- помилки у власному коді теми або дочірньої теми;
- ліміти пам’яті, час виконання скриптів і необхідні розширення PHP.
Якщо компонент давно не оновлювався, безпечнішим рішенням може бути його заміна, а не примусове виправлення окремих файлів. Ручне редагування файлів без розуміння логіки системи часто призводить до нових помилок і ускладнює подальше оновлення.
Безпечний повторний перехід
Повторний перехід на нову версію PHP бажано виконувати поетапно. Спершу підготуйте резервну копію файлів і бази даних, перевірте її працездатність та переконайтеся, що маєте доступ до панелі хостингу. Для важливого сайту краще спочатку протестувати зміни на копії або тестовому середовищі.
- Оновіть WordPress, тему та плагіни до сумісних версій.
- Перевірте сайт на тестовій копії, якщо хостинг це дозволяє.
- Виправте помилки, які з’являються в журналі PHP.
- Перемкніть PHP на нову версію у період мінімального навантаження.
- Перевірте сайт з боку відвідувача та адміністратора.
- Протестуйте форми, оплату, авторизацію, пошук, кошик, інтеграції та фонові завдання.
Після переходу не вимикайте журналювання помилок назавжди без потреби, але й не залишайте детальні повідомлення доступними відвідувачам. На робочому сайті помилки мають записуватися у внутрішній журнал, а не виводитися на екран.
Спеціаліст потрібен, якщо немає доступу до хостингу або бази даних, помилка повторюється після відкату PHP, пошкоджені файли, сайт заражений вірусом або на ньому працюють платежі та інші критичні інтеграції. У таких випадках правильна діагностика безпечніша за багаторазові спроби змінити версію PHP навмання.