Настройка массового изменения свойств товаров в 1С-Битрикс

Настройка массового изменения свойств товаров в 1С-Битрикс

В каталоге 15 000 товаров нужно проставить новое свойство «Материал» у 8 000 позиций определённой категории, исправить опечатку в значении фасетного фильтра у 2 000 товаров, снять флаг «Рекомендуемый» у половины ассортимента. Через карточку товара это недели работы. Мы решаем такие задачи пакетным обновлением через API с контролем целостности данных. У нас за плечами более 10 лет опыта в разработке на Битрикс — мы знаем, как обновить свойства тысяч товаров за часы, а не дни. На каталоге из 15 000 товаров ручное обновление заняло бы 3–4 недели, автоматизация сокращает до 1–2 дней. Экономия времени очевидна, а стоимость рассчитывается индивидуально — вы платите только за результат.

Где хранятся свойства

Свойства товаров в Битрикс хранятся в нескольких местах в зависимости от типа:

• Поля элемента (NAME, PREVIEW_TEXT, ACTIVE и др.) — b_iblock_element
• Свойства инфоблока — b_iblock_element_property, где IBLOCK_PROPERTY_ID — ID свойства, VALUE — значение
• Множественные свойства — несколько строк в b_iblock_element_property с одним IBLOCK_ELEMENT_ID и одним IBLOCK_PROPERTY_ID
• Свойства типа «Список» — VALUE содержит текстовое значение, VALUE_ENUM_ID — ссылку на b_iblock_property_enum

Для торговых предложений — аналогичная структура, но IBLOCK_ID указывает на инфоблок предложений, а не основной каталог. Понимание этой структуры необходимо для выбора оптимального метода обновления.

Как массово обновить свойства товаров без просадки производительности?

Для небольших объёмов (до 1 000 элементов) подходит CIBlockElement::SetPropertyValues. Код рабочий:

$iblockId   = 10; // ID инфоблока каталога
$propertyCode = 'MATERIAL';
$newValue   = 'Хлопок 100%';

// Получаем список элементов нужной секции
$res = \CIBlockElement::GetList(
    [],
    ['IBLOCK_ID' => $iblockId, 'SECTION_ID' => 42, 'ACTIVE' => 'Y'],
    false,
    false,
    ['ID']
);

while ($row = $res->Fetch()) {
    \CIBlockElement::SetPropertyValues(
        $row['ID'],
        $iblockId,
        $newValue,
        $propertyCode
    );
}

Однако на больших объёмах этот метод медленный — он читает текущие значения, сравнивает, обновляет. Каждый вызов — несколько SQL-запросов. Для объёмов от 1 000 элементов настоятельно рекомендуем прямое обновление через D7 ORM.

Быстрое обновление через D7 ORM

Для объёмов от 1 000 элементов используйте прямое обновление b_iblock_element_property:

use Bitrix\Iblock\ElementPropertyTable;

// Сначала получаем ID свойства
$propertyId = getPropertyIdByCode($iblockId, 'MATERIAL');

// Получаем ID элементов пакетами
$elementIds = getElementIdsBySectionBatch($iblockId, $sectionId, 500);

foreach (array_chunk($elementIds, 500) as $chunk) {
    // Проверяем, у кого уже есть запись
    $existing = ElementPropertyTable::getList([
        'filter' => [
            'IBLOCK_PROPERTY_ID' => $propertyId,
            'IBLOCK_ELEMENT_ID'  => $chunk,
        ],
        'select' => ['ID', 'IBLOCK_ELEMENT_ID'],
    ])->fetchAll();

    $existingMap = array_column($existing, 'ID', 'IBLOCK_ELEMENT_ID');

    foreach ($chunk as $elementId) {
        if (isset($existingMap[$elementId])) {
            // Обновляем существующую запись
            ElementPropertyTable::update($existingMap[$elementId], ['VALUE' => 'Хлопок 100%']);
        } else {
            // Вставляем новую
            ElementPropertyTable::add([
                'IBLOCK_ELEMENT_ID'  => $elementId,
                'IBLOCK_PROPERTY_ID' => $propertyId,
                'VALUE'              => 'Хлопок 100%',
            ]);
        }
    }
}

