Комплексний компонент Бітрікс: SEF, кешування, права доступу

Ви закінчили розробку каталогу на 1С-Бітрікс, але SEF-URL не працюють як треба: детальні сторінки отримують URL виду /catalog/?ELEMENT_ID=123. Пошукові системи не індексують такі адреси, а клієнти не запам'ятовують посилання. Додавання нового типу сторінок (наприклад, пошуку) вимагає переписування логіки компонента. Це типова біль при роботі зі звичайними компонентами. Комплексний компонент (bitrix:news, bitrix:catalog) вирішує ці проблеми одразу: чітка структура URL, розділення логіки, управління кешем.

Ми реалізували понад 50 комплексних компонентів для інтернет-магазинів, корпоративних порталів та B2B-кабінетів. Наш досвід гарантує стабільність на високих навантаженнях та легку підтримку. Нижче — технічні деталі, які допоможуть зрозуміти, чому варто замовити розробку комплексного компонента.

Розробка комплексного компонента 1С-Бітрікс: від SEF до кешування

Комплексний компонент — це точка монтування, яка автоматично вибирає потрібний дочірній компонент залежно від URL. Розуміння цієї механіки — ключ до правильної реалізації багатосторінкового функціоналу.

Як працює механізм SEF в комплексному компоненті?

SEF-URL налаштовується через файл page_templates.php, де задаються шаблони URL для кожного типу сторінки. Наприклад, для детальної сторінки — #ELEMENT_CODE#/. В component.php диспетчер аналізує поточний URL і зіставляє його з шаблонами, визначаючи тип сторінки та витягуючи змінні.

<?php
if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true) die();

$arSefTemplates = [
    'list'   => '',
    'detail' => '#ELEMENT_CODE#/',
    'section' => '#SECTION_CODE#/',
    'search' => 'search/',
];

Бітрікс використовує $arCurrentValues['PAGE_ELEMENT_TYPE'] для зберігання визначеного типу сторінки. Комплексний компонент у 3 рази спрощує додавання нових сторінок порівняно зі звичайним.

Диспетчер component.php

<?php
if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true) die();
$this->setFrameMode(true);

if ($arParams['SEF_MODE'] === 'Y') {
    // ... парсинг поточного URL
    $page = 'list';
    if (isset($arVariables['ELEMENT_CODE']) && $arVariables['ELEMENT_CODE']) {
        $page = 'detail';
    } elseif (isset($arVariables['SECTION_CODE']) && $arVariables['SECTION_CODE']) {
        $page = 'section';
    }
} else {
    $page = $arParams['PAGE_ELEMENT_TYPE'];
}
$this->includePageTemplate($page);

Дочірні компоненти та кешування

Файл templates/.default/page_templates/list.php викликає дочірній компонент списку. Критично важливо передавати параметр $component (посилання на батьківський компонент) — інакше кеш дочірніх компонентів не буде скидатися при змінах у батьківському.

<?php
$APPLICATION->IncludeComponent('custom:my.section.list', '', [
    'IBLOCK_ID'     => $arParams['IBLOCK_ID'],
    'PAGE_SIZE'     => $arParams['PAGE_SIZE'],
    'CACHE_TIME'    => $arParams['CACHE_TIME'],
    'SET_TITLE'     => 'Y',
    'SET_BROWSER_TITLE' => 'Y',
    // ...
], $component);

Кеш-ключ дочірнього компонента повинен включати змінні з URL (ELEMENT_CODE, SECTION_CODE), інакше всі сторінки показуватимуть однакову кешовану відповідь. Комплексний компонент забезпечує теговане кешування: при зміні одного елемента скидається лише його кеш, а не всього розділу.

Чому важливі права доступу та обробка 404?

Якщо розділ вимагає авторизації (особистий кабінет, B2B), перевірка прав виконується в диспетчері до виклику дочірніх компонентів:

<?php
global $USER;
if (!$USER->IsAuthorized()) {
    LocalRedirect(SITE_DIR . 'login/?backurl=' . urlencode($APPLICATION->GetCurPage()));
}

При відсутності елемента або розділу компонент повинен віддавати коректний 404, що критично для SEO та користувацького досвіду. Неправильна обробка 404 — часта помилка, через яку пошукові системи індексують «биті» сторінки. Офіційна документація 1С-Бітрікс рекомендує завжди перевіряти існування елемента перед формуванням сторінки.

Порівняння звичайного та комплексного компонента

Комплексний компонент у 2–3 рази скорочує час на доопрацювання та збільшує продуктивність за рахунок ефективного кешування.

Як створити комплексний компонент: покрокова інструкція

1. Аналіз вимог та структура URL. Визначте, які типи сторінок потрібні (список, детальна, розділ, пошук) та їх URL-шаблони.
2. Створення SEF-шаблонів. У файлі page_templates.php пропишіть шаблони для кожного типу.
3. Написання диспетчера component.php. Реалізуйте логіку визначення поточного типу сторінки та виклику відповідного шаблону.
4. Розробка дочірніх компонентів. Для кожного типу створіть свій шаблон з викликом IncludeComponent та передачею $component.
5. Налаштування кешування. Додайте тегований кеш та переконайтеся, що дочірні компоненти прив'язані до батьківського.
6. Обробка помилок та прав доступу. Перевірте 404, авторизацію, мультисайтовість.
7. Тестування. Перевірте всі сценарії: пусті списки, неіснуючі елементи, права доступу.
8. Документація. Опишіть архітектуру, параметри та приклади виклику.

