Большое январское обновление Битрикс 2026: что важно разработчикам

Видимо, коллеги из Битрикс решили спокойно провести новогодние каникулы и не релизиться перед новым годом 😁, а выкатить всё сразу в январе, так как обновление 25.800.0 было в облаке уже в конце ноября. Январь 2026 принёс пачку изменений, которые прямо влияют на разработку и сопровождение коробочных проектов: обновили интеграцию поиска со Sphinx 3, расширили возможности D7-контроллеров, добавили генераторы кода через CLI, усилили аудит целостности ядра и продолжили развивать REST V3/REST 3.0.

TL;DR (коротко)

• Окружение: с 01.02.2026 прекращается поддержка PHP ниже 8.2 (рекомендуемая 8.4+). С 01.09.2026 будет ограничена поддержка MySQL ниже 8.0.0 (рекомендуемая 8.4+).
• Поиск: добавлена поддержка Sphinx 3 (в т.ч. обновлён пример sphinx.conf и учтены нюансы SNIPPETS).
• в \Bitrix\Main\Engine\Controller добавлен renderComponentAjax() для удобного AJAX-рендеринга компонентов;
• добавлено событие onApplicationResponseFinalized — можно перехватить финальный HTTP-ответ контроллера;
• появилось PSR-16‑совместимое хранилище в БД + декоратор с отложенной записью;
• тест модификации ядра теперь показывает лишние/неизвестные файлы в папках модулей;
• urlrewrite.php подключает routing_index.php;
• Redis-коннектор умеет принимать password;
• добавлены make:* команды в CLI.
• rest: правки REST 3.0 (кеширование/API) + API для описания scope и изменён ключ кеширования.

Важные изменения по окружению (обязательно учесть)

С 01.02.2026 — прекращение поддержки PHP ниже 8.2

Если у вас всё ещё PHP 8.0/8.1 — это уже зона риска: часть обновлений ядра и модулей будет ориентироваться на PHP 8.2+.

Рекомендуемая версия: PHP 8.4+.

Что сделать:

• Поднять тестовый стенд на PHP 8.2/8.3/8.4 и прогнать регресс.
• Проверить Composer-зависимости (если используете /local/vendor) на совместимость с 8.2+.
• Проверить расширения (gd/imagick, redis, intl, opcache, mbstring и т.д.).
• Включить строгий аудит депрекейтов: лог E_DEPRECATED на тесте.

С 01.09.2026 — будет ограничена поддержка MySQL ниже 8.0.0

Если ваши окружения до сих пор на MySQL 5.7 — планируйте миграцию.

Рекомендуемая версия: MySQL 8.4+.

Что сделать:

• Проверить дамп на тестовом MySQL 8.0+ (collation, индексы, размер полей, режимы SQL).
• Перепроверить нагрузочные места (планы запросов после апгрейда).

Поиск: добавлена поддержка Sphinx 3 (Поиск 25.200.0)

В модуле поиска добавили поддержку Sphinx 3, причём не только «на словах»: в коде учтены отличия по построению сниппетов и в админке актуализирован пример sphinx.conf.

Что изменилось в ядре

• В bitrix/modules/search/tools/sphinx.php учтены различия версий Sphinx при построении SNIPPETS: для Sphinx < 3 добавляется query_mode, а для Sphinx 3 — нет (версия берётся из server_info).
• В bitrix/modules/search/options.php добавлен отдельный пример конфигурации для Sphinx 3.x (RT-индекс с field и attr_*, включая attr_uint_set).

Что сделать администратору / DevOps

1. Обновить sphinx.conf под 3.x (если мигрируете с 2.x):

   • использовать field = ... вместо rt_field = ...;
   • использовать attr_uint, attr_string, attr_uint_set вместо rt_attr_*;
   • убрать устаревшие параметры из примера 2.x (path, docinfo, dict, enable_star, charset_type и т.п.).

   Минимальный каркас RT-индекса под 3.x (схема — как ожидает Битрикс):

   Копировать

           index bitrix
   {
       type = rt
       field = title
       field = body
   
       attr_uint = module_id
       attr_string = module
       attr_uint = item_id
       attr_string = item
       attr_uint = param1_id
       attr_string = param1
       attr_uint = param2_id
       attr_string = param2
       attr_uint = date_change
       attr_uint = date_to
       attr_uint = date_from
       attr_uint = custom_rank
   
       attr_uint_set = tags
       attr_uint_set = right
       attr_uint_set = site
       attr_uint_set = param
   }
   
       

