PHP 8.3 вийшов наприкінці 2023 року, PHP 8.4 — роком пізніше. Обидві версії вже доступні на більшості серверів із cPanel та ISPmanager 6, але багато проєктів досі працюють на PHP 8.1 просто за інерцією. Розберемо, що змінилося на практиці і чи варто переходити прямо зараз.
Що нового в PHP 8.3 і PHP 8.4
PHP 8.3 додав типізовані константи класів, атрибут
#[Override] для контролю перевизначення методів і функцію
json_validate(), яка перевіряє коректність JSON без розбору
всієї структури в пам'ять. Це помітно пришвидшує валідацію вхідних запитів
API.
PHP 8.4 пішов далі: з'явилися property hooks (гетери і сетери прямо в
оголошенні властивості), асиметрична видимість (public readonly
можна зробити публічним на читання і приватним на запис окремо) та нові
функції для масивів — array_find(), array_any(),
array_all(). Докладніше про строгу типізацію, яка добре
поєднується з цими нововведеннями, — у статті
про strict_types на проді.
Як працюють property hooks на практиці
Раніше для валідації значення при записі у властивість потрібен був окремий метод-сетер. Property hooks прибирають цю прошарку:
class Product {
public int $price {
set {
if ($value < 0) {
throw new InvalidArgumentException('Ціна не може бути відʼємною');
}
$this->price = $value;
}
}
}
Код стає коротшим, а IDE і статичні аналізатори бачать реальний тип властивості, а не здогадуються за докблоками.
Строки підтримки версій PHP
Кожна версія PHP отримує два роки активної підтримки з виправленням багів і ще один рік — лише security-патчі. Далі версія вважається застарілою і оновлення припиняються.
| Версія | Активна підтримка | Security-фікси | Статус на сервері |
|---|---|---|---|
| PHP 8.1 | завершена | закінчується | час планувати перехід |
| PHP 8.2 | завершується | триває | ще безпечно |
| PHP 8.3 | триває | не почалася | рекомендовано |
| PHP 8.4 | триває | не почалася | для нових проєктів |
На що звернути увагу при переході
Частина змін у 8.3 і 8.4 ламає старий код, якщо він покладався на нестроге поводження PHP. Перед оновленням перевірте:
- Неявні nullable-типи в сигнатурах функцій — у PHP 8.4 такі оголошення
вважаються застарілими і потребують явного
?type. - Динамічні властивості класів без атрибута
#[AllowDynamicProperties]— вони заборонені ще з PHP 8.2. - Розширення з pecl, які не оновлювалися понад два роки — частина з них ламається на новому Zend Engine.
- Бібліотеки Composer із жорстко вказаною верхньою межею PHP у
composer.json— їх доведеться оновити або замінити.
Як перевірити і перемкнути версію PHP на сервері
На Ubuntu і Debian версії PHP перемикаються через update-alternatives,
а для сайтів під Nginx і PHP-FPM — через пул у конфігу віртуального хоста.
Спочатку поставте потрібну версію поруч зі старою, не видаляючи її:
php -v
sudo apt install php8.4 php8.4-fpm php8.4-mysql php8.4-mbstring
sudo update-alternatives --set php /usr/bin/php8.4
sudo systemctl restart php8.4-fpm
Як тримати кілька версій одночасно і перемикати їх per-vhost — описано в статті про кілька версій PHP на одному сервері. Перелік потрібних розширень для конкретного фреймворку простіше зібрати за інструкцією про встановлення розширень PHP.
Чи варто оновлюватися: чек-лист
Оновлення версії PHP — це не разова кнопка, а перевірка сумісності. Порядок дій такий:
- Розгорніть копію проєкту на staging із новою версією PHP і прожене тести або принаймні основні сценарії вручну.
- Виконайте
composer installі переконайтеся, що всі залежності підтримують обрану версію без попереджень про сумісність. - Перемкніть PHP-FPM на нову версію і увімкніть JIT в OPcache — приріст швидкості на CPU-інтенсивних задачах помітний вже на перших запитах.
Часті питання
Як оновитися з PHP 8.3 до PHP 8.4 без зупинки сайту під час переходу?
Нову версію варто ставити поруч зі старою, не видаляючи її одразу, і спочатку перевірити проєкт на копії на staging. Після команди composer install потрібно переконатися, що всі залежності підтримують нову версію без попереджень, і лише тоді перемкнути пул PHP-FPM на PHP 8.4 — тоді в разі проблем можна миттєво повернутися на попередню версію.
Які зміни під час переходу з PHP 8.3 на PHP 8.4 найчастіше ламають старий код?
Головний кандидат — неявні nullable-типи в сигнатурах функцій: у PHP 8.4 такий запис вважається застарілим і потребує явного знака питання перед типом. Також варто заздалегідь перевірити розширення з pecl, які давно не оновлювалися, динамічні властивості класів без спеціального атрибута і бібліотеки Composer із жорстко прописаною верхньою межею підтримуваної версії PHP.
Чи можна продовжувати працювати на PHP 8.1, поки руки не дійдуть до повноцінного оновлення?
Формально сайт продовжить працювати без видимих змін: активна підтримка PHP 8.1 вже завершена, а фаза лише security-патчів добігає кінця. Це означає, що нові вразливості в цій версії перестануть закриватися зовсім, і сервер поступово опиниться без захисту від свіжих проблем — привід радше спланувати перехід, ніж відкладати його далі.
Чи обовʼязково одразу вмикати JIT в OPcache під час переходу на нову версію PHP?
Ні, це не обовʼязковий крок для роботи на новій версії, а окрема рекомендація з чек-листа за підсумками оновлення. Більшість звичайних сайтів впираються у швидкість бази даних чи мережі, а не в обчислення процесора, тому приріст від JIT там малопомітний. Вмикати його варто окремо для CPU-інтенсивних завдань, де виграш у швидкості видно вже на перших запитах.