Кінець підтримки PHP 8.2: що робити із сайтом на WordPress

Хостинг надіслав листа про зміну версій PHP, в адмінці WordPress висить жовте повідомлення «оновіть PHP», а підрядник каже: «усе працює, не чіпайте». Причина в усіх випадках одна: PHP 8.1 без підтримки з 1 січня 2026 року, кінець підтримки PHP 8.2 настає 31 грудня 2026-го, а слідом за мовою підвищують вимоги WordPress і WooCommerce. У статті: чим це загрожує сайту, як за дві хвилини дізнатися свою версію PHP і в якому порядку переходити на PHP 8.3, щоб сайт не впав.

Що означає «PHP без підтримки»

PHP — мова, якою написані WordPress і більшість інших систем керування сайтом. Код сайту виконує інтерпретатор PHP на сервері хостингу, і в кожної його версії обмежений термін служби. Близько двох років після виходу триває активна підтримка: розробники виправляють помилки та вразливості й регулярно випускають оновлення. Ще два роки версія отримує лише виправлення безпеки, причому тільки критичні й за потреби. Потім настає кінець життя (end of life): оновлень немає, php.net радить переходити на нову версію якомога швидше.

Календар на 8 листопада 2026 року за офіційною сторінкою підтримуваних версій PHP:

У PHP 8.2 звичайні помилки не виправляють уже майже два роки, а з 1 січня 2027-го перестануть закривати і вразливості. Гілка 8.1 закрита: останній випуск — 8.1.34, нових не буде. Різницю видно на прикладі жовтня 2026 року: PHP випустив 8.2.35, 8.3.36, 8.4.27 і 8.5.12 з виправленнями безпеки, а гілка 8.1 нічого не отримала (докладніше — у статті PHP2Shell: критичні вразливості PHP).

За статистикою wordpress.org на 8 листопада 2026 року близько 32 % інсталяцій WordPress, які надсилають туди дані, працюють на PHP нижче 8.2, ще майже 23 % — на PHP 8.2. Без оновлення до січня понад половина таких інсталяцій опиниться на PHP без підтримки.

Чим загрожує старий PHP

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

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

CMS перестають оновлюватися на старому PHP. Це вже відбувається:

• WordPress 7.0 (травень 2026) підняв мінімальну версію PHP до 7.4. Сайти на PHP 7.2 і 7.3 залишилися на гілці 6.9 і нових версій ядра не отримають.
• WooCommerce 11.6, запланований на лютий 2027 року, вимагатиме PHP 8.1 або новішу. Останній випуск для PHP 7.4 і 8.0 — 11.5; у нього переноситимуть лише виправлення вразливостей з оцінкою CVSS 9 і вище.

Коли оновлення CMS і плагінів перестають установлюватися, припиняються і їхні виправлення безпеки. Ризик зростає щомісяця, навіть якщо сайт ніхто не чіпає.

Старий PHP починає коштувати грошей. Хостинги не тримають застарілі версії вічно: версію можуть прибрати з панелі або зробити платною. GoDaddy з 1 січня 2026 року перевів PHP 8.1 у платну додаткову опцію «розширена підтримка» і підключає її автоматично в разі продовження тарифу: власник платить за те, що сайт залишається на застарілій версії.

Як дізнатися версію PHP на своєму сайті

Для перевірки програміст не потрібен.

WordPress. Відкрийте «Інструменти → Стан сайту», вкладку «Інформація», розділ «Сервер». У рядку «Версія PHP» зазначена поточна версія; якщо там 8.3 або вище, термінових дій не потрібно. Магазини на WooCommerce з PHP 7.4 або 8.0, починаючи з WooCommerce 11.3, бачать в адмінці окреме повідомлення з версією PHP; версія є і в розділі «WooCommerce → Статус», блок «Серверне середовище».

Будь-який інший рушій. У cPanel, Plesk, ISPmanager і панелях українських хостингів є розділ вибору версії PHP. Там видно, яка версія увімкнена для кожного сайту і які доступні.