2. Пересоздать RT-индекс (изменение схемы RT‑таблицы).

3. В админке Битрикс: Настройки → Настройки продукта → Поиск → Переиндексация — выполнить полную переиндексацию.

4. Проверить строку подключения в настройках поиска (обычно 127.0.0.1:9306, MySQL‑протокол).

Что сделать разработчику

• Если у вас есть кастомные интеграции, завязанные на Sphinx, проверьте:
  • что индекс действительно типа rt (ядро это проверяет);
  • что поля и типы соответствуют ожидаемому набору (ядро сравнивает DESCRIBE с картой полей).

Главный модуль (main)

Контроллеры: renderComponentAjax() (main 25.1100.0)

В базовый класс \Bitrix\Main\Engine\Controller добавлен метод renderComponentAjax() — удобный способ вернуть ответ контроллера, который рендерит компонент в формате, подходящем для AJAX‑сценариев (вместо «ручного» includeComponent/буферов).

Где в коде: bitrix/modules/main/lib/engine/controller.php.

Пример:

        use Bitrix\Main\Engine\Controller;
use Bitrix\Main\Engine\ActionFilter;
use Bitrix\Main\Engine\Response\Component as ComponentResponse;

final class Catalog extends Controller
{
    protected function getDefaultPreFilters(): array
    {
        return [
            new ActionFilter\Authentication(),
            new ActionFilter\HttpMethod([ActionFilter\HttpMethod::METHOD_POST]),
        ];
    }

    public function listAction(int $sectionId = 0): ComponentResponse
    {
        return $this->renderComponentAjax(
            'bitrix:catalog.section',
            '.default',
            [
                'IBLOCK_ID' => 1,
                'SECTION_ID' => $sectionId,
            ],
        );
    }
}

    

Когда применять:

• Когда фронтенд ждёт «компонентный» ответ, но вы хотите работать через контроллеры (а не отдельные AJAX‑скрипты).
• Когда важно держать бизнес‑логику в сервисах и отдавать UI через компонент.

Событие onApplicationResponseFinalized (main 25.1100.0)

Добавлено событие, которое срабатывает после финализации ответа контроллера, но до отправки в клиент. Это позволяет подключить «перехватчик» на уровне приложения.

Где в коде: bitrix/modules/main/lib/httpapplication.php (HttpApplication::EVENT_ON_RESPONSE_FINALIZED и отправка события в finalizeControllerResult()).

Практические кейсы:

• Единое логирование ответа контроллеров (статус, размер, тип ответа) без правки каждого контроллера.
• Метрики/трассировка (тайминги, correlation id).
• Нормализация заголовков (например, Cache-Control, X-Request-Id) в одном месте.

Пример регистрации обработчика (идея):

        use Bitrix\Main\EventManager;
use Bitrix\Main\HttpApplication;

EventManager::getInstance()->addEventHandler('main', HttpApplication::EVENT_ON_RESPONSE_FINALIZED, static function(\Bitrix\Main\Event $event) {
    $response = $event->getParameter('response');
    $controller = $event->getParameter('controller');
    // ... логирование/метрики/заголовки ...
});

    

PSR‑16 хранилище в БД + отложенное сохранение (main 25.1100.0)

Добавлены два важных кирпичика для хранения небольших значений в БД:

• ConnectionBasedPersistentStorage — реализация PersistentStorageInterface, которая хранит ключ‑значение в таблице PersistentStorageTable с TTL.
• DeferredStorageDecorator — декоратор над StorageInterface, который копит изменения в памяти и сохраняет пачкой (при save() или в __destruct()).

Где в коде:

• bitrix/modules/main/lib/data/storage/connectionbasedpersistentstorage.php
• bitrix/modules/main/lib/data/storage/deferredstoragedecorator.php
• DI‑привязка в bitrix/modules/main/.settings.php (интерфейсы мапятся на ConnectionBasedPersistentStorage).

