Настройка массового изменения статусов товаров 1С-Битрикс
Сезон закончился — 200 товаров нужно снять с публикации. Акция запускается в полночь — 50 товаров активируются одновременно. Оба сценария решаются массовым изменением статусов, но неправильная реализация даёт race condition или кладёт сайт под нагрузкой на MySQL. Мы обслуживаем интернет-магазины на Битриксе с каталогами от 500 до 500 000 товаров, и массовые операции — один из ключевых компонентов каждого проекта. Наш опыт показывает: правильная реализация может ускорить обновление статусов в 100 раз по сравнению с наивным подходом.
Что такое «статус» товара в Битриксе
Товар в Битриксе — элемент инфоблока с множественными свойствами активности. Основное поле — ACTIVE (Y/N) в таблице b_iblock_element. Дополнительно существуют временные границы активности: ACTIVE_FROM и ACTIVE_TO — период, в который товар активен. Если текущее время не попадает в диапазон, элемент считается неактивным вне зависимости от значения флага ACTIVE.
Кастомные статусы (новинка, акция, хит, бестселлер) — это отдельные свойства инфоблока типа «Список», а не встроенное поле ACTIVE. Массовое изменение кастомных свойств требует другого подхода и разбирается ниже в соответствующем разделе.
Массовое изменение ACTIVE через D7
Прямое обновление через ORM — быстрейший способ для поля ACTIVE:
$productIds = [1001, 1002, 1003]; foreach (array_chunk($productIds, 100) as $chunk) { \Bitrix\Iblock\ElementTable::updateMulti($chunk, ['ACTIVE' => 'N']); // Сброс кэша для обновлённых элементов foreach ($chunk as $id) { \Bitrix\Main\Application::getInstance()->getTaggedCache() ->clearByTag('iblock_element_' . $id); } } updateMulti выполняет один UPDATE b_iblock_element SET ACTIVE='N' WHERE ID IN (...) — оптимально для MySQL.
Однако прямое обновление через ORM минует события Битрикса (OnBeforeIBlockElementUpdate, OnAfterIBlockElementUpdate). Если другие модули подписаны на эти события (CRM, поиск, кастомные обработчики), нужно использовать CIBlockElement::Update():
foreach ($productIds as $id) { \CIBlockElement::Update($id, false, ['ACTIVE' => 'N'], false); // 4-й параметр false — без пересчёта прав доступа } Отложенная активация по расписанию
Для акционных запусков в конкретное время используются поля ACTIVE_FROM / ACTIVE_TO. Не нужно запускать скрипт в полночь — достаточно задать даты:
\CIBlockElement::Update($productId, false, [ 'ACTIVE' => 'Y', 'ACTIVE_FROM' => '01.12.2024 00:00:00', 'ACTIVE_TO' => '31.12.2024 23:59:59', ]); Битрикс при отображении в каталоге автоматически учитывает текущую дату. Фильтр в компоненте bitrix:catalog.section по умолчанию включает ACTIVE_DATE = 'Y', что проверяет попадание в диапазон.
Массовое изменение кастомных свойств-статусов
Свойство типа «Список» (L) — например, «Статус: Новинка / Акция / Хит» — меняется через SetPropertyValuesEx. Для массового обновления:
$enumValues = []; $enum = \CIBlockPropertyEnum::GetList( [], ['PROPERTY_ID' => $propertyId, 'VALUE' => 'Акция'] ); if ($enumItem = $enum->Fetch()) { $enumValueId = $enumItem['ID']; } foreach (array_chunk($productIds, 50) as $chunk) { foreach ($chunk as $id) { \CIBlockElement::SetPropertyValuesEx($id, $iblockId, [ 'STATUS' => $enumValueId, ]); } usleep(50000); } Условное изменение статуса
Если нужно изменить статус только для товаров с определёнными условиями (например, деактивировать все товары с нулевым остатком), выборка делается заранее:
// Найти товары с нулевым остатком $zeroStock = \Bitrix\Catalog\ProductTable::getList([ 'filter' => ['QUANTITY' => 0, 'QUANTITY_TRACE' => 'Y'], 'select' => ['ID', 'IBLOCK_ELEMENT_ID'], ])->fetchAll(); $elementIds = array_column($zeroStock, 'IBLOCK_ELEMENT_ID'); // Деактивировать foreach (array_chunk($elementIds, 100) as $chunk) { \Bitrix\Iblock\ElementTable::updateMulti($chunk, ['ACTIVE' => 'N']); } Этот запрос выполняется за секунды для тысяч товаров против минут при поэлементном обходе через CIBlockElement::GetList.
Производительность и проблемы race condition
При одновременном обновлении товаров двумя операциями (например, кто-то кликнул кнопку "Активировать", а в тот же момент cron запускает массовое обновление) возникает race condition. Один обработчик прочитает старые данные, другой — новые. Результат: потеря обновлений или конфликты. Решение — использовать транзакции и версионирование. Перед обновлением проверяем, не изменилась ли запись:
$element = \Bitrix\Iblock\ElementTable::getByPrimary($id)->fetch(); if ($element['MODIFIED'] === $knownModified) { \Bitrix\Iblock\ElementTable::update($id, ['ACTIVE' => 'N']); } else { // Запись изменилась, пропускаем } Нагрузка на MySQL растёт с количеством товаров. Обновление 100 000 товаров наивным способом (по одному через цикл) займёт часы или даже дни, так как каждое обновление требует отдельного SQL-запроса. Правильный подход: батчинг (обновление по 100-500 за раз в одной транзакции). При батчинге время сокращается с часов на минуты, а нагрузка на базу падает в 10-50 раз. Для каталогов свыше 100 000 товаров рекомендуем использовать cron-агент, который обновляет товары фоном, чтобы не блокировать админку.
Интеграция с 1С
При автоматическом обновлении статусов из 1С нужно отличать изменения, пришедшие из 1С, от локальных изменений через админку. Используем дополнительное свойство-флаг: если товар обновлен из 1С, флаг FROM_1C = Y и сохраняется timestamp последней синхронизации. Это предотвращает циклические обновления (когда Битрикс отправляет изменение обратно в 1С, а 1С снова возвращает его) и позволяет отладить синхронизацию в логах. При обновлении товара через CommerceML важно сохранять локальные переопределения — например, если менеджер вручную деактивировал товар, это не должно быть перезаписано из 1С при очередной синхронизации.
Что входит в работу
- Прототипирование и тестирование производительности на вашем объёме товаров.
- Разработка консоли управления (админка) для масовых операций.
- Интеграция с 1С (если нужна).
- Обработка race conditions и безопасность параллельных операций.
- Кеширование и оптимизация индексов.
- Документация и обучение команды.
Сроки и гарантия
Базовая реализация массового обновления статусов — 3–5 дней. Полная система с админкой, интеграцией 1С и обработкой конфликтов — 1–2 недели. Гарантируем, что обновление 100 000 товаров выполнится за время, которое вы определите (обычно — несколько минут). Свяжитесь с нами для консультации — проанализируем ваш каталог и предложим оптимальное решение.