Послуги з розробки компонентів 1С-Бітрікс

Розробка компонентів Бітрікс

result_modifier.php — найнедооціненіший файл у Бітрікс

Почнемо з того, про що більшість бітріксоїдів дізнаються через рік роботи. result_modifier.php сидить у папці шаблону компонента і виконується між логікою компонента та відмальовкою template.php. Він отримує заповнений $arResult і може його доповнити, перегрупувати, збагатити — і при цьому при оновленні самого компонента файл залишається недоторканим.

Реальні задачі, які через нього вирішуємо постійно:

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

Головне правило: важкі запити до БД у result_modifier допустимі, тому що він працює всередині зони кешування. А ось у component_epilog.php — ні.

component_epilog.php — поза кешем, і в цьому сила

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

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

Критично: жодних важких SQL тут. CIBlockElement::GetList у epilog — прямий шлях до деградації, тому що запит виконуватиметься на кожному показі сторінки, обминаючи кеш.

Архітектура компонента

Компонент — самодостатній модуль:

• class.php — ООП-клас, що наслідує CBitrixComponent. Бізнес-логіка, вибірка даних, валідація параметрів. У нових компонентах використовуємо лише його, component.php — процедурний пережиток.
• template.php — чистий HTML + $arResult. Жодної бізнес-логіки.
• .parameters.php — опис вхідних параметрів для адмінки.
• .description.php — метадані: назва, категорія, іконка.

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

Кастомні компоненти

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

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

Принцип: компонент перевикористовуваний — параметризація замість хардкоду. Документуємо параметри та поведінку, щоб через півроку не реверс-інженерити власний код.

Ajax: контролери D7

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

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

Кешування — визначає швидкість сайту

Різниця між 200 мс та 3 секунди — це стратегія кешування.

Керований кеш — автоінвалідація при зміні даних. Додали товар в інфоблок — кеш перестворився. Найнадійніший варіант для контентних компонентів. Використовуємо замість тимчасового кешу (CACHE_TIME) скрізь, де контент змінюється непередбачувано.

Розділення за групами користувачів: гість / авторизований / адміністратор бачать різний контент — різний кеш. Персональні дані — суворо в component_epilog, поза кешем.

Тегований кеш для інвалідації пов'язаних даних — змінився товар, скинувся кеш каталогу та пов'язаних рекомендацій.

Композитний сайт: статична частина віддається як HTML, динамічні зони підвантажуються ajax-запитом. TTFB < 100 мс. Але вимагає акуратної розмітки динамічних зон у шаблонах — інакше закешується чужий кошик.

Моніторинг hit ratio: якщо промахів кешу більше 30% — конфігурація крива.

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

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