Symfony 6.4, Drupal 10 і PHP 8.2: три строки підтримки до 2027 року і що робити

За п'ять тижнів наприкінці 2026 року три опори PHP-сайтів втрачають підтримку: виправлення помилок для Symfony 6.4, будь-які випуски для Drupal 10 і виправлення безпеки для PHP 8.2. Цими днями нічого не вимкнеться, але відтоді кожна знайдена проблема лишиться невиправленою. Розбираємо, що й коли закінчується, як за десять хвилин дізнатися, чи стосується це вашого сайту, який шлях оновлення в кожному випадку і чому питання вдвічі важливіше, якщо попереду продаж чи інвестор.

Три дати

Що і коли закінчується

Три строки йдуть від трьох різних проєктів, і в кожного свої правила. Разом вони накривають більшу частину PHP-сайтів і бізнес-систем, побудованих із 2021 по 2024 рік.

Дати пов'язані між собою. Drupal 10 працює на компонентах Symfony 6.4, тож сайт на Drupal 10 зустрічає перші два строки одразу, а чимало таких сайтів стоять на PHP 8.1 чи 8.2, і це приносить третій. Сайти на Laravel теж не осторонь: Laravel 10 втратив підтримку безпеки в лютому 2025 року, Laravel 11 у березні 2026 року, і обидва стоять на компонентах Symfony 6 чи 7 того самого віку. Чому Laravel, Drupal і Symfony так тісно пов'язані, ми розібрали у статті Symfony у 2026 році: фреймворк, на якому стоїть сучасний PHP.

Що це означає

Сайт не вимкнеться

1 грудня нічого не станеться. Сайт відкривається, замовлення надходять, адмінка працює. Саме тому такі строки й пропускають: немає моменту, коли проблема стає видимою.

Змінюється те, що буде, коли наступного разу щось знайдуть. Якщо в ядрі Drupal виявлять уразливість після 9 грудня, випуску Drupal 10, який її закриє, не буде. Якщо помилка в компоненті Symfony 6.4 зламає форму чи оплату після 30 листопада, виправлення потрапить у 7.4 і 8.x, а не в 6.4, якщо тільки це не питання безпеки. А якщо в PHP 8.2 знайдуть діру після Нового року, хостингу чи адміністраторові сервера не буде чого встановлювати.

Довкола цього головного ризику місяць за місяцем накопичуються менші:

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

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

У день строку нічого не ламається. Усе, що знайдуть потім, лишиться зламаним.

Як перевірити

Дізнайтеся, на чому працює ваш сайт

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

# Версія PHP на сервері
php -v

# Застосунок на Symfony: версія ядра фреймворку
composer show symfony/http-kernel

# Застосунок на Laravel
php artisan --version

# Сайт на Drupal (якщо встановлено Drush)
drush status

У Drupal є ще сторінка в адмінці: Звіти, далі Звіт про стан. Угорі там вказано версію Drupal і версію PHP. Ось як читати знайдене:

Якщо відповідь звучить як «ми не знаємо, у кого доступ до сервера», це вже знахідка, і термінова. Відновлення доступів і документації це перший крок будь-якого прийому проєкту.

Symfony 6.4 на 7.4

Шлях оновлення для Symfony

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

1. Прибрати попередження на 6.4. У середовищі розробки Symfony записує кожен виклик застарілої можливості з місцем у коді. Команда виправляє їх один за одним, поки сайт ще працює на 6.4, тож нічого не під загрозою.
2. Перевірити сторонні пакети. Звідси береться більша частина затримок. У кожного зовнішнього пакета має бути версія для Symfony 7; закинуті доводиться замінювати або переносити у власний код.
3. Підняти PHP до 8.2 або новішого. Symfony 7.4 вимагає щонайменше PHP 8.2. Ми радимо одразу йти на 8.4, у якого підтримка безпеки до кінця 2028 року, тоді питання сервера закрите на два роки.
4. Підняти вимоги до версій до 7.4 у файлі залежностей, оновити, прогнати тести й уручну пройти ключові сценарії: вхід, форми, оплати, листи, інтеграції.
5. Випускати поетапно, з готовою копією бази і шляхом назад.

Чому 7.4, а не 8.x? Symfony 7.4 це версія з довгою підтримкою: виправлення помилок до листопада 2028 року і безпеки до листопада 2029 року. Лінія 8.x дає нові можливості, але вимагає PHP 8.4 і оновлення раз на пів року, доки в листопаді 2027 року не вийде 8.4 LTS. Для бізнес-системи, яка має працювати, а не стежити за випусками, 7.4 це спокійний вибір, і з 7.4 наступний крок на 8.4 LTS буде таким самим механічним.

Drupal 10 на 11

Шлях оновлення для Drupal

Drupal дотримується тієї самої логіки зі своїми інструментами. Drupal 11 вимагає PHP 8.3 або новішого і працює на Symfony 7, а мажорні версії Drupal проходять по одній, тож сайт на Drupal 10 у будь-якому разі потрапляє на Drupal 12 через 11. Drupal 11 підтримується до початку грудня 2028 року, це два спокійні роки після оновлення.

Робота зазвичай іде в такому порядку. Спершу ставлять модуль Upgrade Status: він сканує сайт і показує, які сторонні модулі мають версії для Drupal 11 і який власний код використовує застарілі можливості. Далі сторонні модулі оновлюють по одному, а закинуті замінюють. Потім виправляють власні модулі й тему, на сервері піднімають PHP, і ядро переводять на Drupal 11.

