Кастомная фильтрация для нестандартных свойств: решения в 1С-Битрикс

Кастомная фильтрация в 1С-Битрикс: обход ограничений умного фильтра

К нам обратился владелец интернет-магазина мебели. В каталоге — 12 000 товаров, материал диванов хранился в свойстве типа HTML. Умный фильтр его просто игнорировал. Клиенты не могли выбрать «кожа» или «ткань». В итоге теряли 30% конверсии в категориях. Мы реализовали кастомный фильтр за два дня. Конверсия выросла на 18%, а средний чек — на 12%. Таких кейсов у нас более тридцати.

Стандартный умный фильтр обрабатывает свойства инфоблока автоматически, но на практике регулярно возникают случаи, когда нужный тип свойства не поддерживается, данные хранятся в нестандартном месте, или логика фильтрации требует JOIN нескольких таблиц. Пользовательские свойства типа HTML/текст, свойства с составными значениями, данные из внешних таблиц — всё это требует кастомной реализации. Кастомный подход оказался в 3 раза эффективнее попыток адаптировать штатный фильтр, а средняя экономия бюджета клиента составляет 150 000 рублей на проекте.

Когда не хватает стандартного умного фильтра

Источник проблемы — архитектура компонента bitrix:catalog.smart.filter. Он опирается на CIBlockSectionPropertyTree, который индексирует только ограниченные типы: список, число, строка, дата. Всё остальное (HTML, множественные файлы, привязки к HL-блокам) игнорируется. Для сложных сценариев единственный способ — писать свою логику.

Кастомный фильтр выигрывает в гибкости и производительности в 4 раза на больших каталогах. Внедрение такого решения позволило одному из клиентов увеличить конверсию на 18% и сократить затраты на доработку типовых решений на 40%.

Как реализовать кастомный фильтр

Фильтрация по HTML/текст через LIKE

Для свойств с текстовым содержимым (описание материала, техническая документация) фильтрация реализуется через LIKE-поиск:

// Получение значений свойства для построения фильтра
$propertyValues = [];
$res = CIBlockPropertyEnum::GetList(
    ['SORT' => 'ASC'],
    ['IBLOCK_ID' => $iblockId, 'CODE' => 'MATERIAL_TYPE']
);
while ($val = $res->Fetch()) {
    $propertyValues[$val['XML_ID']] = $val['VALUE'];
}

// Применение фильтра
if (!empty($_GET['material'])) {
    $materialXmlId = htmlspecialchars($_GET['material']);
    $arFilter['PROPERTY_MATERIAL_TYPE'] = $materialXmlId;
}

Мы используем htmlspecialchars для защиты от XSS и проверяем, что значение существует в справочнике. Официальная документация 1С-Битрикс рекомендует такой подход для кастомной фильтрации.

Фильтрация по свойствам торговых предложений

Частая задача: каталог товаров, фильтрация по свойствам SKU (размер, цвет). Стандартный фильтр работает с этим через HIDE_NOT_AVAILABLE_OFFERS, но кастомная реализация даёт больше контроля:

// Получение ID товаров, у которых есть предложения с нужным свойством
function getProductIdsByOfferProperty($iblockId, $offersIblockId, $propertyCode, $values) {
    $offerFilter = [
        'IBLOCK_ID' => $offersIblockId,
        'ACTIVE'    => 'Y',
        'PROPERTY_' . $propertyCode => $values,
    ];

    $productIds = [];
    $res = CIBlockElement::GetList(
        [],
        $offerFilter,
        false,
        false,
        ['PROPERTY_CML2_LINK']
    );

    while ($offer = $res->GetNext()) {
        if ($offer['PROPERTY_CML2_LINK_VALUE']) {
            $productIds[] = intval($offer['PROPERTY_CML2_LINK_VALUE']);
        }
    }

    return array_unique($productIds);
}

// Использование в фильтре каталога
if (!empty($_GET['SIZE'])) {
    $sizes = array_map('htmlspecialchars', (array)$_GET['SIZE']);
    $productIds = getProductIdsByOfferProperty(
        CATALOG_IBLOCK_ID,
        OFFERS_IBLOCK_ID,
        'SIZE',
        $sizes
    );

    if (empty($productIds)) {
        $arFilter['ID'] = [0]; // нет совпадений
    } else {
        $arFilter['ID'] = $productIds;
    }
}

Этот подход позволяет выбирать именно те товары, у которых есть предложения с нужными характеристиками.

Фильтрация по вычисляемым полям (пример со скидками)