Фонові завдання (cron) — вивантаження товарів, обмін з обліковою системою, розсилки — іноді працюють на іншій версії PHP, ніж сайт: сайт уже на 8.3, а нічний імпорт прайсу йде на 7.4. Якщо такі завдання є, попросіть хостинг або адміністратора сервера перевірити версію і для них.

Чому не можна просто перемкнути версію в панелі

Змінити версію PHP можна одним кліком у панелі хостингу. Звідси стільки історій «після оновлення PHP сайт не працює»: перемкнули й отримали білий екран або повідомлення «На сайті сталася критична помилка». Між PHP 7.4 і 8.3 мова помітно змінилася, і старий код на новій версії ламається. Приклади з офіційних списків змін PHP:

• У PHP 8.0 видалено функції create_function() і each(), поширені в темах і плагінах десятирічної давності. На PHP 8 виклик такої функції дає фатальну помилку, і сторінка не відкривається.
• У PHP 8.0 заборонено статичний виклик звичайного методу класу. Це одна з найчастіших помилок після переходу: у журналі з’являється «Non-static method … cannot be called statically».
• У PHP 8.2 оголошено застарілим створення динамічних властивостей об’єкта. Сайт працює, але журнал заповнюється повідомленнями Deprecated. У наступних версіях PHP такий код може перестати працювати, тому виправити його краще заздалегідь.

Ядро WordPress на нових версіях PHP перевіряють самі розробники. Ламається зазвичай те, що додано до ядра:

1. Тема або шаблон на замовлення, написані багато років тому, які відтоді ніхто не оновлював.
2. Покинуті плагіни та модулі, зокрема «нульовані» (зламані) копії платних плагінів: вони не оновлюються взагалі.
3. Власний код: правки у файлах теми, інтеграції з обліковою системою та службами доставки, скрипти імпорту.

Чому відкладати оновлення небезпечніше

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

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

Порядок безпечного переходу на PHP 8.3

Послідовність підходить для будь-якого сайту на PHP; особливості WordPress і WooCommerce — у наступному розділі.

Яка версія PHP потрібна. WordPress рекомендує PHP 8.3 або вище. Ми радимо щонайменше 8.3, а 8.4 — якщо всі плагіни або модулі сайту офіційно її підтримують: виправлення безпеки для 8.4 виходитимуть до кінця 2028 року, для 8.3 — до кінця 2027-го. Переходити на 8.2 зараз безглуздо: через два місяці роботу доведеться повторювати. У 8.4 є особливість: розширення IMAP (через нього сайт забирає пошту зі скриньки) прибрано зі стандартного комплекту PHP, і на хостингу його може не бути.

1. Складіть перелік. Версія CMS, плагіни або модулі, тема або шаблон, ліцензії на платні розширення, інтеграції та фонові завдання. Часто на цьому кроці з’ясовується, що частина плагінів не оновлювалася роками. У розділі вибору версії PHP у панелі хостингу порівняйте розширення PHP: які увімкнені зараз і чи є вони в нової версії. Якщо в нової версії немає, наприклад, soap або gd, за справного коду сайту перестануть працювати обмін із зовнішнім сервісом або обробка картинок.
2. Зробіть резервну копію файлів і бази даних та перевірте, що сайт із неї відновлюється. Буває, що в архіві немає бази або він пошкоджений, і з’ясовується це в день аварії.
3. Розгорніть тестову копію на окремому домені (наприклад, test.вашсайт.com) з тими самими версіями PHP, бази даних і вебсервера, що на робочому сервері. Закрийте копію паролем від відвідувачів і пошукових роботів, вимкніть на ній реальні платежі, листи клієнтам і обмін з обліковою системою, інакше тестові замовлення дійдуть до бухгалтера.
4. Оновіть CMS, плагіни та модулі ще на старій версії PHP. Багато помилок після переходу вже виправлені у свіжих версіях плагінів і ядра.
5. Перемкніть PHP на тестовій копії та увімкніть журнал помилок. Пройдіть сайт очима клієнта і працівника: головна, каталог, фільтр, картка товару, кошик, оформлення замовлення, оплата в тестовому режимі, форми, особистий кабінет, пошук, адмінка. Окремо запустіть імпорт, вивантаження та інші фонові завдання.
6. Виправте знайдене. Несумісний плагін оновлюють або міняють на аналог, старий код теми переписують. Якщо заміни плагіну немає, а автор не відповідає, потрібен розробник.
7. Перемкніть робочий сайт у години найменшого навантаження, одразу після свіжої резервної копії. Скиньте кеш CMS і плагіна кешування, інакше і ви, і відвідувачі бачитимете сторінки, зібрані ще старою версією PHP, і перевірка покаже хибну картину. Потім пройдіть ті самі сценарії, що на тестовій копії.
8. Спостерігайте кілька днів. Частина помилок проявляється лише під час рідкісних дій: повернення замовлення, нічний cron, вивантаження в маркетплейс раз на добу. Журнал помилок переглядайте щодня.

