Что такое result_modifier.php и component_epilog.php в 1С-Битрикс и зачем они нужны?

Ниже представлена расширенная версия статьи, в которой учтены оба подхода к созданию компонентов в 1С-Битрикс: классический (через component.php) и на новом ядре (через class.php). При этом суть работы с файлами result_modifier.php и component_epilog.php остаётся такой же, но есть некоторые нюансы, связанные с тем, где хранится основная логика компонента.

1. Почему в 1С-Битрикс несколько вариантов структуры компонента

В классическом подходе к разработке для каждого компонента использовался основной файл логики component.php. Начиная с появления “нового ядра” Bitrix (D7) всё чаще практикуется создание компонентов с помощью классов, где основная логика переносится в файл class.php. Этот способ считается более современным и гибким, особенно при построении крупных проектов и использовании ООП-подхода.

Классический подход предполагает:


/my_component/
|— component.php          (основная логика компонента)
|— .parameters.php        (описание параметров)
|— lang/                  (файлы локализации)
|— templates/
   |— .default/
       |— result_modifier.php
       |— template.php
       |— component_epilog.php

Подход на новом ядре (D7) предполагает примерно такую структуру:


/my_component/
|— class.php              (основная логика компонента, класс наследует CBitrixComponent)
|— .parameters.php
|— lang/
|— templates/
   |— .default/
       |— result_modifier.php
       |— template.php
       |— component_epilog.php

При этом принципы работы с кешем, формирования и модификации данных, а также место result_modifier.php и component_epilog.php в цепочке исполнения остаются почти идентичными. Главное отличие в том, что “сердце” компонента — код, который формирует $arResult, теперь находится не в component.php, а в методе executeComponent() внутри class.php.

2. Общая схема работы компонента (обе версии)

Независимо от того, используете вы файл component.php или class.php, цепочка вызовов обычно выглядит так:

Основной код компонента:
- Классический подход: файл component.php.
- Новый подход: файл class.php с методом executeComponent().
В нём формируется массив $arResult, обрабатываются $arParams, выполняются запросы к БД, работа с API и т.д.
(Опционально) result_modifier.php
- Находится в папке шаблона.
- Используется для того, чтобы дополнительно изменить $arResult (и/или $arParams) перед тем, как данные будут переданы в шаблон template.php.
- Служит для “предварительной обработки” итогового результата и разгрузки шаблона от вычислительной логики.
template.php
- Непосредственно HTML/PHP-шаблон, который отображает данные из $arResult.
- Вся верстка, стили, вывод значений на экран находятся именно здесь (либо частично — в подключаемых файлах).
(Опционально) component_epilog.php
- Находится в папке шаблона.
- Вызывается после рендеринга шаблона.
- Используется для выполнения пост-действий, которые не влияют на отображение (логирование, подсчет статистики, отправка уведомлений и прочее).

3. `result_modifier.php`: для чего нужен и как работает

3.1. Общая идея

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

В реальных проектах это нужно, чтобы:

Добавить или убрать поля, пришедшие из базы.
Провести фильтрацию (например, скрыть неактуальные элементы).
Собрать в удобную для вывода структуру (убрать вложенные массивы, объединить данные в один массив и т.д.).

3.2. Место в цепочке

Логика в component.php или class.php сначала формирует $arResult.
После выполнения основной логики (и, при необходимости, кеширования) подключается result_modifier.php.
Итоговая версия $arResult с учётом изменений попадает в template.php.

3.3. Особенности кеширования

Кеш, как правило, контролируется кодом в component.php или class.php. При этом result_modifier.php учитывается как часть шаблона.
Если вы включаете кеш и вносите изменения в result_modifier.php, то при последующих запросах может выдаваться старый кеш. Нужно либо сбрасывать кеш, либо явно настраивать зависимость кеша от тех данных, которые вы меняете.

3.4. Пример кода (классический подход)


// /local/components/my_component/templates/.default/result_modifier.php

// $arResult пришел из component.php
// Допустим, хотим отфильтровать товары по цене
foreach ($arResult['ITEMS'] as $key => $item) {
    if ($item['PRICE'] < 100) {
        unset($arResult['ITEMS'][$key]);
    }
}

// Добавим поле
$arResult['COUNT'] = count($arResult['ITEMS']);

3.5. Пример кода (новый D7-подход)


// /local/components/my_component/templates/.default/result_modifier.php

// $arResult и $arParams получены из class.php, где у нас:
// class MyComponent extends CBitrixComponent { 
//     public function executeComponent() {
//         // ...
//         $this->arResult = [...]; // формируем массив
//         $this->includeComponentTemplate(); // вызываем шаблон
//     }
// }

foreach ($arResult as $key => $item) {
    // Например, добавим "OLD_PRICE"
    $arResult[$key]["OLD_PRICE"] = $item["PRICE"] * 1.2;
}

4. `component_epilog.php`: когда он нужен

4.1. Основная идея

component_epilog.php вызывается после вывода шаблона (template.php). То есть, это место для логики, которая:

Уже не влияет на контент, но должна выполниться “по следам” работы компонента.
Может собирать статистику, писать логи, обновлять счётчики, работать с сессиями и т.п.

4.2. Место в цепочке

Сначала код компонента (либо component.php, либо class.php).
(Опционально) result_modifier.php.
Шаблон template.php — формируется и выводится HTML.
(Опционально) component_epilog.php.

4.3. Особенности кеширования

Как правило, HTML-вывод уже готов и закэширован, поэтому изменения, сделанные в component_epilog.php, не отображаются непосредственно на странице.
Однако если вы делаете что-то, что всё-таки влияет на контент (например, вставляете динамический скрипт), нужно учитывать особенности кеширования. Чаще всего для таких вставок используют дополнительные механизмы (AJAX, динамические области).