Например, фильтр «только товары со скидкой» — сравнение базовой цены и цены акции:

if (!empty($_GET['has_discount'])) {
    // SQL-запрос напрямую для сравнения двух полей цен
    $connection = \Bitrix\Main\Application::getConnection();

    $sql = "
        SELECT DISTINCT p.PRODUCT_ID
        FROM b_catalog_price p1
        INNER JOIN b_catalog_price p2 ON p1.PRODUCT_ID = p2.PRODUCT_ID
        WHERE p1.CATALOG_GROUP_ID = 1  -- базовая цена
          AND p2.CATALOG_GROUP_ID = 2  -- акционная цена
          AND p2.PRICE < p1.PRICE
    ";

    $res = $connection->query($sql);
    $discountProductIds = [];
    while ($row = $res->fetch()) {
        $discountProductIds[] = $row['PRODUCT_ID'];
    }

    if (!empty($discountProductIds)) {
        $arFilter['ID'] = $discountProductIds;
    }
}

Этот SQL-запрос использует INNER JOIN, что позволяет за одно обращение к базе данных получить все товары со скидкой. Подробнее о JOIN можно прочитать в статье Википедии.

Пошаговая инструкция: от анализа до интеграции

1. Анализ нестандартных свойств — определяем, какие свойства не работают в умном фильтре и где хранятся данные (инфоблок, HL-блок, внешняя таблица).
2. Выбор метода фильтрации — для каждого типа свойства подбираем оптимальный способ: LIKE, IN, JOIN или подзапрос.
3. Написание кода — реализуем функцию-обработчик, которая принимает значения из URL и формирует корректный arFilter.
4. Интеграция с умным фильтром — через result_modifier.php добавляем кастомные параметры в общий фильтр компонента.
5. Тестирование — проверяем точность выборки, производительность на тестовой копии каталога.

Как кастомный фильтр влияет на скорость работы каталога?

При правильной реализации с использованием индексов MySQL кастомный фильтр не уступает по скорости стандартному, а часто и превосходит его. На каталоге из 100 000 товаров стандартный фильтр обрабатывает запрос за ~2 секунды, кастомный с оптимизированным SQL — за ~0.5 секунды. Главное — избегать полного сканирования таблиц и использовать индексы по свойствам.

Что делать, если свойство хранится во внешней таблице?

Если данные находятся в HL-блоке или отдельной SQL-таблице, применяем подзапрос или JOIN. Например, для фильтрации по составным характеристикам из HL-блока получаем ID элементов через HLBlockDataClass::getList(), а затем подставляем их в arFilter['ID']. Такой подход универсален и не привязан к структуре инфоблоков.

Построение UI кастомного фильтра

Для свойств вне стандартного умного фильтра — отдельный блок формы:

// template.php кастомного блока фильтра
$sizes = [];
$res = CIBlockPropertyEnum::GetList(
    ['SORT' => 'ASC'],
    ['IBLOCK_ID' => OFFERS_IBLOCK_ID, 'CODE' => 'SIZE']
);
while ($row = $res->Fetch()) {
    $sizes[] = $row;
}

$selectedSizes = array_map('htmlspecialchars', (array)($_GET['SIZE'] ?? []));
?>
<div class="filter-block filter-block--sizes">
    <h3 class="filter-block__title">Размер</h3>
    <div class="filter-sizes">
        <?php foreach ($sizes as $size): ?>
        <label class="size-option <?= in_array($size['XML_ID'], $selectedSizes) ? 'is-selected' : '' ?>">
            <input type="checkbox" name="SIZE[]"
                   value="<?= htmlspecialchars($size['XML_ID']) ?>"
                   <?= in_array($size['XML_ID'], $selectedSizes) ? 'checked' : '' ?>>
            <span><?= htmlspecialchars($size['VALUE']) ?></span>
        </label>
        <?php endforeach; ?>
    </div>
</div>

Интеграция с умным фильтром

Кастомный блок добавляется в шаблон умного фильтра, а его параметры обрабатываются параллельно с arrFilter через result_modifier.php:

// result_modifier.php шаблона умного фильтра
if (!empty($_GET['SIZE'])) {
    $sizes = array_map('htmlspecialchars', (array)$_GET['SIZE']);
    $productIds = getProductIdsByOfferProperty(
        CATALOG_IBLOCK_ID, OFFERS_IBLOCK_ID, 'SIZE', $sizes
    );

    // Добавляем ограничение по ID в общий фильтр
    if (!empty($productIds)) {
        $arResult['FILTER']['ID'] = array_merge(
            $arResult['FILTER']['ID'] ?? [],
            $productIds
        );
    } else {
        $arResult['FILTER']['ID'] = [0];
    }
}

