Налаштування масового переміщення товарів між розділами 1С-Бітрікс

Реструктуризація каталогу: як не потонути в рутині

Уявіть: розділ «Смартфони» розбивається на підрозділи за брендами — 800 товарів потрібно розподілити за пару годин, інакше простій сайту. Або постачальник змінив категоризацію, і 400 позицій зависли в невірних розділах, пошук видає плутанину, а менеджери витрачають години на ручне оновлення. Якщо робити це руками через адміністративну панель, на 800 товарів піде близько двох тижнів безперервної роботи — лише кліки, без урахування помилок. Єдиний вихід — автоматизоване масове переміщення. Наприклад, в одному проекті ми перенесли 1200 товарів з розділу «Ноутбуки» в «Ультрабуки» за 3 хвилини за допомогою прямого SQL — без помилок і простоїв. Клієнт заощадив понад 40 годин ручної роботи.

Наша методика перевірена на 150+ каталогах з об'ємом від 300 до 50 000 товарів. За роки роботи з 1С-Бітрікс ми вибудували ефективні методи, які враховують внутрішню будову інфоблоків, кешування та права доступу. Нижче — технічний розбір від структури таблиць до оптимізації продуктивності, а в кінці — готове рішення під ваш проект.

Структура розділів і прив'язка товарів

Розділи інфоблоку зберігаються в b_iblock_section. Прив'язка елемента до розділу — поле IBLOCK_SECTION_ID в b_iblock_element (основний розділ). Додаткова прив'язка до кількох розділів — таблиця b_iblock_section_element: IBLOCK_ELEMENT_ID, IBLOCK_SECTION_ID, ADDITIONAL_PROPERTY_ID.

При переміщенні товару потрібно оновити обидва місця:

1. IBLOCK_SECTION_ID в b_iblock_element — основний розділ.
2. Запис в b_iblock_section_element — для коректної роботи фільтрів.

Переміщення через CIBlockElement::Update

Стандартний метод оновлення зі зміною розділу:

\CIBlockElement::Update($elementId, false, [
    'IBLOCK_SECTION_ID' => $newSectionId,
]);

Після Update() Бітрікс автоматично оновлює b_iblock_section_element. Але метод повільний при масовому застосуванні — кожен виклик проходить через події, кеш, права доступу.

Чому пряме SQL-оновлення вигідніше?

При роботі з каталогами від 500 елементів різниця стає критичною. CIBlockElement::Update завантажує модулі Бітрікса, перевіряє права, викликає події. У фоновому режимі це призводить до зависань. Прямий SQL обходить ці шари, але вимагає ретельного контролю цілісності даних. Ми використовуємо його в зв'язці з транзакціями та бекапом.

Пряме SQL-оновлення для швидкості:

global $DB;

$elementIds = implode(',', array_map('intval', $productIds));
$newSection  = (int)$newSectionId;

