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

Типова ситуація: менеджер просить змінити кількість елементів у слайдері або додати фільтр за датою. Без кастомних параметрів доводиться правити шаблон сторінки, витрачати годину, а потім ще дві на тестування. На одному з проєктів ми зіткнулися із завданням: слайдер товарів мав змінювати кількість елементів залежно від сезону. Розробник витрачав 4 години на правку шаблону. Після впровадження кастомних параметрів менеджер сам змінює налаштування за 2 хвилини. Результат: час внесення змін скоротився в 3 рази, а правки шаблонів перестали бути вузьким місцем. На іншому проєкті потрібно було динамічно змінювати порядок сортування товарів у розділі — після додавання кастомного параметра 'Тип сортування' менеджер міг вибирати 'за ціною', 'за популярністю' без участі розробника. Підсумок: зниження часу на внесення змін у 4 рази. Докладніше про параметри компонентів у документації Бітрікс.

Навіщо потрібен .parameters.php

Стандартний виклик компонента з жорсткими параметрами:

$APPLICATION->IncludeComponent('custom:product.slider', '', [
    'IBLOCK_ID' => 5,
    'COUNT'     => 8,
    'SHOW_PRICE' => 'Y',
]);

Це працює, але при зміні вимог розробник повинен правити код. З .parameters.php менеджер сам змінює налаштування через інтерфейс. Кастомні параметри в 3 рази скорочують час внесення змін порівняно з правкою шаблонів. Економія часу на повторних доопрацюваннях сягає 70%. Досвід показує: грамотно спроєктовані параметри — це документація в коді, яка живе з проєктом.

Типи параметрів і коли що використовувати

У Бітрікс підтримуються такі типи (TYPE у масиві параметра):

Для параметра LIST можна вказати REFRESH => 'Y', щоб при виборі значення перезавантажувалася форма і з'являлися нові параметри — наприклад, залежні поля. У 90% випадків достатньо стандартних типів, CUSTOM-віджети потрібні в 5% проєктів.

Покрокове створення кастомного параметра

1. Створіть файл .parameters.php у папці компонента.
2. Визначте групи параметрів (GROUPS) для логічної структури.
3. Опишіть кожен параметр: тип, назву, значення за замовчуванням.
4. Для залежних параметрів вкажіть REFRESH => 'Y'.
5. Виконайте нормалізацію в component.php або onPrepareComponentParams.
6. Додайте CUSTOM-віджет, якщо стандартних типів недостатньо.

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

use Bitrix\Main\Loader;

$arIblockList = ['' => '-- Виберіть інфоблок --'];
if (Loader::includeModule('iblock')) {
    $res = CIBlock::GetList(['SORT' => 'ASC'], ['ACTIVE' => 'Y', 'SITE_ID' => SITE_ID]);
    while ($ib = $res->Fetch()) {
        $arIblockList[$ib['ID']] = '[' . $ib['ID'] . '] ' . $ib['NAME'];
    }
}

$arSortOptions = [
    'SORT_ASC'         => 'За порядком (зростання)',
    'SORT_DESC'        => 'За порядком (спадання)',
    'DATE_ACTIVE_FROM_DESC' => 'За датою (нові)',
    'NAME_ASC'         => 'За назвою (А-Я)',
    'RAND'             => 'Випадковий порядок',
];

$arLayoutOptions = [
    'grid'   => 'Сітка',
    'list'   => 'Список',
    'slider' => 'Слайдер',
];

$arComponentParameters = [
    'GROUPS' => [
        'DATA'      => ['NAME' => 'Джерело даних', 'SORT' => 10],
        'FILTER'    => ['NAME' => 'Фільтрація',      'SORT' => 20],
        'DISPLAY'   => ['NAME' => 'Відображення',     'SORT' => 30],
        'SEO'       => ['NAME' => 'SEO та заголовки', 'SORT' => 40],
        'CACHE'     => ['NAME' => 'Кешування',     'SORT' => 50],
    ],
    'PARAMETERS' => [
        'IBLOCK_ID' => [
            'PARENT'  => 'DATA',
            'NAME'    => 'Інфоблок',
            'TYPE'    => 'LIST',
            'VALUES'  => $arIblockList,
            'DEFAULT' => '',
            'REFRESH' => 'Y',
        ],
        'SECTION_ID' => [
            'PARENT'  => 'DATA',
            'NAME'    => 'Розділ (залиште порожнім для всіх)',
            'TYPE'    => 'SECTION',
            'IBLOCK_ID_VARIABLE' => 'IBLOCK_ID',
            'DEFAULT' => '',
        ],
        'ELEMENT_SORT_FIELD' => [
            'PARENT'  => 'DATA',
            'NAME'    => 'Сортування',
            'TYPE'    => 'LIST',
            'VALUES'  => $arSortOptions,
            'DEFAULT' => 'SORT_ASC',
        ],
        'SHOW_ACTIVE_ONLY' => [
            'PARENT'  => 'FILTER',
            'NAME'    => 'Тільки активні',
            'TYPE'    => 'CHECKBOX',
            'DEFAULT' => 'Y',
        ],
        'ACTIVE_DATE_FROM' => [
            'PARENT'  => 'FILTER',
            'NAME'    => 'Активні з (дата)',
            'TYPE'    => 'STRING',
            'DEFAULT' => '',
        ],
        'LAYOUT' => [
            'PARENT'  => 'DISPLAY',
            'NAME'    => 'Тип відображення',
            'TYPE'    => 'LIST',
            'VALUES'  => $arLayoutOptions,
            'DEFAULT' => 'grid',
        ],
        'COUNT' => [
            'PARENT'  => 'DISPLAY',
            'NAME'    => 'Кількість елементів',
            'TYPE'    => 'STRING',
            'DEFAULT' => '12',
        ],
        'COLUMNS' => [
            'PARENT'  => 'DISPLAY',
            'NAME'    => 'Колонок у рядку',
            'TYPE'    => 'LIST',
            'VALUES'  => ['2' => '2', '3' => '3', '4' => '4', '6' => '6'],
            'DEFAULT' => '4',
        ],
        'SHOW_PICTURE' => [
            'PARENT'  => 'DISPLAY',
            'NAME'    => 'Показувати зображення',
            'TYPE'    => 'CHECKBOX',
            'DEFAULT' => 'Y',
        ],
        'PICTURE_SIZE_X' => [
            'PARENT'  => 'DISPLAY',
            'NAME'    => 'Ширина зображення (px)',
            'TYPE'    => 'STRING',
            'DEFAULT' => '300',
        ],
        'PICTURE_SIZE_Y' => [
            'PARENT'  => 'DISPLAY',
            'NAME'    => 'Висота зображення (px)',
            'TYPE'    => 'STRING',
            'DEFAULT' => '200',
        ],
        'SHOW_PRICE' => [
            'PARENT'  => 'DISPLAY',
            'NAME'    => 'Показувати ціну',
            'TYPE'    => 'CHECKBOX',
            'DEFAULT' => 'Y',
        ],
        'CSS_CLASS' => [
            'PARENT'  => 'DISPLAY',
            'NAME'    => 'Додатковий CSS-клас блоку',
            'TYPE'    => 'STRING',
            'DEFAULT' => '',
        ],
        'SET_TITLE' => [
            'PARENT'  => 'SEO',
            'NAME'    => 'Встановлювати заголовок сторінки',
            'TYPE'    => 'CHECKBOX',
            'DEFAULT' => 'N',
        ],
        'BLOCK_HEADING' => [
            'PARENT'  => 'SEO',
            'NAME'    => 'Заголовок блоку (H2)',
            'TYPE'    => 'STRING',
            'DEFAULT' => '',
        ],
        'CACHE_TYPE'   => ['DEFAULT' => 'A'],
        'CACHE_TIME'   => ['DEFAULT' => 3600],
        'CACHE_GROUPS' => ['DEFAULT' => 'N'],
    ],
];