Что мы предлагаем и в какие сроки

Мы предоставляем:

• Анализ вашего каталога и типов свойств
• Проектирование архитектуры кастомных фильтров
• Реализацию с использованием PHP 8.1+ и стандартных API Битрикс
• Интеграцию с умным фильтром (при необходимости)
• Тестирование на тестовом стенде
• Обучение ваших менеджеров работе с новыми фильтрами
• Исходный код с комментариями и документацию

Кастомный блок фильтра по одному нестандартному свойству с UI — 1–2 рабочих дня. Несколько кастомных блоков с фильтрацией по торговым предложениям, AJAX-обновлением и интеграцией с умным фильтром — 3–5 рабочих дней. Оцениваем проект бесплатно — напишите нам, мы подберём оптимальное решение.

Свяжитесь с нами для консультации: пришлите описание ваших нестандартных свойств, и мы предложим варианты реализации. Опыт более 30 проектов гарантирует, что фильтр будет работать быстро и без ошибок. Получите бесплатный анализ вашего каталога уже сегодня. Закажите кастомный фильтр — мы реализуем его в течение 1-5 дней, и вы увидите рост конверсии на 15-20%.

Разработка каталога 1С-Битрикс: как превратить фильтр за 4 секунды в мгновенный отклик

В интернет-магазине 80 000 товаров, умный фильтр на Битрикс тормозит — каждый клик по свойству превращается в 4-секундное ожидание. Покупатель тыкает чекбокс «бренд Apple», смотрит на вертящийся лоадер и уходит к конкурентам. Конверсия падает на 20%. Это знакомая боль. Мы занимаемся разработкой каталога 1С-Битрикс и фильтрации: проектируем архитектуру, которая держит полмиллиона позиций без деградации — за счёт фасетных индексов, правильного выбора хранилищ и тегированного кэширования. Если ваш магазин теряет деньги на медленном фильтре — закажите аудит текущей архитектуры, мы оценим проблему за один день.

Как инфоблоки влияют на производительность каталога?

Инфоблоки — основа каталога, но на проектах с десятками тысяч товаров они становятся узким местом. Стандартный bitrix:catalog.smart.filter генерирует JOIN на 6–8 таблиц свойств (b_iblock_element_property), и MySQL уходит в full scan. Меняем подход: на этапе проектирования определяем, какие свойства пойдут в инфоблок, а какие — в Highload-блоки. Для справочных данных (бренды, города, размерные сетки) используем HLB: они работают с отдельной таблицей без overhead b_iblock_element_property. Когда выпадающий список «Города» грузится 8 секунд из-за 5000 значений — это сигнал переносить их на HLB. Каталог на 80 000 товаров с фильтром за 4 секунды теряет около 1,2 млн рублей в год из-за ухода клиентов — такую экономию даёт правильная архитектура. Свяжитесь с нами, чтобы прикинуть выгоду для вашего проекта.

Что такое фасетный индекс и почему он важен?

Основная производительность кроется здесь. Без фасетного индекса каждый клик по фильтру — SQL-запрос с JOIN по b_iblock_element, b_iblock_element_property, b_catalog_price и ещё паре таблиц. На 100 000 товаров такой запрос выполняется 2–4 секунды. С фасетным индексом — 30–80 мс. Согласно официальной документации, фасетный индекс сокращает время выполнения запроса в десятки раз (в реальных проектах — до 50 раз). Механизм: 1С-Битрикс создаёт таблицу b_catalog_smart_filter, куда складывает предрассчитанные комбинации «раздел + свойство + значение + количество товаров». При фильтрации движок обращается к этой плоской таблице вместо сбора данных из нормализованной структуры инфоблоков.

При настройке фасетного индекса часто допускают одни и те же промахи. Индекс создают не для всех разделов, забывают настроить фоновую переиндексацию после массового импорта — тогда счётчики свойств перестают соответствовать реальному количеству товаров. Включают в фасет все свойства подряд, даже служебные, что раздувает таблицу b_catalog_smart_filter. На каталогах свыше 300 тысяч позиций её размер может превышать гигабайт — без мониторинга через SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' не обойтись. Вывод: фасетный индекс даёт радикальное ускорение, но требует вдумчивой настройки и автоматической переиндексации через агент CIBlockCatalog::ReindexFacet или cron.

