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

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

Часто к нам приходят с задачей: в каталоге 5000 товаров, у 800 из них нужно обновить одно поле — скажем, добавить флаг «Хит продаж». Редактировать по одному — рабочий день. Штатный инструмент массового редактирования в административной части Битрикса закрывает большинство сценариев, но имеет ограничения, которые нужно знать. Мы предлагаем гибридный подход: комбинацию стандартных средств и кастомных скриптов на API, который ускоряет обновление в 5–10 раз. Гарантируем стабильность результата и даём 14 дней пост-поддержки.

Когда требуется кастомное массовое редактирование товаров?

Стандартный интерфейс справляется с задачами вроде смены цены или активности у десятка товаров. Но как только появляется потребность обновить 500+ записей, установить значение только для пустых полей или затронуть множественные свойства — без собственного скрипта не обойтись. Обратитесь к нам — мы подберём оптимальное решение под вашу задачу.

Как ускорить массовое редактирование в 10 раз? — настройка массового редактирования

Ключ к скорости — батчевая обработка через D7 API и отключение лишних событий. Например, метод \Bitrix\Catalog\ProductTable::updateMulti выполняет один SQL UPDATE с WHERE ID IN (...) вместо N отдельных запросов. Это даёт прирост производительности до 70% на выборках от 500 элементов. Также важно временно отключать поисковую переиндексацию (BX_SKIP_SEARCH_REINDEX), чтобы каждый вызов Update не генерировал событие.

Стандартный механизм: когда он сработает, а когда — нет

В административном списке товаров (/bitrix/admin/iblock_list_admin.php?type=catalog) выбираются нужные позиции, затем действие «Редактировать выбранные». Открывается форма, где указываются только изменяемые поля — остальные остаются без изменений. Технически это работает через CIBlockElement::Update(), вызываемый для каждого выбранного ID. Параметр $bWorkFlow = false в вызове — без создания черновика. При обновлении свойств Битрикс перезаписывает только переданные свойства, не затрагивая остальные.

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

Первое ограничение: не работает с множественными свойствами (тип L с несколькими значениями). Второе: не поддерживает условное обновление («установить значение только если текущее пустое»). Третье: при обновлении 500+ элементов браузер начинает тормозить из-за перезагрузки страницы с прогрессом. Для больших каталогов (от 10000 товаров) стандартный механизм практически непригоден — время выполнения нелинейно растёт.

Как мы ускоряем массовое редактирование?

Для обновления большого количества товаров через скрипт правильнее использовать D7 API с батчевой обработкой:

$productIds = [1001, 1002, 1003, /* ... */]; $batchSize = 50; $chunks = array_chunk($productIds, $batchSize); foreach ($chunks as $chunk) { foreach ($chunk as $id) { \CIBlockElement::Update($id, false, [ 'PROPERTY_VALUES' => [ 'IS_HIT' => 'Y', ], ]); } // Небольшая задержка между батчами чтобы не перегружать MySQL usleep(100000); // 100ms } 

Для чисто табличных данных (поля b_catalog_product, а не свойства инфоблока) быстрее прямое обновление через D7:

\Bitrix\Catalog\ProductTable::updateMulti($productIds, [ 'VAT_ID' => 3, 'VAT_INCLUDED' => 'Y', ]); 

Метод updateMulti выполняет один SQL UPDATE с WHERE ID IN (...) вместо N отдельных запросов.

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

Сравнение производительности при разных размерах батча

Что входит в работу

• Аудит текущей структуры инфоблоков и выявление узких мест.
• Написание скрипта массового обновления с учётом ваших условий.
• Тестирование на копии базы (бекап обязателен).
• Развёртывание на боевом сервере в окно низкой нагрузки.
• Документация по скрипту и обучение сотрудников работе с ним.
• Пост-поддержка: 14 дней после запуска на случай обнаружения ошибок.

Пошаговая инструкция по настройке

1. Определите, какие поля и свойства необходимо обновить.
2. Напишите скрипт с использованием D7 API или циклом CIBlockElement::Update.
3. Отключите поисковую переиндексацию через define('BX_SKIP_SEARCH_REINDEX', true).
4. Протестируйте на копии базы данных.
5. Запустите скрипт в часы низкой нагрузки.
6. После завершения включите переиндексацию поиска.

Мониторинг прогресса

При массовом обновлении через веб-интерфейс Битрикс использует механизм «продолжения» через параметр sessid и скрытые поля — каждые N элементов страница перезагружается с прогрессом. Для скриптовой обработки удобнее писать прогресс в файл и читать его через AJAX:

file_put_contents('/tmp/update_progress.json', json_encode([ 'processed' => $processed, 'total' => $total, 'percent' => round($processed / $total * 100), ])); 

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

Типичные ошибки при массовом обновлении

• Забывают отключить переиндексацию поиска — каждый вызов Update вызывает CSearch::Index(), что увеличивает время в 2–3 раза. Используйте define('BX_SKIP_SEARCH_REINDEX', true).
• Обновляют одно поле несколькими последовательными вызовами Update вместо одного. Каждый вызов триггерит события и обновляет кэш — лишние 100 мс на элемент.
• Не проверяют права доступа у скрипта — если скрипт запущен от администратора, а пользователь потом редактирует элемент, могут возникнуть конфликты с бизнес-процессами.

Сроки и как начать

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

Официальная документация по API 1С-Битрикс