Доробка стандартних компонентів через component_epilog в 1С-Бітрікс
Часто завдання виходять за межі стандартної логіки компонента. У 80% проєктів ми використовуємо component_epilog.php для впровадження аналітики та збору метрик без порушення кешування. Це економить в середньому 4 години на один компонент і спрощує підтримку — жодних костилів у template.php. Проблема: стандартні компоненти Бітрікс з увімкненим кешем не виконують result_modifier.php, а отже, аналітика та лічильники перестають працювати коректно на кешованих сторінках.
Файл component_epilog.php вирішує цю проблему без вимкнення кешу. Наші інженери за 8 років роботи з платформою реалізували понад 200 компонентних доробок з використанням епілогу — від простої аналітики до складної інтеграції із зовнішніми CRM-системами. Такий підхід забезпечує стабільність роботи компонента, зберігає продуктивність за рахунок кешування шаблону та дозволяє додавати функціонал без правки ядра. Це офіційно рекомендований спосіб доробки від вендора платформи 1С-Бітрікс, який застосовується в enterprise-проєктах.
Місце в послідовності виконання
-
component.php— логіка, заповнює$arResult -
result_modifier.php— модифікація$arResultдо рендеру -
template.php— рендер HTML -
component_epilog.php— після рендеру: дії, JS, аналітика
Файл знаходиться в папці шаблону компонента: /local/templates/{site_template}/components/bitrix/catalog.element/default/component_epilog.php
Чим component_epilog відрізняється від result_modifier
| result_modifier | component_epilog | |
|---|---|---|
| Коли виконується | До рендеру шаблону | Після рендеру шаблону |
Доступний $arResult |
Так, для зміни | Так, лише для читання |
| Впливає на HTML компонента | Так (через $arResult) |
Ні |
| Виконується при кеші | Ні (дані беруться з кешу) | Так, завжди |
| Для JS і аналітики | Ні | Так |
| Для побічних ефектів | Ні | Так |
Ключова відмінність: 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(),
]);
});
}
Сценарії використання
| Задача | Рішення | Складність |
|---|---|---|
| Аналітика | Вставка JS-подій через epilog | Низька |
| Лічильники переглядів | Запис в Redis/MySQL через чергу | Середня |
| Супутні товари | Підключення доп. компонента | Середня |
| Логування кошика | register_shutdown_function |
Низька |
Типові помилки при використанні component_epilog
Натисніть, щоб розгорнути
- Забули перевірити AJAX-запит — дублювання JS на кожному ajax-кроці кошика.
- Намагаєтесь змінити
$arResult— не працює, використовуйтеresult_modifier. - Вставляєте важку логіку в 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, звичайний запит).
- Документація з підтримки.
Процес оцінки та роботи
- Збір даних — вивчаємо ваш поточний компонент та бізнес-вимоги.
- Аудит — аналізуємо точки розширення, кешування, AJAX-сценарії.
- Проектування — пропонуємо архітектуру epilog-файлу.
- Оцінка — надаємо вартість та терміни після аналізу.
- Розробка — пишемо код, інтегруємо з вашими системами.
- Тестування — перевіряємо на всіх режимах (кеш, AJAX, без кешу).
- Запуск — розгортаємо на production, передаємо документацію.
Орієнтири за термінами
Терміни залежать від складності: від 3 робочих днів для типової задачі до 2 тижнів для комплексної інтеграції. Точні терміни визначаються після аналізу. Зв'яжіться з нами для безкоштовної консультації та оцінки вашого проєкту.