Content distribution system development on 1C-Bitrix

Content distribution system development on 1C-Bitrix

Managing content on a single site is simple. But when you have multiple sites—a network of regional portals, a group of thematic resources, a multilingual project, or a marketplace with storefronts for different channels—manual replication of changes becomes labor-intensive and unreliable. Each edit demands attention, and synchronizing data via copying is a direct path to errors.

A content distribution system automates the dissemination of materials between a source and consumers. We design the architecture, integrate with your existing stack, and configure flexible control: what, where, when, and with what transformations. For example, for a network of 15 regional sites, we cut the time to publish news from 3 hours to 5 minutes, saving the client over 600,000 rubles per year.

This article covers the key elements of such a system: master and child site architecture, distribution rules, transformations, conflict handling, and monitoring. Our engineers bring 10+ years of experience on Bitrix projects, guaranteeing fault tolerance and scalability.

Architecture: master and child sites

The typical scheme is one master site (content source) and several child sites (consumers). On Bitrix, this can be implemented in several ways depending on infrastructure:

• Multi-site Bitrix — if all sites are on one installation. As per the 1C-Bitrix documentation, multi-site supports up to 50 sites per installation. Infoblock elements are tied to sites via b_iblock_site. One element can be active on multiple sites simultaneously. Management via the ACTIVE field and site linking.
• Distributed scheme — separate Bitrix installations. Requires an API layer: master publishes content via REST API or message queue; child sites subscribe and receive updates.
• Hybrid — CDN for media files, API for structured content, direct database replication for urgent updates (lag up to 2 seconds).

How does the infoblock distributor work?

To track what has been distributed where, a custom table is needed:

CREATE TABLE content_distribution ( ID INT AUTO_INCREMENT PRIMARY KEY, SOURCE_ELEMENT_ID INT NOT NULL, SOURCE_IBLOCK_ID INT NOT NULL, TARGET_SITE_ID VARCHAR(8) NOT NULL, TARGET_ELEMENT_ID INT, STATUS ENUM('pending','published','failed','excluded') DEFAULT 'pending', PUBLISHED_AT DATETIME, ERROR TEXT, INDEX (SOURCE_ELEMENT_ID), INDEX (TARGET_SITE_ID, STATUS) ); 

When an element is published on the master, the OnAfterIBlockElementAdd/Update event triggers distribution. The handler checks the rules and writes tasks to the table.

What distribution rules to set?

A flexible rule system defines which content goes where:

$distributionRules = [ [ 'source_iblock_id' => 5, // Infoblock "News" 'target_sites' => ['s2', 's3', 's4'], 'filter' => [ 'PROPERTY_CATEGORY' => [1, 2], ], 'transform' => 'NewsTransformer', 'delay' => 0, ], [ 'source_iblock_id' => 8, // "Promotions" 'target_sites' => ['s2'], 'filter' => ['PROPERTY_REGION' => 'msk'], 'transform' => null, 'delay' => 3600, ], ]; 

Content transformation during distribution

Content is rarely distributed "as is". Typical transformations: link adaptation, translation, regional adaptation, image replacement. About 90% of all elements require link replacement to target sites. Example adaptation:

// Link adaptation $content = preg_replace( '|https://master-site\.ru/([^"\']+)|', 'https://regional-site.ru/$1', $sourceContent ); // Automatic translation via DeepL API $translated = $translationService->translate( $element['DETAIL_TEXT'], from: 'ru', to: $targetSite['LANGUAGE'] ); 

The master site handles up to 50,000 elements, with distribution lag not exceeding 5 minutes.

Why is asynchronous processing faster?

With many sites, synchronous distribution in the event handler is a bad idea: the user would wait several seconds for save. Asynchronous processing via a queue is 3–5 times faster. The event handler creates a task; a cron worker performs the distribution.

// Worker processes 50 tasks per run $tasks = DistributionQueue::getPending(limit: 50); foreach ($tasks as $task) { $distributor->distribute($task); } 

How to handle edit conflicts?

If manual editing is allowed on child sites, merge logic is needed. Policies:

• Always overwrite — simple but loses local edits.
• Don't touch manually edited — flag LOCALLY_MODIFIED.
• Field-level merge — some fields sync, others stay local.

Implementation via a user property of the infoblock element:

// On manual save on the child site CIBlockElement::SetPropertyValues($elementId, IBLOCK_ID, 'Y', 'LOCALLY_MODIFIED'); // On master distribution check the flag $locallyModified = CIBlockElement::GetProperty(IBLOCK_ID, $elementId, [], ['CODE' => 'LOCALLY_MODIFIED'])->Fetch(); if ($locallyModified['VALUE'] === 'Y' && $rule['respect_local_edits']) { // Skip update continue; } 

Distribution monitoring

How to set up distribution: step-by-step

1. Define the scheme: choose multi-site, distributed, or hybrid.
2. Create the tasks table: run the SQL script above.
3. Write event handlers: subscribe to OnAfterIBlockElementAdd/Update.
4. Configure rules: set filters and transformers for each infoblock.
5. Wrap in a worker: run queue processing via cron.
6. Set up monitoring: log statuses and errors.

What's included in distribution system development

• Scheme and rule design
• Multi-site or distributed architecture setup
• API layer development (REST / message queue)
• Transformations implementation (links, translation, regional data)
• Monitoring and logging integration
• Admin training and documentation
• 3-month warranty support

Contact us to discuss your project and get a consultation.

Development stages

Total: 6–10 weeks depending on number of sites and transformation complexity.

Get a consultation for your project — our engineers will help design a turnkey system. Request an evaluation of your task.