WordPress не працює після переходу на PHP 8.3 або 8.4: що робити

Перехід на PHP 8.3 або 8.4 може покращити продуктивність і безпеку сайту, але водночас спричинити помилки сумісності. Найчастіше після зміни версії з’являється білий екран, повідомлення «There has been a critical error on this website», помилки 500, проблеми з адмінпанеллю або некоректна робота окремих функцій.

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

Як перевірити сумісність із новою версією PHP

Спочатку потрібно з’ясувати, яка саме версія PHP активна на сервері та коли почалися проблеми. Цю інформацію можна перевірити в панелі хостингу, у розділі налаштувань PHP або в WordPress за шляхом «Інструменти» → «Стан сайту» → «Інформація».

Далі перевірте вимоги до сумісності для всіх основних компонентів:

• версії WordPress і вимоги до PHP, зазначені в офіційній документації;
• плагіни, особливо ті, що давно не оновлювалися;
• активну тему та дочірню тему;
• модулі PHP, необхідні для роботи сайту;
• власні фрагменти коду у файлах теми, плагінах або в functions.php.

Сам факт того, що плагін працював на PHP 7.4 або 8.1, не означає його сумісність із PHP 8.3 чи 8.4. У нових версіях PHP могли змінитися правила обробки типів даних, аргументів функцій, динамічних властивостей і застарілих конструкцій.

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

Де знайти фатальні помилки

Повідомлення на екрані часто містить лише загальний опис проблеми. Для точного пошуку причини потрібен журнал помилок.

Перевірити його можна в кількох місцях:

• у панелі хостингу в розділі Errors, «Журнали» або «Логи»;
• у файлі error_log у корені сайту або в каталозі конкретного домену;
• у журналі PHP-FPM або вебсервера, якщо хостинг надає до нього доступ;
• у журналі налагодження WordPress, якщо його було увімкнено заздалегідь.

Для тимчасового налагодження у файлі wp-config.php можуть використовуватися такі параметри:

define('WP_DEBUG', true);

define('WPDEBUGLOG', true);
define('WPDEBUGDISPLAY', false);

Журнал зазвичай записується до файлу wp-content/debug.log. Показувати технічні помилки відвідувачам не рекомендується, оскільки вони можуть містити шляхи до файлів, назви таблиць або інші службові дані. Після завершення діагностики налагодження слід вимкнути, а журнал — захистити або видалити, якщо в ньому більше немає потреби.

Звертайте увагу на рядки з позначками PHP Fatal error, Uncaught TypeError, Deprecated та Warning. Не кожне попередження зупиняє сайт, але фатальна помилка зазвичай містить назву файлу, номер рядка та шлях до плагіна або теми, де виникла проблема.

Як визначити застарілий плагін або тему

Найімовірніший підозрюваний — компонент, який давно не оновлювався або не має заявленої підтримки PHP 8.3 чи 8.4. У списку плагінів подивіться дату останнього оновлення, сумісність із поточною версією WordPress і повідомлення розробника. Аналогічно перевірте активну тему та її дочірню тему.

Зіставте дані з журналу помилок. Якщо в ньому згадується каталог wp-content/plugins/назва-плагіна, спочатку перевіряйте цей плагін. Якщо вказано wp-content/themes/назва-теми, проблема може бути в темі або в її додаткових файлах.

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

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

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

Безпечний відкат і поетапне оновлення

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

Перед відкатом:

1. збережіть повну копію файлів сайту та бази даних;
2. зафіксуйте поточну версію PHP та перелік активних плагінів;
3. завантажте або збережіть журнали помилок;
4. переконайтеся, що маєте доступ до панелі хостингу, FTP або SSH;
5. повідомте відповідальним працівникам про можливий короткочасний простій.

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

Оптимальний процес — перевірити оновлення на копії сайту, переконатися в коректній роботі, а потім перенести підтверджені зміни на робочий сайт. Для складних проєктів варто окремо перевіряти інтеграції з оплатою, CRM, поштовими сервісами, системами доставки та зовнішніми API.

Коли потрібне виправлення коду

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

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

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

Спеціаліст потрібен, якщо недоступні і сайт, і адмінпанель, у журналі немає зрозумілого пояснення, помилки виникають у базі даних або сервері, потрібне ручне редагування коду, а також коли сайт обробляє платежі чи персональні дані. У такій ситуації спочатку створюють копію та ізольовану тестову середу, потім аналізують журнали, сумісність компонентів і конфігурацію сервера. Лише після цього визначають безпечний спосіб відновлення роботи після переходу на PHP 8.3 або 8.4.