План відкату

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

Базу з резервної копії відновлюють лише в крайньому разі: усе, що сталося після створення копії (замовлення, реєстрації, заявки), пропаде. Для інтернет-магазину це втрачені замовлення, тому їх заздалегідь вивантажують або перемикають сайт у той час, коли замовлень майже немає.

Особливості WordPress і WooCommerce

Для оновлення PHP на WordPress є офіційна інструкція wordpress.org. Вона радить оновити ядро, теми та плагіни, а сумісність перевірити плагіном PHP Compatibility Checker. З останньою порадою ми не згодні. Плагін на своїй сторінці в каталозі попереджає: він більше не підтримується, нових версій, зокрема виправлень безпеки, не буде, а перевіряє він сумісність лише до PHP 8.0. Для переходу на 8.3 його результат майже марний; надійніша перевірка на тестовій копії з увімкненим журналом помилок.

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

Журнал помилок у WordPress вмикають у файлі wp-config.php на тестовій копії:

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

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

Що ще перевірити на WordPress:

• Конструктори сторінок і доповнення до них (Elementor і пакети віджетів). Сам конструктор оновлюється регулярно, сторонні пакети віджетів відстають частіше.
• Платні теми, куплені багато років тому. Оновлення таких тем зазвичай прив’язані до чинної ліцензії у продавця, без неї нову версію не завантажити. Перевірте також, чи не правили файли теми напряму: оновлення зітре ці правки, тому спершу їх переносять у дочірню тему.
• WooCommerce і плагіни до нього: оплата, доставка, вивантаження товарів. Вони мають бути сумісні і з новим PHP, і з поточною версією WooCommerce.

Якщо після перемикання замість сайту з’явилося повідомлення «На сайті сталася критична помилка», порядок дій описано в статті критична помилка WordPress після оновлення.

Часті запитання

Чи можна залишитися на PHP 8.2 після 31 грудня 2026 року?

Сайт і далі відкриватиметься, але нових вразливостей у PHP 8.2 закривати не будуть, а хостинг може прибрати 8.2 з панелі або зробити платною. WordPress рекомендує PHP 8.3 або вище; перехід краще спланувати самому й не чекати листа від хостингу.

Чи варто переходити одразу на PHP 8.5?

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

Сайт старий, підрядника немає: з чого почати?

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

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

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

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

Як із переходом на новий PHP допомагає RIVERIT

Пропонуємо взяти сайт на технічну підтримку: до неї входять оновлення CMS і плагінів (зазвичай щомісяця), резервні копії та моніторинг сайту й домену. Перехід на нову версію PHP проводимо за порядком із цієї статті: тестова копія, перевірка, виправлення коду, перемикання і спостереження після нього; працюємо із сайтами на WordPress і WooCommerce, а також на Laravel і Django. Якщо сайт стоїть на VPS або виділеному сервері, беремо сервер на адміністрування (сервер орендується на ваш акаунт), включно зі зміною версії PHP. Якщо поточний хостинг не підтримує PHP 8.3, перенесемо сайт на наш хостинг: сервери в Європі, щоденні резервні копії в окреме сховище, перенесення з іншого хостингу входить у техпідтримку. Клієнтам на підтримці відповідаємо протягом години, а якщо сайт упав, лагодимо і в неробочий час, якщо це входить у тариф.