Mass Update of Product Properties in 1C-Bitrix

Mass Update of Product Properties in 1C-Bitrix In a catalog of 15,000 products, you need to add a new "Material" property to 8,000 items in a certain category, fix a typo in a facet filter value for 2,000 products, and remove the "Recommended" flag from half the assortment. Through the product ed

Our competencies:

Frequently Asked Questions

Mass Update of Product Properties in 1C-Bitrix

In a catalog of 15,000 products, you need to add a new "Material" property to 8,000 items in a certain category, fix a typo in a facet filter value for 2,000 products, and remove the "Recommended" flag from half the assortment. Through the product edit form, this would be weeks of work. We solve such tasks with batch updates via API while maintaining data integrity. With over 10 years of experience in Bitrix development, we know how to update properties of thousands of products in hours, not days. On a catalog of 15,000 products, manual updating would take 3-4 weeks; automation reduces it to 1-2 days. Time savings are obvious, and the cost is calculated individually — you pay only for the result.

Where Properties Are Stored

Product properties in Bitrix are stored in several places depending on type:

  • Element fields (NAME, PREVIEW_TEXT, ACTIVE, etc.) — b_iblock_element
  • Infoblock properties — b_iblock_element_property, where IBLOCK_PROPERTY_ID is the property ID, VALUE is the value
  • Multiple properties — several rows in b_iblock_element_property with the same IBLOCK_ELEMENT_ID and same IBLOCK_PROPERTY_ID
  • List-type properties — VALUE contains the text value, VALUE_ENUM_ID references b_iblock_property_enum

For trade offers, the structure is similar, but IBLOCK_ID points to the offers infoblock, not the main catalog. Understanding this structure is necessary to choose the optimal update method.

How to Mass Update Product Properties Without Performance Degradation?

For small volumes (up to 1,000 elements), CIBlockElement::SetPropertyValues is suitable. Working code:

$iblockId = 10; // ID of catalog infoblock $propertyCode = 'MATERIAL'; $newValue = 'Cotton 100%'; // Get list of elements in the desired section $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 ); } 

However, on large volumes this method is slow — it reads current values, compares, updates. Each call involves several SQL queries. For volumes from 1,000 elements, we strongly recommend direct update via D7 ORM.

Fast Update via D7 ORM

For volumes from 1,000 elements, directly update b_iblock_element_property:

use Bitrix\Iblock\ElementPropertyTable; // First get the property ID $propertyId = getPropertyIdByCode($iblockId, 'MATERIAL'); // Get element IDs in batches $elementIds = getElementIdsBySectionBatch($iblockId, $sectionId, 500); foreach (array_chunk($elementIds, 500) as $chunk) { // Check which ones already have a record $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])) { // Update existing record ElementPropertyTable::update($existingMap[$elementId], ['VALUE' => 'Cotton 100%']); } else { // Insert new record ElementPropertyTable::add([ 'IBLOCK_ELEMENT_ID' => $elementId, 'IBLOCK_PROPERTY_ID' => $propertyId, 'VALUE' => 'Cotton 100%', ]); } } } 

After directly modifying the table, you need to clear the infoblock cache:

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

Why Doesn't the Facet Filter Work After Mass Property Update?

After changing properties that are used in the smart filter (catalog.smart.filter), you must rebuild the facet index. Otherwise, values won't update in the filter. We always include reindexing in our work process.

\Bitrix\Iblock\PropertyIndex\Manager::markIblockToReindex($iblockId); // or force: $indexer = new \Bitrix\Iblock\PropertyIndex\Indexer($iblockId); $indexer->startIndex(); $indexer->continueIndex(0); $indexer->endIndex(); 

On a catalog of 50,000+ products, reindexing takes several minutes — run it in the background via agent or cron. According to 1C-Bitrix documentation, it is recommended to run reindexing in background processes to avoid blocking users.

Reindexing Details The facet index is built from the `b_iblock_element_property` and `b_iblock_property_enum` tables. If you update properties directly via SQL, the index may not match the actual data. Rebuilding the index via `PropertyIndex\Manager` ensures synchronization. For large catalogs (from 100,000 items), use step-by-step indexing through an agent with a step of 1000 elements.

Specifics of Updating List Properties

List-type properties (used in facet filter) store the text value in VALUE and the ID from b_iblock_property_enum in VALUE_ENUM_ID. When changing a value, you need to update both fields.

// Find the ID of the new value in the enumeration $enumRes = \CIBlockPropertyEnum::GetList( [], ['PROPERTY_ID' => $propertyId, 'VALUE' => 'Blue'] ); $enum = $enumRes->Fetch(); $enumId = $enum['ID']; // Update ElementPropertyTable::update($existingPropId, [ 'VALUE' => 'Blue', 'VALUE_ENUM_ID' => $enumId, ]); 

If the desired value is not yet in the enumeration, first add it via CIBlockProperty::SetEnumValues() or directly into b_iblock_property_enum.

CSV Import as an Alternative

For non-technical users or regular updates, CSV import via Catalog → Import is better. File template: first row — headers with field codes (ID, PROPERTY_MATERIAL, PROPERTY_COLOR). Bitrix updates only those properties whose columns are present in the file.

Limitation of standard import: no support for conditions ("update property only if current value is empty"). For such scenarios, only scripts.

Step-by-Step Plan for Mass Property Update

  1. Analyze structure: determine which properties and how many elements need update.
  2. Choose method: for <500 items — SetPropertyValues, for larger — D7 ORM.
  3. Develop script considering property types (simple, multiple, list).
  4. Test on a database copy or small sample (10-20 elements).
  5. Run update with logging and error control.
  6. Clear infoblock cache and rebuild facet index.
  7. Validate: check that properties updated, filter works correctly.

What's Included in Configuring Mass Property Change

Within the scope of work, we:

  • Analyze current property structure and data
  • Choose optimal update method (API, D7 ORM, CSV import)
  • Write scripts with error control and logging
  • Test on a small sample
  • Run full update and rebuild cache and facet index
  • Provide documentation on the process

We guarantee data safety and minimal downtime.

Timelines

Volume Method Time
Up to 500 items Admin UI / SetPropertyValues 1-3 hours
500-5,000 items D7 batch update 3-6 hours
5,000-50,000 items D7 + queue + reindexing 1-2 days

Method Comparison

Method Speed Complexity Condition Support
SetPropertyValues Slow (up to 1000 items) Low No
D7 ORM Fast (from 1000 items) Medium Yes (in code)
CSV import Medium Low Only by ID

How to Order Configuration

If you need to mass update product properties, contact us. We will assess the scope of work and propose a turnkey solution. Get a consultation — just write. Your catalog will be put in order without pain and downtime.