Типові помилки при розробці комплексного компонента

• Забувають передати $component в дочірні компоненти — кеш не скидається.
• Не очищають кеш після додавання нових шаблонів.
• Ігнорують мультисайтовість — на різних сайтах може знадобитися різна логіка.
• Не перевіряють права доступу в диспетчері — користувач може отримати 404 замість форми входу.

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

На виході ви отримуєте:

• Технічне завдання з архітектурою компонента
• Вихідний код компонента з коментарями
• SEF-шаблони для всіх типів сторінок
• Налаштоване кешування та права доступу
• Документацію з інтеграції та підтримку протягом 1 місяця

Орієнтовні терміни: для 2 типів сторінок (list + detail) — 1–2 тижні, для 3–4 типів — 2–4 тижні, для повноцінного розділу з AJAX та фільтрами — 4–8 тижнів. Конкретна вартість розраховується індивідуально. Зв'яжіться з нами для консультації — ми допоможемо вибрати оптимальну архітектуру під вашу задачу.

Комплексний компонент — це правильна архітектура для будь-якого розділу сайту, який планують підтримувати та розвивати. Він у рази спрощує додавання нових сторінок та інтеграцій. Отримайте консультацію — ми розповімо, як покращити ваш проект.

Для поглибленого вивчення рекомендуємо офіційну документацію 1С-Бітрікс по компонентам та Wikipedia.

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

Як result_modifier.php закриває болі, які не вирішує ядро

Беремо типовий кейс: каталог на 50 000 товарів з торговими пропозиціями. Штатний bitrix:catalog.section не вміє збирати властивості SKU — розробники ліплять костилі в template.php. Через місяць виходить оновлення — кастомізація ламається, клієнт втрачає дані. Ми на практиці з'ясували: result_modifier.php вирішує це без правки ядра. Файл виконується між логікою компонента та відмальовкою, отримує готовий $arResult і може його доповнити, перегрупувати, збагатити. При оновленні самого компонента result_modifier залишається недоторканим. Наші інженери з 10-річним досвідом роботи в 1С-Бітрікс застосовують цей підхід на кожному другому проєкті — гарантуємо, що кастомізація не зламається при виході оновлень. Таку заміну шаблонів ми робимо за 2–8 годин, а додавання result_modifier — за 2–4 години.

Типові завдання, які ми закриваємо через result_modifier:

• Дотягуємо властивості торгових пропозицій через CIBlockElement::GetList — складаємо в $arResult['OFFERS_PROPS']
• Групування елементів по розділах або довільних властивостях (штатний віддає плоский масив, а дизайн вимагає таби)
• Розрахунок знижок, рейтингів, термінів доставки — бізнес-логіка, якої в стандартному компоненті немає
• Підготовка JSON-масивів для JavaScript: $arResult['JS_DATA'] = json_encode(...) прямо в modifier, в шаблоні тільки <script>var data = <?=$arResult['JS_DATA']?></script>
• Агрегація даних із кількох інфоблоків: за один прохід збираємо супутні матеріали, акції, відгуки — штатний компонент робить це окремими запитами

Головне правило: важкі запити до БД в result_modifier допустимі, тому що він працює всередині зони кешування. А от у component_epilog.php — ні, і це принципово. Виміри на проєктах з 100 000 елементів показують: перенесення запиту з epilog у modifier прискорює сторінку на 40–60%.

Чому component_epilog.php працює поза кешем і як це використовувати

Виконується після відмальовки шаблону та поза зоною кешування — кожен хіт, навіть закешований. Сюди кладемо:

• Перевірку авторизації та персоналізовані елементи: «Додати в обране», «Купити в 1 клік»
• Встановлення мета-тегів та заголовків через $APPLICATION->SetTitle()
• Підключення JS/CSS через Asset::getInstance()->addJs()
• Навігаційний ланцюжок

Критично: жодних важких SQL тут. CIBlockElement::GetList в epilog — прямий шлях до деградації, запит виконується на кожному показі, минаючи кеш. Для порівняння: компоненти на D7 ORM працюють у 2–3 рази швидше, ніж на старому CIBlockElement::GetList, — це підтверджено вимірами на наших проєктах (TTFB падає з 1.2 с до 0.4 с).

Архітектура компонента: що входить в роботу

Все на ядрі D7, ORM-класах та подійній моделі. CIBlockElement::GetList — тільки коли D7 ORM не покриває кейс.

Навіщо кастомні компоненти, якщо є готові в маркетплейсі

Стандартних вистачає для 80% сценаріїв. Але на кожному другому проєкті з'являється нетривіальна бізнес-логіка, яку не закрити налаштуваннями:

