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