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

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Разработка кастомных параметров компонентов 1С-Битрикс
Средний
~1-2 недели
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    944
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1074

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

Зачем нужен .parameters.php

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

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

Это работает, но при изменении требований разработчик должен править код. С .parameters.php менеджер сам меняет настройки через интерфейс. Кастомные параметры в 3 раза сокращают время внесения изменений по сравнению с правкой шаблонов. Экономия времени на повторных доработках достигает 70%. Опыт показывает: грамотно спроектированные параметры — это документация в коде, которая живёт с проектом.

Типы параметров и когда что использовать

В Битрикс поддерживаются следующие типы (TYPE в массиве параметра):

Тип Когда использовать
STRING Заголовок, CSS-класс, URL
LIST Выбор из набора значений
CHECKBOX Да/Нет флаги
NUMBER Количество, лимиты
COLORPICKER Выбор цвета
FILE Путь к файлу
CUSTOM Произвольный HTML-виджет

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

Пошаговое создание кастомного параметра

  1. Создайте файл .parameters.php в папке компонента.
  2. Определите группы параметров (GROUPS) для логической структуры.
  3. Опишите каждый параметр: тип, название, значение по умолчанию.
  4. Для зависимых параметров укажите REFRESH => 'Y'.
  5. Выполните нормализацию в component.php или onPrepareComponentParams.
  6. Добавьте CUSTOM-виджет, если стандартных типов недостаточно.
Полноценный .parameters.php (нажмите, чтобы развернуть)
<?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 лет в разработке Битрикс. Гарантируем качество и соблюдение стандартов безопасности. Если хотите, чтобы компоненты были гибкими и управляемыми — закажите разработку кастомных параметров. Получите консультацию по вашему проекту — оценим трудоёмкость и предложим оптимальное решение.

Сроки

Объём параметров Что входит Срок
5–10 параметров Стандартные типы, группы, нормализация 1–2 дня
15–25 параметров + SECTION-тип, REFRESH, зависимые параметры 3–5 дней
+ CUSTOM-виджеты + JS-обработчики, сложные UI в форме 1 неделя

Свяжитесь с нами — поможем сделать компоненты гибкими и управляемыми. Хорошо спроектированные параметры компонента — это документация в коде. Разработчик открывает .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 — нет, и это принципиально.

Почему 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 с).

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

Файл Назначение
class.php ООП-класс, наследующий CBitrixComponent. Бизнес-логика, выборка данных, валидация параметров. В новых компонентах используем только его, component.php — процедурный пережиток.
template.php Чистый HTML + $arResult. Никакой бизнес-логики.
result_modifier.php Дополнительная обработка после выборки, но перед отрисовкой.
component_epilog.php Персонализация, мета-теги, скрипты — выполняется вне кэша.
.parameters.php Описание входных параметров для админки.
.description.php Метаданные: название, категория, иконка.

Всё на ядре D7, ORM-классах и событийной модели. CIBlockElement::GetList — только когда D7 ORM не покрывает кейс. Документация по компонентам — на dev.1c-bitrix.ru. Общее понятие компонентной архитектуры — на Wikipedia.

Зачем кастомные компоненты, если есть готовые в маркетплейсе

Стандартных хватает для 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-редактирование — всё через контроллеры. Подробнее о D7 контроллерах — на официальном портале.

Как кэширование определяет скорость сайта и экономит бюджет

Разница между 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 месяца

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

Сроки разработки

Тип задачи Сроки
Кастомный шаблон стандартного компонента 2–8 часов
result_modifier с дополнительной логикой 2–4 часа
Простой кастомный компонент 1–3 дня
Сложный компонент с ajax и кэшированием 3–7 дней
Интеграционный компонент (внешний API) 3–10 дней

Свяжитесь с нами для оценки вашего проекта — мы проанализируем задачу, предложим архитектуру и сроки. Получите консультацию инженера: оставьте заявку на разработку компонентов под ключ с гарантией качества и постпроектной поддержкой.