После прямого изменения таблицы нужно сбросить кэш инфоблока:

\Bitrix\Iblock\InformationBlock::cleanTagCache($iblockId);
\Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag('iblock_id_' . $iblockId);

Почему после массового обновления свойств не работает фасетный фильтр?

После изменения свойств, которые используются в умном фильтре (catalog.smart.filter), необходимо перестроить фасетный индекс. Иначе значения не обновятся в фильтре. Мы всегда включаем переиндексацию в процесс работ.

\Bitrix\Iblock\PropertyIndex\Manager::markIblockToReindex($iblockId);
// или принудительно:
$indexer = new \Bitrix\Iblock\PropertyIndex\Indexer($iblockId);
$indexer->startIndex();
$indexer->continueIndex(0);
$indexer->endIndex();

На каталоге 50 000+ товаров переиндексация занимает несколько минут — запускайте в фоне через агент или cron. Согласно документации 1С-Битрикс, рекомендуется запускать переиндексацию в фоновых процессах, чтобы не блокировать пользователей.

Особенности обновления списковых свойств

Свойства типа «Список» (используются в фасетном фильтре) хранят в VALUE текстовое значение, а в VALUE_ENUM_ID — ID из b_iblock_property_enum. При изменении значения нужно обновлять оба поля.

// Находим ID нового значения в перечислении
$enumRes = \CIBlockPropertyEnum::GetList(
    [],
    ['PROPERTY_ID' => $propertyId, 'VALUE' => 'Синий']
);
$enum = $enumRes->Fetch();
$enumId = $enum['ID'];

// Обновляем
ElementPropertyTable::update($existingPropId, [
    'VALUE'         => 'Синий',
    'VALUE_ENUM_ID' => $enumId,
]);

Если нужного значения ещё нет в перечислении — сначала добавьте его через CIBlockProperty::SetEnumValues() или напрямую в b_iblock_property_enum.

Импорт CSV как альтернатива

Для нетехнических пользователей или регулярных обновлений лучше подходит импорт CSV через Каталог → Импорт. Шаблон файла: первая строка — заголовки с кодами полей (ID, PROPERTY_MATERIAL, PROPERTY_COLOR). Битрикс обновляет только те свойства, колонки которых присутствуют в файле.

Ограничение стандартного импорта: нет поддержки условий («обновить свойство только если текущее значение пустое»). Для таких сценариев — только скрипты.

Пошаговый план массового обновления

1. Анализ структуры: выяснить, какие свойства и сколько элементов нужно обновить.
2. Выбор метода: для <500 товаров — SetPropertyValues, для больших — D7 ORM.
3. Разработка скрипта с учётом типа свойств (простые, множественные, списковые).
4. Тестирование на копии базы или небольшой выборке (10-20 элементов).
5. Запуск обновления с логированием и контролем ошибок.
6. Сброс кэша инфоблока и перестроение фасетного индекса.
7. Валидация: проверить, что свойства обновились, фильтр работает корректно.

Что входит в настройку массового изменения свойств

В рамках работы мы:

• Анализируем текущую структуру свойств и данные
• Выбираем оптимальный метод обновления (API, D7 ORM, импорт CSV)
• Пишем скрипты с контролем ошибок и логированием
• Тестируем на небольшой выборке
• Запускаем полное обновление и перестраиваем кэш и фасетный индекс
• Предоставляем документацию по процессу

Мы гарантируем сохранность данных и минимизацию времени простоя.

Сроки выполнения

Сравнение методов обновления

Как заказать настройку

Если вам нужно массово обновить свойства товаров, свяжитесь с нами. Мы оценим объём работ и предложим решение под ключ. Получите консультацию — просто напишите. Ваш каталог будет приведён в порядок без боли и простоев.

Разработка каталога 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 успешных проектов за плечами.