$DB->Query("
    UPDATE b_iblock_element
    SET IBLOCK_SECTION_ID = {$newSection}
    WHERE ID IN ({$elementIds})
");

$DB->Query("
    DELETE FROM b_iblock_section_element
    WHERE IBLOCK_ELEMENT_ID IN ({$elementIds})
    AND ADDITIONAL_PROPERTY_ID IS NULL
");

foreach ($productIds as $id) {
    $DB->Query("
        INSERT INTO b_iblock_section_element
            (IBLOCK_ELEMENT_ID, IBLOCK_SECTION_ID)
        VALUES
            ({$id}, {$newSection})
    ");
}

Прямий SQL працює в 50-100 разів швидше CIBlockElement::Update() для масових операцій, але вимагає ручного скидання кешу.

Порівняння способів переміщення

Типові помилки при масовому переміщенні

Як скинути кеш після переміщення?

Після масового переміщення кеш компонентів каталогу протухає не відразу. Примусове скидання:

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

// Для конкретних розділів
foreach (array_unique(array_merge($oldSectionIds, [$newSectionId])) as $secId) {
    \Bitrix\Main\Application::getInstance()->getTaggedCache()
        ->clearByTag('iblock_section_' . $secId);
}

Як автоматично розподілити товари по розділах?

Для автоматичного розподілу товарів по розділах на основі властивостей — наприклад, за брендом:

$brandSectionMap = [
    'Apple'   => 125,
    'Samsung' => 126,
    'Xiaomi'  => 127,
];

$res = \CIBlockElement::GetList(
    [],
    ['IBLOCK_ID' => $iblockId, 'IBLOCK_SECTION_ID' => $sourceSection],
    false,
    false,
    ['ID', 'PROPERTY_BRAND']
);

while ($item = $res->GetNext()) {
    $brand    = $item['PROPERTY_BRAND_VALUE'];
    $targetId = $brandSectionMap[$brand] ?? null;
    if ($targetId) {
        \CIBlockElement::Update($item['ID'], false, ['IBLOCK_SECTION_ID' => $targetId]);
    }
}

При великих об'ємах цей скрипт запускається через агент Бітрікса пакетами по 100-200 елементів зі збереженням прогресу в b_option.

Як ми автоматизуємо процес: покроково

1. Аналіз структури — вивчаємо поточні розділи, властивості, права доступу.
2. Розробка скрипту — пишемо SQL або API-скрипт з урахуванням ваших умов.
3. Тестування на копії — запускаємо на staging-копії, перевіряємо цілісність.
4. Запуск у продакшн — виконуємо міграцію в години мінімального навантаження.
5. Скидання кешу — очищаємо теговані кеші та перевіряємо фронт.
6. Документація — передаємо опис процедури на випадок повторення.

Що входить у нашу роботу

• Консультація та аналіз поточної структури каталогу.
• Написання скрипту міграції з урахуванням ваших умов (бренди, властивості, ціни).
• Тестування на staging-копії.
• Запуск у продакшн та скидання кешу.
• Документація по процедурі.
• Гарантійна підтримка 30 днів.

Наш досвід і гарантії

Понад 7 років досвіду розробки на Бітрікс, 150+ успішних проектів з міграції та оптимізації каталогів. Сертифіковані спеціалісти. Економія коштів на адміністрування каталогу досягає 80% при автоматизації. Ми впевнені в якості, тому даємо гарантію на роботу скрипту.

Зв'яжіться з нами, щоб ми оцінили ваш проект і запропонували оптимальне рішення. Замовте налаштування масового переміщення — і забудьте про рутину. Отримайте консультацію інженера по вашому каталогу.

Офіційна документація 1С-Бітрікс: Структура таблиць інфоблоків

Що включає професійне встановлення 1С-Бітрікс

Ми починаємо встановлення 1С-Бітрікс з перевірки innodb_buffer_pool_size. Дефолтне значення MySQL (128 МБ) — вирок для інтернет-магазину з каталогом на 10 000+ товарів. Ми ставимо 70–80% від доступної RAM на виділеному сервері, 50% на VPS. Одна ця налаштування прискорює сайт у 2–3 рази порівняно з дефолтом. Правильна конфігурація сервера заощаджує до 60% вартості хостингу щомісяця. Оцінимо ваш проєкт за один день — отримайте консультацію. Звертайтеся, щоб замовити встановлення під ключ з гарантією продуктивності.

Як вибрати хостинг та редакцію для встановлення 1С-Бітрікс?

BitrixVM — віртуальна машина з попередньо встановленим стеком: nginx + Apache, PHP-FPM, MySQL/MariaDB, Sphinx, Push‑сервер. Для VPS — найкращий старт. Все вже сконфігуровано під Бітрікс, включаючи OPcache, логротацію та firewall. Керування через веб‑панель на порту 8890.

VPS/VDS — золота середина. Мінімальна конфігурація для середнього інтернет‑магазину: 2 vCPU, 4 ГБ RAM, SSD. Оптимальна: 4 vCPU, 8 ГБ RAM. ОС: Ubuntu 22.04 або Debian 12. Якщо не BitrixVM — налаштовуємо стек вручну під задачу. Віртуальний хостинг — тільки для візиток та лендінгів. Вимоги: PHP 8.0+, MySQL 5.7+ / MariaDB 10.0+, 512 МБ RAM, .htaccess. Хостинг‑партнери 1С-Бітрікс — гарантія сумісності. Виділений сервер — для highload. Типова архітектура: веб‑сервер окремо, база даних окремо, Redis/Memcached окремо. На редакції «Ентерпрайз» — веб‑кластер з балансувальником. Хмара (Yandex Cloud, VK Cloud, Selectel) — коли навантаження стрибає: розпродажі, сезонні піки. Автомасштабування через Managed Kubernetes або просто вертикальне масштабування VM.

Вибір редакції — не менш важливий крок. Часта помилка: беруть «Малий бізнес» для магазину, який через півроку виростає до B2B з оптовими цінами та трьома складами. Перехід на «Бізнес» — доплата різниці, дані не втрачаються, але краще передбачити заздалегідь. Наші фахівці підберуть редакцію під поточні завдання і з запасом на зростання. Наприклад, ліцензія «Бізнес» окупається за рахунок мультискладу та обміну з 1С, а неправильний вибір призводить до додаткових витрат, які можуть у 2–3 рази перевищити вартість ліцензії.

Які налаштування сервера критичні для 1С-Бітрікс?

Веб‑сервер та PHP

nginx як reverse proxy + Apache (mod_php) або nginx + PHP-FPM напряму. Другий варіант економить пам’ять — Apache не потрібен. Але деякі модулі Бітрікс використовують .htaccess, тому для сумісності іноді залишаємо Apache. Конфігурація nginx: fastcgi_read_timeout 300 — для довгих операцій (імпорт з 1С), client_max_body_size 1024m — завантаження великих файлів. Закриваємо доступ до .settings.php, .settings_extra.php, bitrix/.settings.php — там паролі до бази. Rewrite‑правила з urlrewrite.php — Бітрікс сам генерує, але при nginx + PHP-FPM потрібно продублювати. PHP 8.0–8.2 з розширеннями: mbstring, curl, gd, xml, json, opcache, redis/memcached. Ключові налаштування php.ini: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, max_execution_time=300, memory_limit=512M, upload_max_filesize=100M, post_max_size=128M. Порівняно з Apache + mod_php, зв’язка nginx + PHP-FPM споживає на 30% менше оперативної пам’яті при однаковому навантаженні — це підтверджено на наших проєктах.

База даних та кешування

MySQL/MariaDB. Ключові параметри my.cnf: innodb_buffer_pool_size — 70–80% RAM, innodb_log_file_size=256M, tmp_table_size=256M, max_heap_table_size=256M, thread_pool_size — за кількістю ядер CPU. Кодування utf8mb4 обов'язково, інакше емодзі та спецсимволи ламаються. Redis кращий за Memcached для Бітрікс — підтримує persistent connections та більш надійний. Налаштовуємо в .settings_extra.php:

'cache' => ['value' => ['type' => ['class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis']]]
'session' => ['value' => ['mode' => 'default', 'handlers' => ['general' => ['type' => 'redis']]]]

Redis прискорює роботу сайту в 1.5 рази порівняно з Memcached завдяки постійним з’єднанням та вбудованому кешуванню сесій.

SSL, пошта та cron

SSL — Let's Encrypt через certbot у 90% випадків. Редирект HTTP → HTTPS (301), HSTS, TLS 1.2/1.3, OCSP Stapling. У Бітрікс перемикаємо на HTTPS у налаштуваннях головного модуля. Пошта: відмовляємося від mail() — підключаємо SMTP (Яндекс.Пошта для домену, Mail.ru для бізнесу). Обов'язково налаштовуємо SPF, DKIM, DMARC. Без SPF листи потрапляють у спам. Тестуємо доставляння через mail‑tester.com — оцінка 9+/10. Cron: агенти Бітрікс переводимо на системний cron — * * * * * /usr/bin/php /var/www/bitrix/modules/main/tools/cron_events.php. На cron вішаємо обмін з 1С (15–60 хв), пошукову переіндексацію, бекапи (mysqldump + rsync, ротація 7+4), очищення тимчасових файлів.

Безпека та адміністрування

Файлова система: власник www-data, директорії 755, файли 644, upload 775. nginx блокує доступ до файлів конфігурації. Вмикаємо Проактивний захист Бітрікс — WAF, контроль активності (блокування після 5 невдалих спроб), перевірку цілісності ядра. Для адмін‑панелі: двофакторна аутентифікація через Google Authenticator або OTP, обмеження доступу за IP через nginx для параноїків.

Скільки часу займає встановлення 1С-Бітрікс та налаштування?

Перевірка після встановлення (покроковий чек‑лист)

1. Монітор продуктивності (/bitrix/admin/perfmon_panel.php) — цілимося в 30+ балів. Нижче 20 — є серйозні проблеми з конфігурацією.
2. Перевірка системи — автоматична перевірка всіх параметрів. Червоні пункти — виправляємо обов'язково, жовті — за ситуацією.
3. Сканер безпеки — перевірка на типові вразливості.
4. PageSpeed Insights — TTFB < 200мс на VPS, LCP < 2.5с.
5. Тестовий обмін з 1С — якщо планується інтеграція, перевіряємо CommerceML‑обмін до запуску.

Додатково перевіряємо версії ПЗ, налаштування кешування, роботу cron, SSL‑сертифікат, SPF/DKIM/DMARC, права доступу, видалення дефолтних користувачів та сторінок. Для проєктів з 54‑ФЗ переконуємося, що налаштована фіскалізація через ОФД‑провайдера.

Що входить у роботу (deliverables)

• Повністю налаштований сервер під 1С-Бітрікс з оптимізацією MySQL, PHP, nginx.
• Встановлена та активована ліцензія потрібної редакції.
• SSL‑сертифікат, поштові налаштування, cron та бекапи.
• Документація: всі параметри конфігурації, доступи, cron‑завдання.
• Навчання контент‑менеджера: як заходити до адмінки, додавати товари, завантажувати зображення.
• Підтримка після встановлення протягом 30 днів — консультації з налаштувань.

Чому варто довірити встановлення професіоналам?

Неправильне встановлення — втрата часу та грошей. Ми бачили проєкти, де магазин на «Старті» не міг витримати 50 відвідувачів, тому що не було налаштовано innodb_buffer_pool_size. Після перенесення на VPS з правильною конфігурацією сайт «полетів». Неправильна конфігурація призводить до невиправданих витрат — іноді в 2–3 рази дорожче, ніж вартість професійного налаштування. Ви отримуєте готову архітектуру, яка масштабується. Замовте встановлення 1С-Бітрікс під ключ — й отримайте надійну платформу для зростання бізнесу. Зв'яжіться з нами — розрахуємо вартість під ваш проєкт. Досвід понад 7 років, реалізовано 120+ проєктів на Бітрікс, включаючи highload‑магазини з каталогами понад 100 000 товарів. Звертайтеся — ми допоможемо налаштувати Бітрікс під ваш проєкт.