Обсяг роботи майже повністю залежить від власного коду. Сайт, зібраний зі стандартних модулів із власною темою, переїжджає швидко. Сайтові, де бізнес-логіка живе в десятку власних модулів, з інтеграціями з CRM чи обліковою системою, спершу потрібен повноцінний аудит. Ми писали модулі для адмінки сайту на Drupal однієї великої американської компанії, тому знаємо, наскільки сьогоднішній модуль Drupal насправді є кодом Symfony: сервіси, події й маршрутизація, ті самі частини, що змінюються між Symfony 6 і 7.

Обсяг оновлення Drupal дорівнює обсягу його власного коду.

В одного з наших клієнтів старіє сайт на Drupal, який хотіли переписати на чомусь новому, і рішення досі зважують. Для такого сайту кінець підтримки Drupal 10 перетворює питання, яке могло почекати, на питання з датою.

PHP 8.2

Сервер під усім цим

PHP це шар, на якому стоїть кожен із цих фреймворків, і в нього свій календар: два роки виправлень помилок і два роки виправлень безпеки для кожної версії. PHP 8.1 втратив підтримку безпеки 31 грудня 2025 року, PHP 8.2 втрачає її 31 грудня 2026 року, PHP 8.3 наприкінці 2027 року, а PHP 8.4 наприкінці 2028 року.

Зміна версії PHP часто виявляється найменшою частиною роботи, а іноді її не можна зробити першою, бо старий фреймворк просто не запускається на новому PHP. Тому важливий порядок: фреймворк готують на старому PHP, далі піднімають PHP, далі переводять фреймворк. Наш власний сайт пройшов ту саму послідовність: перед переведенням на Laravel 13 ми підготували код на старому PHP, і з жовтня 2026 року він працює на PHP 8.4. Як це було, розказано у статті Шість версій Laravel за три дні.

Не завжди оновлення

Коли оновлювати не варто

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

Тоді вибір іде між переписуванням, часто на Laravel, і збереженням старого ядра, поруч із яким нові частини будують із чіткою межею. Бізнес-рішенням частіше потрібен простіший і поширеніший Laravel, який власникові дешевше обслуговувати; Symfony чи Drupal лишаються правильною основою для важких і складних систем і для сайтів, які живуть на моделі контенту Drupal. Ми докладніше розібрали ці варіанти у статті Symfony у 2026 році, а ознаки коду, який варто зберігати, у статті Що відрізняє преміальну збірку на Laravel або Symfony.

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

Ціна і строки

Скільки це коштує і скільки триває

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

У нас робота починається з аудиту, який відповідає на ці питання і дає план із ціною. Для модернізації сайту аудит коштує від $300 для невеликого сайту і від $1 000 для великого. Якщо проєкт приходить від іншого підрядника і треба відновлювати доступи чи документацію, усе починається з аудиту перед прийомом, від $3 000. Саму роботу оцінюють після аудиту за ставкою нашої команди: 75 доларів на годину для senior-розробника і від 45 до 50 для middle, і більшу частину оновлення можна віддати middle під контролем senior.

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

Якщо попереду угода

Чому перед угодою це важливо вдвічі

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

Різниця між продавцем, який це знає, і тим, хто не знає, у часі. Знахідка, яку продавець уже виправив або хоча б запланував із датою і ціною, послаблює позицію покупця значно менше, ніж та, яку покупець знайшов сам. Це робота The Structure, нашого бренду технічної перевірки в угодах із софтверними компаніями: перевірка готовності до виходу знаходить те, що знайшов би покупець, і допомагає вчасно це виправити, а перевірка з боку продавця дає продавцеві незалежний звіт, який можна показати покупцям.

Питання

Питання про строки підтримки

Чи перестане сайт працювати, коли закінчиться підтримка?

Ні. Сайт на Symfony 6.4, Drupal 10 чи PHP 8.2 працюватиме й наступного дня після строку. Припиняються виправлення: нові вразливості й помилки, знайдені після цієї дати, лишаються невиправленими у вашій версії, і кожен місяць подовжує майбутнє оновлення.

Чи безпечно зараз користуватися Symfony 6.4?

Поки що так. Виправлення помилок закінчуються 30 листопада 2026 року, але виправлення безпеки триватимуть до листопада 2027 року. Це рік, щоб спланувати перехід на Symfony 7.4 LTS, який підтримується до листопада 2029 року.

Коли закінчується життя Drupal 10?

9 грудня 2026 року, того ж тижня, коли виходить Drupal 12. Після цього нових випусків Drupal 10 немає зовсім, зокрема випусків безпеки. Drupal 11 підтримується до початку грудня 2028 року.

Чи можна перейти з Drupal 10 одразу на Drupal 12?

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

На яку версію PHP переходити?

На PHP 8.4, якщо ваша версія фреймворку його підтримує: у нього підтримка безпеки до кінця 2028 року. PHP 8.3 це мінімум для Drupal 11, він підтримується до кінця 2027 року. PHP 8.2 і старіші втрачають будь-яку підтримку до кінця 2026 року.

Скільки коштує оновлення?

Це залежить від власного коду, кількості сторонніх модулів, тестів та інтеграцій, тому ціну визначають після аудиту. У нас аудит для модернізації коштує від $300 для невеликого сайту і від $1 000 для великого, а роботу оплачують за ставкою нашої команди.

Джерела

• Symfony Releases
• Drupal core release schedule
• PHP Supported Versions
• Upgrading a Major Version, Symfony documentation
• Laravel 13 Release Notes and Support Policy