4.4. Пример использования


// /local/components/my_component/templates/.default/component_epilog.php

// Здесь нам доступен $arResult, $arParams, $component
// Допустим, мы записываем логи о том, сколько товаров было отображено

$logFile = $_SERVER['DOCUMENT_ROOT'].'/upload/log.txt';
$countItems = $arResult["COUNT"] ?? 0;
$time = date("Y-m-d H:i:s");
$logString = "[$time] Показано товаров: $countItems\n";

file_put_contents($logFile, $logString, FILE_APPEND);

5. Где формируется `$arResult`?

5.1. Классический подход (`component.php`)

В component.php вы пишете логику запроса к БД, работы с API, формируете $arResult и т.д.
В конце обычно вызывается $this->IncludeComponentTemplate() (если вы внутри класса) или просто includeComponentTemplate() (если используете процедурный стиль).


// Пример (упрощённый):
if($this->StartResultCache()) {
    // Достаём из БД список элементов
    $arResult = getSomeData(); 
    $this->IncludeComponentTemplate();
}

5.2. Новый подход (D7, `class.php`)

У вас есть класс, унаследованный от CBitrixComponent, где вы переопределяете метод executeComponent().
Там вы формируете $this->arResult, а потом делаете $this->includeComponentTemplate().


class MyComponent extends CBitrixComponent
{
    public function executeComponent()
    {
        if ($this->startResultCache()) {
            // Получаем данные
            $this->arResult = getSomeData();
            // ...
        }
        $this->includeComponentTemplate();
    }
}

Важно: с точки зрения запуска result_modifier.php и component_epilog.php, ничего принципиально не меняется — это по-прежнему файлы шаблона, которые вызываются до и после template.php.

6. Когда применять `result_modifier.php` и `component_epilog.php`, а когда — нет

6.1. Когда стоит использовать `result_modifier.php`

Вам нужно изолировать/упростить логику преобразования $arResult, не запихивая лишний код в шаблон.
Нужно, чтобы сам шаблон оставался “чистым” и занимался только выводом.
Изменение структуры, ключей $arResult или подключение дополнительной информации из других источников перед рендерингом.

6.2. Когда стоит использовать `component_epilog.php`

Нужно выполнить пост-обработку (логирование, метрики, пост-обратные вызовы).
Вы уверены, что это не повлияет на отображение текущего компонента.

6.3. Когда эти файлы могут быть лишними

Если код компонента достаточно простой, и нет сложных преобразований данных — тогда всё можно сделать в самом class.php/component.php и template.php.
Если нет необходимости в пост-действиях, component_epilog.php не нужен.
Если вывод уже формируется через AJAX, где у вас есть своя логика формирования JSON-ответов, иногда удобнее всю обработку делать на стороне PHP-контроллера, не трогая “стандартную” структуру файлов.

7. Кеширование: общий взгляд

Независимо от того, используется ли component.php или class.php, управление кешем остаётся схожим:

Вызывается startResultCache() с некоторым временем кеша или зависимостями.
Если кеш актуален, код внутри startResultCache() не выполняется повторно, а берётся готовый результат.
Если кеш неактуален, код выполняется заново, формируется $arResult, вызывается result_modifier.php, а итоговый результат сохраняется в кеш.
При последующих запросах, пока кеш действует, конечные данные берутся из кеша.

Если вы вносите правки в логику result_modifier.php или в саму структуру $arResult, чтобы увидеть изменения, нужно:

Сбросить кеш (например, в административной части Битрикс).
Либо добавить условия, которые принудительно сбрасывают кеш при изменении входных данных.

8. Рекомендации по структуре проекта

Старайтесь использовать новый подход (D7) при создании новых компонентов.
Это даёт гибкость, позволяет удобно использовать ООП, наследовать базовые классы, писать юнит-тесты и т.д.
Не перегружайте class.php мелочными преобразованиями, если они логичнее смотрятся в result_modifier.php.
В class.php (или component.php) формируйте “сырые” данные; все “косметические” преобразования делайте в result_modifier.php.
Если у вас в template.php много “сложного” кода, старайтесь часть этого кода перенести в result_modifier.php, чтобы шаблон был более читаемым.
Используйте component_epilog.php для сервисных задач (логирование, метрики), особенно когда это не влияет на отображение.
Вопросы кеширования продумывайте заранее. Если логика “тяжёлая”, но при этом частично зависит от динамических данных (например, пользовательских), возможно, стоит разбить функционал на кешируемую часть и отдельные AJAX-запросы.

9. Заключение

Файлы result_modifier.php и component_epilog.php — это универсальные механизмы в 1С-Битрикс, которые работают одинаково как в классической структуре (через component.php), так и в новом подходе (через class.php):

result_modifier.php — для изменения $arResult до вывода,
component_epilog.php — для выполнения любых действий после вывода.

Переход на “новое ядро” (D7) меняет место, где вы пишете основную логику компонента (теперь это метод executeComponent() в class.php), но не отменяет и не меняет назначение файлов в шаблоне. С их помощью вы можете разгрузить шаблон от лишнего кода, отделить бизнес-логику от логики оформления и реализовать любые пост-действия удобным, структурированным образом.

Если вы всё ещё не применяете эти файлы, но чувствуете потребность в более гибком и “чистом” подходе к написанию компонентов, самое время заняться их изучением и практической реализацией. В конечном счёте это улучшит читаемость и поддержку кода, а также поможет правильно работать с кешированием в 1С-Битрикс.

Надеемся, что эта статья помогла вам разобраться, когда и как правильно использовать result_modifier.php и component_epilog.php. Успешной разработки на 1С-Битрикс!

Теги: Битрикс, справочник