Зачем это нужно:

• компактное состояние (флаги, маркеры, шаги) без отдельной таблицы в вашем модуле;
• снижение количества запросов при множественных set() (через отложенную запись).

На что обратить внимание:

• ConnectionBasedPersistentStorage::clear() запрещён (кидает исключение), то есть «снести всё» нельзя — только точечно по ключам.
• DeferredStorageDecorator сохраняет в деструкторе — для долгоживущих процессов/очередей лучше явно вызывать save().

Мини-пример использования (в т.ч. с отложенной записью):

        use Bitrix\Main\Data\Storage\ConnectionBasedPersistentStorage;
use Bitrix\Main\Data\Storage\DeferredStorageDecorator;

$storage = new DeferredStorageDecorator(new ConnectionBasedPersistentStorage());

$counter = (int)$storage->get('my.feature.counter', 0);

// можно сделать несколько set() — в БД улетит пачкой при save() (или в __destruct())
$storage->set('my.feature.counter', $counter + 1, 3600);
$storage->set('my.feature.lastRunAt', (new \DateTimeImmutable())->format(DATE_ATOM), 3600);

$storage->save();

    

CLI: генераторы make:* (main 25.900.0)

В Bitrix CLI добавили набор команд‑генераторов: make:entity, make:module, make:request, make:service, make:event, make:eventhandler, make:message, make:messagehandler, make:agent.

Где в коде: bitrix/modules/main/lib/cli/command/make/ (например, ModuleCommand, EntityCommand, AgentCommand и т.д.).

Все новые команды make:* из обновления:

• make:entity — создание класса-сущности ORM (таблицы);
• make:module — генерация структуры нового модуля;
• make:request — создание класса для обработки HTTP-запросов;
• make:service — генерация каркаса сервис-класса для бизнес-логики;
• make:event — создание класса события;
• make:eventhandler — генерация шаблона обработчика события;
• make:message — создание класса сообщения для шины данных;
• make:messagehandler — генерация обработчика сообщения;
• make:agent — создание заготовки для нового агента.

Примеры запуска:

        # генерация сущности
php bitrix.php make:entity post -m my.module

# генерация модуля-скелета в /local/modules
php bitrix.php make:module my.module --name="My Module"

# генерация обработчика события
php bitrix.php make:eventhandler OnBeforeUserAdd --handler-module=my.module --event-module=main

    

Практический сценарий (типовой):

1. Создать каркас модуля: php bitrix.php make:module vendor.module --name="..." --description="..."
2. Добавить сервис: php bitrix.php make:service Notification -m vendor.module
3. Сгенерировать сущность ORM: php bitrix.php make:entity Notification -m vendor.module

Проверка системы: тест модификации ядра показывает «лишние файлы» (main 25.900.0)

Тест проверки целостности ядра теперь показывает не только изменённые файлы, но и неизвестные (лишние) — те, которых нет в эталонном списке файлов/хешей для конкретной версии модуля.

Где в коде:

• CAutoCheck::CheckKernel() — bitrix/modules/main/classes/general/autocheck.php
• рекурсивное сканирование — CCheckListTools::__scandir() в bitrix/modules/main/classes/general/checklisttools.php
• эталонные хеши скачиваются через Bitrix\Main\UpdateSystem\Checksum::getHashes(..., fullScan: true) — bitrix/modules/main/lib/UpdateSystem/Checksum.php

Почему вы увидите «лишние файлы»: Сканер почти ничего не исключает (по сути только ua/ и языковые подпапки, кроме de/en/kz/ru). Любые *.bak, *.old, .DS_Store, мусор от IDE и т.п. в /bitrix/modules/<module>/ попадёт в отчёт как UNKNOWN_FILES.

Как использовать с пользой:

• это хороший аудит на предмет «подложили файл в модуль»;
• для чистоты отчёта держите /bitrix/modules без временных артефактов и резервных копий.

Роутинг: urlrewrite.php подключает routing_index.php (main 25.800.0)

В старый вход urlrewrite.php добавлено подключение routing_index.php. Это мост между «старыми маршрутами» и новым роутингом.

Где в коде: bitrix/modules/main/include/urlrewrite.php (в конце файла подключается routing_index.php).