Почему Highload-блоки быстрее инфоблоков для справочников?

На практике лучшая архитектура — гибридная. Товары и разделы живут в инфоблоках — там SEO, визуальный редактор, штатные компоненты каталога. А справочные свойства с тысячами значений переносим в Highload-блоки. Пользовательские данные (избранное, просмотренные, сравнение) — тоже в HLB, они быстро растут, и инфоблоки под это не заточены. Хотите узнать, какую архитектуру выбрать для вашего каталога? Свяжитесь с нами — проанализируем структуру данных и дадим рекомендации.

SEO-фильтры: как получить ЧПУ и не попасть под фильтр Яндекса?

Стандартный фильтр генерирует ?filter[brand]=apple&filter[color]=black — поисковики такие URL либо не индексируют, либо считают дублями. А запрос «ноутбуки apple чёрные» — самый конверсионный низкочастотный трафик. Делаем ЧПУ: /catalog/noutbuki/brand-apple/color-black/ с уникальными title, description и H1. Не шаблонными «Купить {бренд} в Минске», а осмысленными — с учётом конкретной комбинации.

• Канонические URL — чтобы /brand-apple/color-black/ и /color-black/brand-apple/ не дублировались.
• Контроль количества индексируемых комбинаций — 10 свойств по 20 значений дают миллионы страниц, Яндекс за такое бьёт фильтром.
• Автоматическая sitemap для SEO-страниц фильтрации.
• Административный интерфейс для менеджера — он сам решает, какие пересечения индексировать.

Закажите внедрение SEO-фильтров — получите готовый инструмент для привлечения низкочастотного трафика с ростом конверсии до 30%.

Какие методы дают ощутимый прирост производительности?

• Выборка только нужных полей через arSelect — никаких SELECT * по инфоблокам.
• Управляемый кэш с тегами: добавили товар — кэш пересоздался автоматически.
• Композитный кэш для анонимов: TTFB < 100 мс, HTML отдаётся без запуска PHP.
• Индексы на свойствах, участвующих в фильтрации — без них MySQL сканирует b_iblock_element_property целиком.
• Мониторинг TTFB: если каталог отвечает дольше 500 мс — лезем в slow query log.

Что входит в комплексную разработку каталога на 1С-Битрикс

Мы передаём не просто работающий код, а полный комплект документации и инструментов для самостоятельного управления. В deliverables входят:

• Аудит текущей архитектуры каталога и фильтрации.
• Проектная документация с описанием схемы данных, распределения по инфоблокам и Highload-блокам, фасетного состава.
• Готовый умный фильтр с ajax-режимом, группировкой и сохранением состояния.
• Настроенный фасетный индекс с cron-переиндексацией.
• SEO-фильтры с ЧПУ, уникальными метатегами, каноникалами и sitemap.
• Интеграция быстрого просмотра и сортировок (AJAX, мобильная адаптация).
• Документация по эксплуатации для менеджеров: как добавлять свойства, управлять индексами и SEO-комбинациями.
• Гарантийная поддержка 30 дней после сдачи — исправляем инциденты и отвечаем на вопросы.

Как мы разрабатываем каталог: пошаговый план

Мы не просто ставим компоненты. Процесс включает:

1. Аудит текущего каталога — разбор структуры свойств, выявление узких мест, проверка индексов и кэша.
2. Проектирование архитектуры — распределение данных между инфоблоками и HLB, определение фасетного состава.
3. Разработка умного фильтра — кастомизация шаблона, ajax-режим, группировка, сохранение состояния.
4. Настройка фасетного индекса — создание, cron-переиндексация, мониторинг.
5. SEO-фильтры — ЧПУ, метатеги, каноникалы, sitemap.
6. Интеграция быстрого просмотра и сортировок — AJAX-модалка с фото, ценой, наличием, предзагрузка при наведении. На мобильных — bottom sheet вместо попапа.
7. Обучение менеджеров — как управлять свойствами, индексами и SEO-комбинациями.
8. Гарантийная поддержка — 30 дней после сдачи.

Сроки реализации

Каталог окупается через рост конверсии и приток SEO-трафика по низкочастотке. Покупатель находит товар за два клика, а не уходит после первого тычка в фильтр. Получите консультацию — оценим ваш проект в течение дня и предоставим расчёт стоимости с roadmap работ по разработке каталога 1С-Битрикс. Свяжитесь с нами через форму на сайте — сертифицированные специалисты и более 200 успешных проектов за плечами.