31 декабря PHP 8.2 перестанет получать исправления: что это значит для сайта на 1С-Битрикс

31 декабря 2026 года ветка PHP 8.2 выходит из поддержки. После этой даты исправления безопасности для неё выпускать не будут — даже для уязвимостей, которые позволяют выполнить чужой код на сервере. Если сайт работает на 8.2, время на спокойный переход есть ровно до конца года.

Что именно заканчивается

У каждой ветки PHP два срока. Первый — активная поддержка, когда чинят любые ошибки. Второй — поддержка безопасности, когда выпускают только исправления уязвимостей. У 8.2 активная поддержка закончилась ещё 31 декабря 2024 года, а поддержка безопасности заканчивается 31 декабря 2026.

Почему это не абстрактная дата

В октябре 2026 года в PHP нашли две уязвимости с оценкой 9,2 из 10, каждая позволяет выполнить произвольный код на сервере без авторизации. Исправления вышли для веток 8.2, 8.3, 8.4 и 8.5. Для 7.4, 8.0 и 8.1 их не выпустили вовсе — эти ветки уже вне поддержки, и единственным решением для них был переход на версию новее.

С 1 января в этом же положении окажется 8.2. Следующая уязвимость такого уровня — а они выходят регулярно — закроется для всех, кроме тех, кто остался на старой ветке. И закрывать её придётся не обновлением за вечер, а срочным переходом на новую версию в тот момент, когда рабочие эксплойты уже разошлись.

Как это выглядит, когда время упущено, мы разбирали в кейсе про взломанный сайт: несколько лет на неподдерживаемой версии, шесть веб-шеллов и поисковый клоакинг, который владелец не видел месяцами.

Что требует сам Битрикс

В требованиях к серверному программному обеспечению указано: для работы продукта нужен PHP 8.2.0 и выше, рекомендуемая версия — 8.4 и выше. Минимум 8.2 действует с 1 февраля 2026 года.

Получается вилка, о которой стоит знать заранее: с 1 января минимально допустимая для продукта версия перестаёт поддерживаться самим PHP. Формально сайт требованиям соответствует, фактически работает на ветке без исправлений безопасности. Поэтому ориентироваться стоит на рекомендацию вендора, а не на нижнюю границу требований.

Как узнать свою версию

Самый надёжный способ — административная часть сайта, раздел «Настройки — Проверка системы». Там показана та версия, на которой работает сам сайт.

Команда php -v в консоли отвечает за другое: на сервере обычно стоит несколько версий, и консольная может отличаться от той, что обслуживает сайт. Разницу важно проверить отдельно, потому что на консольной версии работают задания планировщика и обмен с 1С. Нередко сайт уже на 8.3, а ночной обмен всё ещё идёт через 8.0 — и ломается после обновления, которого никто не делал.

Если доступа к админке нет, версию покажет страница с phpinfo(), выложенная во временный файл. После проверки файл нужно удалить: он раскрывает конфигурацию сервера целиком.

Куда переходить

Вариантов два, и оба рабочие.

PHP 8.3 — минимальный шаг. Исправления до конца 2027 года, ломающих изменений относительно 8.2 немного. Подходит, если на сайте много старых модулей Маркетплейса и хочется разнести переход на два этапа.

PHP 8.4 — рекомендация вендора. Исправления до конца 2028 года, то есть следующий такой разговор состоится через два года, а не через год. Требует чуть больше работы по уведомлениям в журнале.

Переходить сразу на 8.5 мы пока не советуем: вендор её рекомендованной не называет, и часть сторонних модулей на ней ещё не проверена.

Что сыплется в журнал на 8.4

Главный источник уведомлений — неявно обнуляемые параметры. Запись вида function foo(Type $arg = null) в PHP 8.4 объявлена устаревшей, правильно писать ?Type $arg = null. В коде, которому несколько лет, такая запись встречается десятками: в собственных компонентах, в шаблонах, в модулях Маркетплейса.

Кроме этого:

• константа E_STRICT объявлена устаревшей — уровень ошибок с таким именем убрали;
• trigger_error() с уровнем E_USER_ERROR устарел, вместо него ожидается исключение или завершение работы;
• возведение нуля в отрицательную степень через ** и pow() устарело — это деление на ноль;
• класс с именем из одного подчёркивания больше использовать нельзя.

Всё перечисленное пока только предупреждения: сайт работает, но журнал растёт. Проблемой они станут в следующей мажорной версии, когда предупреждения превратятся в фатальные ошибки. Так уже было при переходе с 7.x на 8.0: count() на не-массиве из предупреждения стал ошибкой и положил тысячи сайтов.

Порядок перехода

По нашему опыту переходов последовательность такая.

1. Сначала журнал ошибок, потом смена версии. Без подробного журнала Битрикс на каждую ошибку показывает заглушку «Произошла ошибка», и причина остаётся неизвестной. Включается в .settings.php и настройках PHP до переключения, а не после.
2. Снять копию и проверить на отдельном стенде. Переключение версии на боевом сайте без репетиции — самый дорогой способ узнать, какой модуль несовместим.
3. Проверить модули Маркетплейса. Сначала обновить то, что обновляется, затем посмотреть, какие решения давно не поддерживаются автором. Чужой код ломается чаще ядра.
4. Проверить консольную версию. Планировщик и обмен с 1С должны работать на той же версии, что и сайт.
5. После правок очистить кеш, включая композитный. Битрикс хранит готовый HTML отдельными файлами, и страница с ошибкой может отдаваться ещё долго после того, как причина устранена.
6. Проверить обмен, оплату и почту. Эти три вещи ломаются тише всего: заказы перестают уходить, письма не отправляются, а на сайте внешне всё в порядке.

Подробный разбор того, что именно ломается в самом продукте, у нас есть в базе знаний: переход на PHP 8 и типовые ошибки.

Если ядро обновить нельзя

Отдельная ситуация — истёкшая лицензия на обновления. Обновить ядро нельзя, а версию PHP поднимать надо. Это решаемо: правки делаются точечно, в местах, где старый код полагался на мягкое поведение прежних версий. В нашем кейсе на связке старого ядра с темой Aspro такой переход занял вечер и около десяти файлов, в каждом — проверка типа перед вызовом.

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

Что успеть до конца года

Если сайт на 8.2, разумный план такой: в ноябре проверить версии (сайт, консоль, планировщик) и список модулей, в начале декабря провести переход на стенде, до двадцатых чисел — на боевом. Оставлять на последнюю неделю декабря не стоит: это время корпоративных отпусков и пикового трафика у магазинов, и любая поломка обходится дороже обычного.

Если версия ниже 8.2 — переход нужен не к Новому году, а сейчас: для этих веток исправления не выпускают уже больше года.