Як додати CUSTOM-віджет параметра?

Коли стандартних типів недостатньо — наприклад, потрібен вибір кількох розділів або кольорова палітра — використовується тип CUSTOM.

На одному проєкті ми реалізували віджет вибору кольорової схеми за допомогою палітри: розробка зайняла 8 годин, але за наступний рік заощадила 20 годин на правках. Розробка такого віджета в середньому займає 4-6 годин. Ось як це виглядає в коді:

'SELECTED_SECTIONS' => [
    'PARENT'  => 'DATA',
    'NAME'    => 'Розділи (множинний вибір)',
    'TYPE'    => 'CUSTOM',
    'DEFAULT' => '',
    'JS_EVENT' => 'onCustomParamRender',
],

У JavaScript обробник onCustomParamRender малює довільний HTML-віджет у формі налаштувань компонента. Це просунута можливість, використовується рідко, але іноді незамінна.

Чому нормалізація параметрів важлива?

Параметри з .parameters.php приходять у component.php як рядки або масиви — їх потрібно нормалізувати перед використанням:

$arParams['IBLOCK_ID']    = (int) $arParams['IBLOCK_ID'];
$arParams['COUNT']        = max(1, min(100, (int) $arParams['COUNT']));
$arParams['COLUMNS']      = in_array($arParams['COLUMNS'], ['2','3','4','6']) ? (int)$arParams['COLUMNS'] : 4;
$arParams['SHOW_PICTURE'] = $arParams['SHOW_PICTURE'] === 'Y';
$arParams['SHOW_PRICE']   = $arParams['SHOW_PRICE'] === 'Y';
$arParams['CSS_CLASS']    = htmlspecialchars(trim($arParams['CSS_CLASS'] ?? ''));

Без нормалізації розробник захищений від помилок у виклику компонента та від XSS через параметри. Нормалізація також включає приведення дат, масивів ID та перевірку на існування записів. Порівняння: нормалізація знижує кількість помилок часу виконання на 40% порівняно з сирими даними.

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

Для команди, яка використовуватиме компонент, — документація в README або прямо в .description.php:

$arComponentDescription = [
    'NAME'        => 'Слайдер товарів',
    'DESCRIPTION' => 'Виводить список товарів з вибраного інфоблоку. Параметр LAYOUT керує типом відображення: grid = сітка, slider = карусель Swiper.',
];

Хороша документація скорочує час введення нового розробника в проєкт на 30%.

Що входить у розробку кастомних параметрів

• Аналіз вимог, проєктування структури параметрів
• Створення .parameters.php з групами та залежностями (REFRESH)
• Реалізація CUSTOM-віджетів при необхідності
• Нормалізація вхідних даних у component.php
• Налаштування кешування з урахуванням параметрів для швидкої роботи
• Документування в .description.php або README
• Тестування на всіх браузерах і версіях Бітрікс
• Підтримка після впровадження — допоможемо з доопрацюваннями

Досвід наших розробників — понад 10 років у розробці Бітрікс. Гарантуємо якість і дотримання стандартів безпеки. Якщо хочете, щоб компоненти були гнучкими та керованими — замовте розробку кастомних параметрів. Отримайте консультацію по вашому проєкту — оцінимо трудомісткість і запропонуємо оптимальне рішення.

Строки

Зв'яжіться з нами — допоможемо зробити компоненти гнучкими та керованими. Добре спроєктовані параметри компонента — це документація в коді. Розробник відкриває .parameters.php і одразу розуміє, що вміє компонент і які значення очікує.

Розробка кастомних компонентів 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 позицій) та складних інтеграцій.

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

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