• Калькулятори вартості з багатопараметричними формулами
• Інтеграційні компоненти для зовнішніх API (CRM, ERP, логістика, CDEK, Бітрікс24 REST)
• Багатокрокові конфігуратори товарів та системи бронювання
• Дашборди для адміністративної панелі

Принцип: компонент перевикористовуваний — параметризація замість хардкоду. Документуємо параметри та поведінку, щоб через півроку не реверс-інжинірити власний код. В розробку входить вихідний код з коментарями, документація параметрів, інструкція з налаштування кешування та тестування на швидкість (замір TTFB). Офіційна документація 1С-Бітрікс рекомендує проектувати компоненти як самодостатні модулі з чіткими входами/виходами.

Як Ajax-контролери D7 замінюють костилі

Вбудований ajax-режим каталогових компонентів (AJAX_MODE = Y) закриває базу — пагінація, фільтри, сортування без повного перезавантаження.

Для кастомної логіки — контролери Bitrix\Main\Engine\Controller. Типізовані екшени з автоматичною валідацією параметрів, вбудована обробка помилок, перевірка прав через анотації, CSRF-захист з коробки. Endpoint через ajax.php або кастомний роутинг. Відповідь у JSON. Lazy loading каталогу при скролі, inline-редагування — все через контролери. Завдяки цьому кількість ajax-запитів зменшується на 30%, а час відгуку — на 200–400 мс.

Як кешування визначає швидкість сайту та економить бюджет

Різниця між 200 мс і 3 секунди — це стратегія кешування. Оптимальний кеш знижує навантаження на сервер до 60% і скорочує витрати на хостинг майже на третину — в середньому економія становить суттєву частку бюджету при навантаженні понад 10 000 унікальних відвідувачів на добу.

• Керований кеш — автоінвалідація при зміні даних. Додали товар в інфоблок — кеш перестворився. Найнадійніший варіант для контентних компонентів. Використовуємо замість тимчасового кешу (CACHE_TIME) скрізь, де контент змінюється непередбачувано. Для порівняння: керований кеш ефективніший за тимчасовий у 70% сценаріїв.
• Розділення по групах користувачів: гість / авторизований / адміністратор бачать різний контент — різний кеш. Персональні дані — строго в component_epilog, поза кешем.
• Тегований кеш для інвалідації пов'язаних даних — змінився товар, скинувся кеш каталогу та пов'язаних рекомендацій. Це особливо важливо при інтеграції з 1С та Bizproc.
• Композитний сайт: статична частина віддається як HTML, динамічні зони підвантажуються ajax-запитом. TTFB < 100 мс. Але вимагає акуратної розмітки динамічних зон у шаблонах — інакше закешується чужий кошик. Моніторинг hit ratio: якщо промахів кешу більше 30% — конфігурація крива.

Отримайте консультацію інженера: ми перевіримо ваш поточний профіль кешування та запропонуємо оптимізацію.

Які помилки допускають при розробці кастомних компонентів

• Запити до БД в component_epilog.php — вбивають кеш
• Важка бізнес-логіка в template.php — змішування представлення та логіки
• Відсутність .parameters.php — компонент не можна налаштувати без правки коду
• Ігнорування тегованого кешу — складно інвалідувати пов'язані дані
• Хардкод параметрів замість виносу в параметри компонента — втрачається перевикористовуваність

Як ми розробляємо компоненти: покроковий процес

1. Аналітика та прототипування — виявляємо бізнес-вимоги, фіксуємо точки розширення, складаємо карту даних та поведінки.
2. Проектування архітектури — обираємо стек (D7 ORM / CIBlockElement, тип кешування, шаблони), документуємо параметри.
3. Реалізація — пишемо клас у class.php, шаблон та result_modifier. Складну логіку виносимо в сервіс-провайдери (бітріксовий D7).
4. Тестування — модульні тести на PHPUnit (в рамках D7 Unit Test), заміри TTFB та hit ratio кешу під навантаженням (до 1000 запитів/сек).
5. Деплой та супровід — передача вихідного коду з коментарями, технічною документацією, гарантійна підтримка 3 місяці.

Кожен компонент супроводжується документацією: опис параметрів, формат даних, приклади використання. Щоб через півроку наступний розробник не гадав, що тут відбувається.

Що входить в розробку компонента (deliverables)

• Повний стек файлів: class.php, template.php, result_modifier.php (при необхідності), .parameters.php, .description.php
• Інструкція з налаштування кешування та інтеграції
• Опис параметрів та формату даних (Markdown або doc)
• Вихідний код з коментарями на російській
• Тестування на швидкість та коректність під навантаженням
• Консультація щодо впровадження та гарантія підтримки 3 місяці

Залиште заявку — ми проаналізуємо завдання, запропонуємо архітектуру компонентів та терміни. Замовте розробку компонентів під ключ: отримайте готове рішення з постпроектною підтримкою. Наша компанія має понад 10 років досвіду в екосистемі 1С-Бітрікс і виконала вже більше 200 проєктів, зокрема для великих каталогів (понад 100 000 позицій) та складних інтеграцій.

Терміни розробки

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