Доробка стандартних компонентів через 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 тижнів для комплексної інтеграції. Точні терміни визначаються після аналізу. Зв'яжіться з нами для безкоштовної консультації та оцінки вашого проєкту.