Что это означает на практике:

• если вы внедряете новый роутинг, ядро теперь активнее «сводит» старую точку входа к новой;
• проверьте кастомизации urlrewrite.php (если вы его меняли вручную) — теперь там появился ещё один важный include.

Redis: пароль в настройках соединения (main 25.800.0)

В настройках Redis‑соединения теперь можно передать пароль password, и соединение выполнит AUTH.

Где в коде:

• разбор конфига (password) — bitrix/modules/main/lib/data/configurator/redisconnectionconfigurator.php
• прокидывание password из кеш‑конфига — bitrix/modules/main/lib/data/cache/keyvalueengine.php

Пример (идея) для .settings.php (соединение):

        return [
    'connections' => [
        'value' => [
            'redis' => [
                'className' => '\\Bitrix\\Main\\Data\\RedisConnection',
                'host' => '127.0.0.1',
                'port' => '6379',
                'password' => 'your-redis-password',
                'persistent' => true,
                'timeout' => 1,
            ],
        ],
    ],
];

    

JS: удалены расширения core_fx и core_ls (main 25.900.0)

По списку обновлений удалены расширения core_fx и core_ls, а их API перенесено в core.

Что проверить в проектах:

• если где-то вызываете CJSCore::Init(['core_fx']) или CJSCore::Init(['core_ls']) — заменяйте на core (или актуальные зависимости библиотеки).
• прогоните UI‑регрессии: анимации, автосейвы, сценарии с локальным хранилищем и «живыми» обновлениями.

Удалены классы вида CAll* (main 25.800.0)

Продолжается чистка старого API: удалён ряд базовых классов CAll* (в списке обновлений примеры: CAllMain, CAllUser).

Практика:

• если в проекте есть прямые ссылки на CAll..., получите фатальную ошибку «Class not found» после обновления;
• обычно это лечится переходом на актуальный класс (CUser, CMain, D7‑аналоги) и/или отказом от наследования от внутренних базовых классов.

Главный модуль (main): REST V3 для работы с журналом событий (main 25.800.0)

Добавлены REST V3 методы для работы с журналом событий (event log).

Где в коде:

• контроллер: bitrix/modules/main/lib/Rest/V3/Controller/EventLog.php
• DTO: bitrix/modules/main/lib/Rest/V3/Dto/EventLogDto.php

Что доступно: Контроллер использует стандартные трейты (ListOrmActionTrait, GetOrmActionTrait, TailOrmActionTrait), то есть ожидаемо будут доступны операции уровня «получить список / получить запись / tail‑выборка».

Права: На уровне фильтра требуется операция view_event_log — это правильно с точки зрения безопасности.

REST-модуль

Исправления в кешировании и API REST 3.0 (rest 25.1200.0 / 25.1100.0)

По списку обновлений — технические правки кеширования и API. На практике это чаще всего означает:

• меньше странных кейсов с устаревшими схемами/описаниями методов;
• иногда может потребоваться очистка managed cache (если ловите «не вижу новые методы/поля» сразу после обновления).

API для описания scope + изменён ключ кеширования (rest 25.900.0)

Добавлены API, позволяющие получать доступные scope (полезно для приложений и диагностики прав), и изменён ключ кеширования в REST 3.0.

Где в коде:

• контроллер для scope: bitrix/modules/rest/lib/V3/Realisation/Controller/Scope.php
• менеджер кеша: bitrix/modules/rest/lib/V3/CacheManager.php

Что важно понимать про кеш: В CacheManager ключ строится с глобальной частью, зависящей от конфигураций модулей (id/version/modification datetime). Это снижает шанс получить «не тот» кеш при изменениях схем/контроллеров.

Если после обновления вы видите странности вида «методы/поля REST V3 не обновились»:

• можно очистить кеш REST V3 программно:

        \Bitrix\Rest\V3\CacheManager::cleanAll();

    

• либо на время диагностики отключить кеширование REST V3 через конфиг:

        // .settings.php
return [
    'rest' => [
        'value' => [
            'v3_cache_disabled' => true,
        ],
    ],
];

    

Известные проблемы при обновлении

Ошибка UUGZA073 Сбой на файле. [CL02] Ошибка распаковки пакета

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