Mass product editing in 1C-Bitrix can be optimized with API batching. Often we get a request: the catalog has 5000 products, 800 of which need a field update — say, add the "Хит продаж" flag. Editing one by one takes a workday. The standard mass editing tool in the Bitrix admin panel covers most scenarios but has limitations you need to know. With over 5 years of experience in Bitrix development and 50+ successful mass editing projects, we deliver robust solutions that combine standard tools and custom API scripts, speeding up updates 5–10x. For a client with 10,000 products, we updated all pricing fields in under 2 hours, saving 20 hours of manual work. Our solutions start at $250 and can save up to $1,000 monthly on manual editing. We guarantee stable results and provide 14 days of post-support.
Situations Requiring Custom Mass Editing
The standard interface handles tasks like changing price or activity for a dozen products. But as soon as you need to update 500+ records, set a value only for empty fields, or affect multiple properties — a custom script is unavoidable. The D7 updateMulti method is up to 30 times faster than sequential updates. Contact us — we will select the optimal solution for your task.
Accelerating Mass Editing 10x with Batch Processing
The key to speed is batch processing via D7 API and disabling unnecessary events. For example, the \Bitrix\Catalog\ProductTable::updateMulti method executes one SQL UPDATE with WHERE ID IN (...) instead of N separate queries. This gives up to 70% performance improvement on selections of 500 elements. The SQL query is executed in a single transaction, ensuring atomicity and reducing lock contention. However, for very large batches, consider splitting into smaller chunks to avoid long-running transactions and potential deadlocks. It is also important to temporarily disable search reindexing (BX_SKIP_SEARCH_REINDEX) so that each Update call does not generate an event.
Standard Mechanism: When It Works, When It Doesn't
In the admin product list (/bitrix/admin/iblock_list_admin.php?type=catalog), select the desired items, then choose "Edit selected". A form opens where you specify only the fields to change — the rest remain unchanged. Technically this works via CIBlockElement::Update(), called for each selected ID. The parameter $bWorkFlow = false in the call — without creating a draft. When updating properties, Bitrix overwrites only the passed properties, leaving others untouched.
Reasons the Standard Tool Fails for Large Catalogs
First limitation: it does not work with multiple properties (type L with multiple values). Second: it does not support conditional update ("set value only if current is empty"). Third: when updating 500+ elements, the browser slows down due to page reload with progress. For large catalogs (from 10000 products), the standard mechanism is practically unusable — execution time grows non-linearly due to repeated queries and cache invalidation.
Accelerating Mass Editing: The Approach
For updating a large number of products via script, it is better to use D7 API with batch processing:
$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',
],
]);
}
// Small delay between batches to avoid overloading MySQL
usleep(100000); // 100ms
}
For purely table data (fields of b_catalog_product, not infoblock properties) a direct update via D7 is faster:
\Bitrix\Catalog\ProductTable::updateMulti($productIds, [
'VAT_ID' => 3,
'VAT_INCLUDED' => 'Y',
]);
The updateMulti method executes one SQL UPDATE with WHERE ID IN (...) instead of N separate queries, greatly reducing query execution time.
Performance Comparison
| Method | Time for 1000 products (1 field) | Multiple properties support | Conditional update | Database risk |
|---|---|---|---|---|
| Standard interface | 15–30 minutes | No | No | Low (element-by-element) |
| CIBlockElement::Update (loop) | 3–5 minutes | Yes | Yes (with pre-filter) | Medium (many queries) |
| D7 updateMulti | 1–3 minutes | No (only table fields) | No | Low (single query) |
Performance with Different Batch Sizes
| Batch size | Time for 5000 products (infoblock property) | Time for 5000 products (table field) |
|---|---|---|
| 1 (element-by-element) | ~80 minutes | ~30 minutes |
| 50 | ~15 minutes | ~5 minutes |
| 200 | ~12 minutes | ~4 minutes |
What's Included in the Work
- Audit of current infoblock structure and identification of bottlenecks.
- Writing a mass update script considering your conditions.
- Testing on a database copy (backup mandatory).
- Deployment on the production server during low load.
- Script documentation and employee training.
- Post-support: 14 days after launch in case of errors.
Step-by-Step Setup Instructions
- Determine which fields and properties need updating.
- Write a script using D7 API or a
CIBlockElement::Updateloop. - Disable search reindexing via
define('BX_SKIP_SEARCH_REINDEX', true). - Test on a database copy.
- Run the script during low load hours.
- After completion, re-enable search reindexing.
Monitoring Progress
When mass updating via the web interface, Bitrix uses a "continuation" mechanism via sessid and hidden fields — every N elements the page reloads with progress. For script processing, it is more convenient to write progress to a file and read it via AJAX:
file_put_contents('/tmp/update_progress.json', json_encode([
'processed' => $processed,
'total' => $total,
'percent' => round($processed / $total * 100),
]));
When updating properties of type "list" (L) en masse, you must first obtain the ID of the list value from b_iblock_property_enum — you need to pass the ID, not the text value.
Typical Errors during Mass Update
- Forgetting to disable search reindexing — each Update call triggers
CSearch::Index(), increasing time by 2-3x. Usedefine('BX_SKIP_SEARCH_REINDEX', true). - Updating one field with several consecutive Update calls instead of one. Each call triggers events and updates cache — extra 100ms per element.
- Not checking script access rights — if the script runs as admin but a user later edits the element, conflicts with business processes may occur.
Timeline and How to Start
Estimated development time for a mass update script is from 2 to 5 working days, depending on complexity. If you need to update products faster and without risk to the production database — write to us. Get a free consultation: we will assess the task and suggest the best option. We guarantee quality and efficiency. Contact us today to speed up your catalog.
Common Mistake: Forgetting to Disable Search Reindexing
Each call to CIBlockElement::Update triggers search reindexing, slowing the process. Use define('BX_SKIP_SEARCH_REINDEX', true) to avoid this.See the official 1C-Bitrix API documentation for more details.
The standard tool does not support updating multiple properties (type L with multiple values) and conditional updates. Additionally, it is not optimized for large datasets.
To update multiple properties via mass editing, you need to write a custom script using the API, passing the PROPERTY_VALUES array where each multiple property is an array of list value IDs.