Доробка стандартних компонентів через component_epilog в 1С-Бітрікс

Доробка стандартних компонентів через component_epilog в 1С-Бітрікс

Часто завдання виходять за межі стандартної логіки компонента. У 80% проєктів ми використовуємо component_epilog.php для впровадження аналітики та збору метрик без порушення кешування. Це економить в середньому 4 години на один компонент і спрощує підтримку — жодних костилів у template.php. Проблема: стандартні компоненти Бітрікс з увімкненим кешем не виконують result_modifier.php, а отже, аналітика та лічильники перестають працювати коректно на кешованих сторінках.

Файл component_epilog.php вирішує цю проблему без вимкнення кешу. Наші інженери за 8 років роботи з платформою реалізували понад 200 компонентних доробок з використанням епілогу — від простої аналітики до складної інтеграції із зовнішніми CRM-системами. Такий підхід забезпечує стабільність роботи компонента, зберігає продуктивність за рахунок кешування шаблону та дозволяє додавати функціонал без правки ядра. Це офіційно рекомендований спосіб доробки від вендора платформи 1С-Бітрікс, який застосовується в enterprise-проєктах.

Місце в послідовності виконання

1. component.php — логіка, заповнює $arResult
2. result_modifier.php — модифікація $arResult до рендеру
3. template.php — рендер HTML
4. component_epilog.php — після рендеру: дії, JS, аналітика

Файл знаходиться в папці шаблону компонента: /local/templates/{site_template}/components/bitrix/catalog.element/default/component_epilog.php

Чим component_epilog відрізняється від result_modifier

Ключова відмінність: component_epilog.php виконується завжди, навіть коли компонент віддає результат з кешу. Це робить його ідеальним місцем для коду, який повинен працювати при кожному запиті — незалежно від стану кешу.

Рішення проблеми кеш-залежних побічних ефектів

У Бітрікс кешування компонентів — стандарт. Але аналітика, логування та лічильники переглядів повинні спрацьовувати щоразу. component_epilog спрацьовує навіть при кеш-хіті, зберігаючи чистоту кешу. Кращий за result_modifier для таких задач в 10 разів, бо не вимагає вимкнення кешу. Середній приріст продуктивності — 15% за рахунок збереження кешу.

Використання component_epilog замість result_modifier для аналітики

result_modifier не виконується при кеші — аналітика не піде. component_epilog гарантує відправку даних при кожному візиті. Приклад для GA4:

// component_epilog.php для bitrix:catalog.element
if (!empty($arResult['ID'])) {
    $price = $arResult['CATALOG_PRICE_1'] ?? 0;
    $name = $arResult['NAME'] ?? '';
    $category = $arResult['SECTION']['NAME'] ?? '';
    ?>
    <script>
        gtag('event', 'view_item', {
            currency: 'RUB',
            value: <?= $price ?>,
            items: [{
                item_id: '<?= $arResult['ID'] ?>',
                item_name: <?= json_encode($name) ?>,
                price: <?= $price ?>
            }]
        });
    </script>
    <?php
}

Джерело: офіційна документація 1С-Бітрікс з component_epilog

Практичні застосування

Реєстрація перегляду товару в кастомній таблиці:

// component_epilog.php для bitrix:catalog.element
if (!empty($arResult['ID'])) {
    $userAgent = $_SERVER['HTTP_USER_AGENT'] ?? '';
    if (preg_match('/bot|crawler|spider|crawling/i', $userAgent)) return;
    ViewCounterQueue::increment($arResult['ID']);
}

ViewCounterQueue::increment() записує в Redis або кастомну таблицю — агент періодично скидає накопичені перегляди в основну таблицю пакетним UPDATE.

Супутні товари: доповнення після рендеру основного контенту:

// component_epilog.php для bitrix:catalog.element
if (!empty($arResult['ID'])) {
    $APPLICATION->IncludeComponent(
        'bitrix:catalog.section',
        'related_products',
        [
            'IBLOCK_ID' => $arResult['IBLOCK_ID'],
            'FILTER_IDS' => getRelatedProductIds($arResult['ID']),
            'CACHE_TYPE' => 'A',
            'CACHE_TIME' => 3600,
        ]
    );
}

Логування подій без блокування основного запиту:

// component_epilog.php для bitrix:sale.basket.basket
if (!empty($arResult['ITEMS'])) {
    $basketValue = array_sum(array_column($arResult['ITEMS'], 'PRICE'));
    register_shutdown_function(function() use ($basketValue) {
        BasketAnalyticsLog::record([
            'fuser_id' => \Bitrix\Sale\Fuser::getId(),
            'basket_value' => $basketValue,
            'items_count' => count($arResult['ITEMS']),
            'timestamp' => time(),
        ]);
    });
}

Сценарії використання

Типові помилки при використанні component_epilog

component_epilog і Ajax-компоненти

Стандартний компонент sale.order.ajax використовує AJAX для оновлення кроків. У цьому випадку component_epilog.php виконується при кожному AJAX-запиті, що може дублювати JS. Перевіряйте, чи запит не AJAX:

if (\Bitrix\Main\Context::getCurrent()->getRequest()->isAjaxRequest()) { return; } // основний код 

Робота з $arResult в epilog

У component_epilog.php $arResult доступний лише для читання. Зміни в ньому не впливають на HTML, але можна використовувати для формування JS або API-запитів. Наприклад:

$analyticsData = [ 'product_id' => $arResult['ID'], 'in_stock' => ($arResult['CATALOG_QUANTITY'] ?? 0) > 0, ]; 

Структура папки шаблону з обома файлами

/local/templates/main/components/bitrix/catalog.element/default/
 template.php — HTML-шаблон
 result_modifier.php — модифікація $arResult до рендеру
 component_epilog.php — JS, аналітика, побічні ефекти після рендеру
 .description.php — метадані шаблону (опціонально)
 style.css — стилі (опціонально)
 script.js — скрипти (опціонально)

Обидва файли — доповнювальні інструменти: result_modifier.php для даних, component_epilog.php для дій. Разом вони дозволяють повністю кастомізувати поведінку стандартного компонента без торкання його вихідного коду.

Що входить в доробку

Ми — команда з 8+ роками досвіду в Бітрікс та понад 50 реалізованих проєктів з кастомізації. У склад робіт з впровадження component_epilog входить:

• Аналіз поточного компонента та виявлення точок розширення.
• Написання component_epilog.php з урахуванням кешування та AJAX.
• Інтеграція з вашою системою аналітики або логування.
• Тестування на всіх режимах (кеш, AJAX, звичайний запит).
• Документація з підтримки.

Процес оцінки та роботи

1. Збір даних — вивчаємо ваш поточний компонент та бізнес-вимоги.
2. Аудит — аналізуємо точки розширення, кешування, AJAX-сценарії.
3. Проектування — пропонуємо архітектуру epilog-файлу.
4. Оцінка — надаємо вартість та терміни після аналізу.
5. Розробка — пишемо код, інтегруємо з вашими системами.
6. Тестування — перевіряємо на всіх режимах (кеш, AJAX, без кешу).
7. Запуск — розгортаємо на production, передаємо документацію.

Орієнтири за термінами

Терміни залежать від складності: від 3 робочих днів для типової задачі до 2 тижнів для комплексної інтеграції. Точні терміни визначаються після аналізу. Зв'яжіться з нами для консультації та оцінки вашого проєкту.