Доработка компонентов Битрикс через result_modifier

Доработка компонентов Битрикс через result_modifier

Наши инженеры регулярно получают такие задачи: вывести список товаров через catalog.section с дополнительными данными — остатками по складу, рейтингами, кастомными свойствами. Стандартные компоненты Битрикс не дают таких данных «из коробки». Многие разработчики лезут в ядро или копируют компонент целиком и получают проблемы с обновлениями платформы.

Мы используем result_modifier.php — файл, который выполняется после работы компонента, но до рендера шаблона. Он позволяет дополнить $arResult любыми данными без единой правки ядра. Согласно официальной документации 1С-Битрикс, result_modifier предназначен для трансформации данных перед шаблоном. Это даёт полную совместимость с обновлениями платформы и снижает время доработки в 2–3 раза по сравнению с переопределением компонента. Экономия бюджета достигает 30–50%, что на типовой задаче составляет от $400–800. А все изменения кэшируются вместе с основными данными.

Принцип работы result_modifier

Последовательность выполнения компонента:

1. component.php — логика компонента, заполняет $arResult.
2. result_modifier.php — модификация $arResult в шаблоне.
3. template.php — рендер HTML.
4. component_epilog.php — постобработка после рендера.

Файл result_modifier.php живёт в папке шаблона компонента:

/local/templates/{site_template}/components/bitrix/catalog.element/default/result_modifier.php 

Если вы создали шаблон через административный интерфейс (Настройки → Компоненты → Шаблоны компонентов), файл создаётся автоматически.

Доступные переменные внутри

Преимущества перед переопределением компонента

Переопределение компонента через /local/components требует копирования всей логики и её поддержки при обновлениях. result_modifier работает поверх существующего компонента, сохраняя совместимость с обновлениями. Время доработки сокращается в 2–3 раза, а бюджет снижается на 30–50% (от $500–1k экономии на среднем проекте). При этом вы не теряете в производительности — все изменения кэшируются вместе с основными данными.

Примеры доработок

Добавление рейтинга через result_modifier

В карточке товара (catalog.element) $arResult не содержит рейтинг из таблицы отзывов. Решаем одной функцией:

// result_modifier.php for bitrix:catalog.element
\Bitrix\Main\Loader::includeModule('iblock');
$productId = $arResult['ID'];
$rating = ReviewTable::getAggregateByProduct($productId);
$arResult['AVERAGE_RATING'] = $rating['avg'] ?? 0;
$arResult['REVIEWS_COUNT'] = $rating['count'] ?? 0;

Остатки по складам в списке товаров

// result_modifier.php for bitrix:catalog.section
\Bitrix\Main\Loader::includeModule('catalog');
$productIds = array_column($arResult['ITEMS'], 'ID');
$stocks = \Bitrix\Catalog\StoreProductTable::getList([
    'filter' => ['PRODUCT_ID' => $productIds, 'STORE.ACTIVE' => 'Y', 'STORE.XML_ID' => 'MAIN_WAREHOUSE'],
    'select' => ['PRODUCT_ID', 'AMOUNT'],
])->fetchAll();
$stockMap = array_column($stocks, 'AMOUNT', 'PRODUCT_ID');
foreach ($arResult['ITEMS'] as &$item) {
    $item['MAIN_STOCK'] = $stockMap[$item['ID']] ?? 0;
    $item['IN_STOCK'] = $item['MAIN_STOCK'] > 0;
}
unset($item);

Изменение цен для групп пользователей

Для показа оптовой цены авторизованным пользователям в result_modifier проверяем группу и подменяем цену:

if ($USER->IsAuthorized() && in_array(5, $USER->GetUserGroupArray())) {
    $arResult['PRICE'] = $arResult['PRICE'] * 0.9; // скидка 10%
}

Кэширование и производительность

Если внутри result_modifier выполняется тяжёлый запрос (например, к внешнему API или большая выборка), оберните его в кэш. Иначе при каждом хите будет выполняться лишняя работа.

$cacheId = 'product_extra_' . $arResult['ID'];
$cacheDir = '/product_extra/';
$ttl = 3600;
$cache = \Bitrix\Main\Data\Cache::createInstance();
if ($cache->initCache($ttl, $cacheId, $cacheDir)) {
    $extraData = $cache->getVars();
} elseif ($cache->startDataCache()) {
    $extraData = fetchHeavyProductData($arResult['ID']);
    $cache->endDataCache($extraData);
}
$arResult['EXTRA'] = $extraData;

Важно: если компонент сам использует кэш (большинство компонентов каталога), то result_modifier.php не выполняется при отдаче из кэша — выполняется только template.php. Данные, добавленные в $arResult в result_modifier.php, кэшируются вместе с $arResult.

Сравнение подходов

Ограничения

result_modifier — не место для операций с побочными эффектами: создания записей в БД, отправки уведомлений, изменения состояния. Это только чтение и трансформация $arResult. Для побочных эффектов используйте component_epilog.php.

Нельзя изменить уже выполненные SQL-запросы компонента — только дополнить результат новыми запросами. Если нужно изменить логику получения данных — придётся переопределять сам компонент.

Процесс и сроки

Типичные этапы работы:

1. Анализ: изучаем структуру $arResult нужного компонента, определяем недостающие данные.
2. Проектирование: выбираем источник данных (HL-блок, таблица, внешнее API).
3. Реализация: пишем result_modifier.php с запросом и модификацией массива.
4. Кэширование: настраиваем тегированный кэш для производительности.
5. Тестирование: проверяем при разных сценариях (кэш вкл/выкл, разные группы пользователей).
6. Деплой: размещаем в папке шаблона, настраиваем мониторинг.

Состав работы:

• Файл result_modifier.php с комментариями и обработкой ошибок.
• Настройка кэша (тегированный, TTL).
• Документация по добавленным полям.
• Консультация по расширению решения.

Ориентировочные сроки: большинство задач занимает 4–16 часов. Стоимость рассчитывается индивидуально — от $400–1.5k в зависимости от сложности. Получите консультацию: расскажем, как сэкономить время и бюджет.