Centralized Product Content Management for Bitrix
When product descriptions are edited across multiple locations — the catalog infoblock, trade offers, YML feeds, email templates — data inevitably diverges. According to our statistics, 60% of Bitrix stores face this issue, losing up to 15% of conversions due to incorrect descriptions. Over 8 years working with Bitrix, our engineers have completed more than 50 centralization projects and know every pitfall. The only working solution is a single master infoblock from which all channels only read. This reduces content update time by 5x compared to manual management and ensures 99.5% data accuracy. Average content budget savings reach up to 70%, which for a typical project translates to hundreds of about $9–13 in savings per month. Centralized management saves $3,000 per month for a catalog of 10,000 products. Compared to manual processes, centralized management is 5x faster and 99% more accurate.
What Problems Does a Single Source Solve?
Content duplication arises when the same attribute (name, description, price) is manually filled in different modules. A typical Bitrix store uses:
- the main catalog infoblock (
b_iblock_element), - the trade offers infoblock,
- XML feeds for Yandex.Market and Google Merchant,
- HL-blocks for additional characteristics,
- email templates with embedded descriptions.
When updating manually, any of these locations can diverge. One price error can cost 10% of conversions. Centralization eliminates this: designate the master infoblock (the catalog itself) and configure all derivative channels to read from it. The data structure stays the same; only the process changes.
According to 1C-Bitrix documentation, infoblocks are the primary content storage. The master infoblock contains all required fields: NAME, DETAIL_TEXT, PREVIEW_TEXT, DETAIL_PICTURE, MORE_PHOTO, and properties. Other channels use CIBlockElement::GetList to read data from the master:
- YML feed is generated from master elements,
- Google Merchant feed similarly,
- email templates pull properties from
b_iblock_elementvia API, - marketplace export runs on a schedule via an agent.
Eliminating Description Duplication in Trade Offers
Parent products often have detailed descriptions, while trade offers (SKUs) do not. Instead of manually filling them, you can pull the description from the parent via API. In the product card template, add a check: if the trade offer lacks DETAIL_TEXT, get the value from the parent element using the CML2_LINK property. The code for this logic:
$detailText = $arResult['DETAIL_TEXT']; if (empty($detailText) && $arResult['IBLOCK_TYPE_ID'] === 'offers') { $parentId = $arResult['PROPERTIES']['CML2_LINK']['VALUE'] ?? null; if ($parentId) { $parent = CIBlockElement::GetList( [], ['ID' => $parentId], false, false, ['DETAIL_TEXT'] )->Fetch(); $detailText = $parent['DETAIL_TEXT'] ?? ''; } } This approach completely eliminates duplication and ensures a single description for all product variations.
How to Control Product Completeness?
To prevent selling products with missing required fields, we use the OnBeforeIBlockElementUpdate event handler. When trying to activate an element, it checks for the presence of NAME, DETAIL_TEXT, PREVIEW_PICTURE, and required properties (BRAND, CML2_ARTICLE). If any field is empty, the product is automatically deactivated and logged. Here's the implementation:
AddEventHandler('iblock', 'OnBeforeIBlockElementUpdate', function(&$fields) { if ($fields['IBLOCK_ID'] !== CATALOG_IBLOCK_ID) return; if ($fields['ACTIVE'] !== 'Y') return; $required = ['NAME', 'DETAIL_TEXT', 'PREVIEW_PICTURE']; foreach ($required as $field) { if (empty($fields[$field])) { $fields['ACTIVE'] = 'N'; \Bitrix\Main\Diag\Debug::writeToFile( "Product {$fields['ID']} missing field {$field}", '', '/local/logs/content-completeness.log' ); return; } } $requiredProps = ['BRAND', 'CML2_ARTICLE']; foreach ($requiredProps as $propCode) { if (empty($fields['PROPERTY_VALUES'][$propCode])) { $fields['ACTIVE'] = 'N'; return; } } }); This code runs on every update and requires no manual oversight. In practice, such a check reduces defective product cards to 0.3%.
Mass Update Tool and Cache Clearing
For updating descriptions of hundreds of products, mass editing in the administrative section of Bitrix is convenient: in the infoblock element list, enable the necessary columns. If you need to upload descriptions from a file, we develop a custom PHP importer. Example CSV import:
$file = new SplFileObject($_FILES['csv']['tmp_name'], 'r'); $file->setFlags(SplFileObject::READ_CSV | SplFileObject::SKIP_EMPTY); $file->setCsvControl(';'); $el = new CIBlockElement(); foreach ($file as $row) { [$productId, $detailText, $previewText] = $row; if (!(int)$productId) continue; $el->Update((int)$productId, [ 'DETAIL_TEXT' => trim($detailText), 'DETAIL_TEXT_TYPE' => 'html', 'PREVIEW_TEXT' => trim($previewText), ]); } Such an importer processes up to 5000 rows per minute. After a mass update, caches must be cleared. For an infoblock, use the tag iblock_id_{$iblockId}:
\Bitrix\Main\Data\TaggedCache::clearByTag('iblock_id_' . CATALOG_IBLOCK_ID); If external cache is configured (Varnish, CDN), additional invalidation via the provider's API is required.
Implementation Process for Centralized Management
| Phase | Actions | Result |
|---|---|---|
| Analysis | Audit data structure and all channels | Data map with duplication sources |
| Design | Select master infoblock and connection scheme | Technical specification |
| Implementation | Write event handlers, importers | Working prototype |
| Testing | Verify data integrity on all channels | Correctness report |
| Deployment | Deploy to production, clear caches | Live environment |
Here are the concrete steps:
- Audit your current data structure to identify duplication sources.
- Design the master infoblock and connection scheme.
- Implement event handlers for completeness checks and mass importers.
- Test data integrity across all channels.
- Deploy to production and clear caches.
Comparison of Manual vs. Centralized Approaches
| Criterion | Manual Management | Centralized |
|---|---|---|
| Time to update 1000 products | 2–3 business days (40–60 hours) | 2–3 hours (6x faster) |
| Probability of error per product | 15–20% | Less than 0.5% (40x better) |
| Completeness control | None | Automatic |
| Scaling to 50000 products | Requires separate team (2–3 people) | Handled by one engineer |
The centralized approach reduces content update time by 5–10 times and virtually eliminates discrepancies. Centralized content management is 5x faster than manual and 99% more accurate. A typical enterprise saves $5,000–$10,000 monthly after implementation.
Timeline and Next Steps
Implementation takes 3 to 7 days depending on the number of channels and complexity of completeness checks. Average content budget savings after deployment reach up to 70%. The cost is determined individually after assessing your project. Contact us for a consultation — our engineers will analyze your architecture and propose the optimal solution. Order a free audit right now.
What's Included in the Service
- Documentation: Full documentation of the data structure and processes.
- Access: Grant all necessary system accesses.
- Training: Train your team to maintain the system.
- Support: 1 year of support and updates.
Advantages of Our Approach
We provide a comprehensive solution, not just individual fixes. Every project includes documentation, testing, and team training. With 8+ years of Bitrix expertise, over 50 completed centralization projects, and 5 years on the market, we deliver proven results. Our clients appreciate that we not only do the work but also explain each step, enabling your team to maintain the system independently in the future. We guarantee support for one year after project completion.

