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 $5.4k–7.8k 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.