Налаштування масової зміни властивостей товарів в 1С-Бітрікс

Налаштування масової зміни властивостей товарів в 1С-Бітрікс

У каталозі 15 000 товарів потрібно проставити нову властивість «Матеріал» у 8 000 позицій певної категорії, виправити друкарську помилку в значенні фасетного фільтра у 2 000 товарів, зняти прапорець «Рекомендований» у половини асортименту. Через картку товару це тижні роботи. Ми вирішуємо такі завдання пакетним оновленням через API з контролем цілісності даних. У нас за плечима більше 10 років досвіду в розробці на Бітрікс — ми знаємо, як оновити властивості тисяч товарів за години, а не дні. На каталозі з 15 000 товарів ручне оновлення зайняло б 3–4 тижні, автоматизація скорочує до 1–2 днів. Економія часу — близько 90%, а вартість розраховується індивідуально — від 100$.

Де зберігаються властивості

Властивості товарів у Бітрікс зберігаються в кількох місцях залежно від типу:

• Поля елемента (NAME, PREVIEW_TEXT, ACTIVE та ін.) — b_iblock_element
• Властивості інфоблоку — b_iblock_element_property, де IBLOCK_PROPERTY_ID — ID властивості, VALUE — значення
• Множинні властивості — кілька рядків у b_iblock_element_property з одним IBLOCK_ELEMENT_ID і одним IBLOCK_PROPERTY_ID
• Властивості типу «Список» — VALUE містить текстове значення, VALUE_ENUM_ID — посилання на b_iblock_property_enum

Для торговельних пропозицій — аналогічна структура, але IBLOCK_ID вказує на інфоблок пропозицій, а не основний каталог. Розуміння цієї структури необхідне для вибору оптимального методу оновлення.

Як масово оновити властивості товарів без просідання продуктивності?

Для невеликих обсягів (до 1 000 елементів) підходить CIBlockElement::SetPropertyValues. Код робочий:

$iblockId   = 10; // ID інфоблоку каталогу
$propertyCode = 'MATERIAL';
$newValue   = 'Хлопок 100%';

// Отримуємо список елементів потрібної секції
$res = \CIBlockElement::GetList(
    [],
    ['IBLOCK_ID' => $iblockId, 'SECTION_ID' => 42, 'ACTIVE' => 'Y'],
    false,
    false,
    ['ID']
);

while ($row = $res->Fetch()) {
    \CIBlockElement::SetPropertyValues(
        $row['ID'],
        $iblockId,
        $newValue,
        $propertyCode
    );
}

Однак на великих обсягах цей метод повільний — він читає поточні значення, порівнює, оновлює. Кожен виклик — кілька SQL-запитів. Для обсягів від 1 000 елементів настійно рекомендуємо пряме оновлення через D7 ORM.

Швидке оновлення через D7 ORM

Для обсягів від 1 000 елементів використовуйте пряме оновлення b_iblock_element_property:

use Bitrix\Iblock\ElementPropertyTable;

// Спочатку отримуємо ID властивості
$propertyId = getPropertyIdByCode($iblockId, 'MATERIAL');

// Отримуємо ID елементів пакетами
$elementIds = getElementIdsBySectionBatch($iblockId, $sectionId, 500);

foreach (array_chunk($elementIds, 500) as $chunk) {
    // Перевіряємо, у кого вже є запис
    $existing = ElementPropertyTable::getList([
        'filter' => [
            'IBLOCK_PROPERTY_ID' => $propertyId,
            'IBLOCK_ELEMENT_ID'  => $chunk,
        ],
        'select' => ['ID', 'IBLOCK_ELEMENT_ID'],
    ])->fetchAll();

    $existingMap = array_column($existing, 'ID', 'IBLOCK_ELEMENT_ID');

    foreach ($chunk as $elementId) {
        if (isset($existingMap[$elementId])) {
            // Оновлюємо існуючий запис
            ElementPropertyTable::update($existingMap[$elementId], ['VALUE' => 'Хлопок 100%']);
        } else {
            // Вставляємо новий
            ElementPropertyTable::add([
                'IBLOCK_ELEMENT_ID'  => $elementId,
                'IBLOCK_PROPERTY_ID' => $propertyId,
                'VALUE'              => 'Хлопок 100%',
            ]);
        }
    }
}

Після прямої зміни таблиці потрібно скинути кеш інфоблоку:

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

Чому після масового оновлення властивостей не працює фасетний фільтр?

Після зміни властивостей, які використовуються в розумному фільтрі (catalog.smart.filter), необхідно перебудувати фасетний індекс. Інакше значення не оновляться у фільтрі. Ми завжди включаємо переіндексацію в процес робіт.

\Bitrix\Iblock\PropertyIndex\Manager::markIblockToReindex($iblockId);
// або примусово:
$indexer = new \Bitrix\Iblock\PropertyIndex\Indexer($iblockId);
$indexer->startIndex();
$indexer->continueIndex(0);
$indexer->endIndex();

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

Особливості оновлення спискових властивостей

Властивості типу «Список» (використовуються у фасетному фільтрі) зберігають у VALUE текстове значення, а в VALUE_ENUM_ID — ID з b_iblock_property_enum. При зміні значення потрібно оновлювати обидва поля.

// Знаходимо ID нового значення в переліку
$enumRes = \CIBlockPropertyEnum::GetList(
    [],
    ['PROPERTY_ID' => $propertyId, 'VALUE' => 'Синій']
);
$enum = $enumRes->Fetch();
$enumId = $enum['ID'];

// Оновлюємо
ElementPropertyTable::update($existingPropId, [
    'VALUE'         => 'Синій',
    'VALUE_ENUM_ID' => $enumId,
]);

Якщо потрібного значення ще немає в переліку — спочатку додайте його через CIBlockProperty::SetEnumValues() або безпосередньо в b_iblock_property_enum.

Імпорт CSV як альтернатива

Для нетехнічних користувачів або регулярних оновлень краще підходить імпорт CSV через Каталог → Імпорт. Шаблон файлу: перший рядок — заголовки з кодами полів (ID, PROPERTY_MATERIAL, PROPERTY_COLOR). Бітрікс оновлює тільки ті властивості, колонки яких присутні у файлі.

Обмеження стандартного імпорту: немає підтримки умов («оновити властивість тільки якщо поточне значення пусте»). Для таких сценаріїв — тільки скрипти.

Покроковий план та порівняння методів

1. Аналіз структури: з'ясувати, які властивості та скільки елементів потрібно оновити.
2. Вибір методу: для <500 товарів — SetPropertyValues, для більших — D7 ORM.
3. Розробка скрипта з контролем помилок та логуванням.
4. Тестування на копії бази або невеликій вибірці (10-20 елементів).
5. Запуск оновлення, скидання кешу та переіндексація фасетів.
6. Валідація результатів.

Порівняння методів:

Що входить у налаштування масової зміни властивостей

У рамках роботи ми:

• Аналізуємо поточну структуру властивостей та дані
• Вибираємо метод (API, D7 ORM, CSV)
• Пишемо скрипти з контролем помилок
• Тестуємо на вибірці
• Запускаємо повне оновлення та перебудовуємо кеш і фасетний індекс
• Надаємо документацію

Гарантуємо збереження даних та мінімізацію простою.

Терміни та вартість

Як замовити налаштування

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

Розробка каталогу 1С-Бітрікс: як перетворити фільтр за 4 секунди на миттєвий відгук

В інтернет-магазині 80 000 товарів, розумний фільтр на Бітрікс гальмує — кожен клік по властивості перетворюється на 4-секундне очікування. Покупець тикає чекбокс «бренд Apple», дивиться на лоадер, що крутиться, і йде до конкурентів. Конверсія падає на 20%. Це знайомий біль. Ми займаємося розробкою каталогу 1С-Бітрікс та фільтрації: проєктуємо архітектуру, яка тримає півмільйона позицій без деградації — завдяки фасетним індексам, правильному вибору сховищ і тегованому кешуванню. Якщо ваш магазин втрачає гроші на повільному фільтрі — замовте аудит поточної архітектури, ми оцінимо проблему за один день.

Як інфоблоки впливають на продуктивність каталогу?

Інфоблоки — основа каталогу, але на проєктах із десятками тисяч товарів вони стають вузьким місцем. Стандартний bitrix:catalog.smart.filter генерує JOIN на 6–8 таблиць властивостей (b_iblock_element_property), і MySQL йде в full scan. Змінюємо підхід: на етапі проєктування визначаємо, які властивості підуть в інфоблок, а які — в Highload-блоки. Для довідкових даних (бренди, міста, розмірні сітки) використовуємо HLB: вони працюють з окремою таблицею без overhead b_iblock_element_property. Коли випадаючий список «Міста» завантажується 8 секунд через 5000 значень — це сигнал переносити їх на HLB. Правильна архітектура дає суттєву економію. Зв'яжіться з нами, щоб прикинути вигоду для вашого проєкту.

Що таке фасетний індекс і чому він важливий?

Основна продуктивність криється тут. Без фасетного індексу кожен клік по фільтру — SQL-запит із JOIN по b_iblock_element, b_iblock_element_property, b_catalog_price і ще парі таблиць. На 100 000 товарів такий запит виконується 2–4 секунди. З фасетним індексом — 30–80 мс. Згідно з офіційною документацією, фасетний індекс скорочує час виконання запиту в десятки разів (у реальних проєктах — до 50 разів). Механізм: 1С-Бітрікс створює таблицю b_catalog_smart_filter, куди складає попередньо розраховані комбінації «розділ + властивість + значення + кількість товарів». При фільтрації движок звертається до цієї плоскої таблиці замість збору даних із нормалізованої структури інфоблоків.

При налаштуванні фасетного індексу часто допускають одні й ті самі помилки. Індекс створюють не для всіх розділів, забувають налаштувати фонову переіндексацію після масового імпорту — тоді лічильники властивостей перестають відповідати реальній кількості товарів. Вмикають у фасет усі властивості підряд, навіть службові, що роздуває таблицю b_catalog_smart_filter. На каталогах понад 300 тисяч позицій її розмір може перевищувати гігабайт — без моніторингу через SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' не обійтися. Висновок: фасетний індекс дає радикальне прискорення, але потребує вдумливого налаштування та автоматичної переіндексації через агент CIBlockCatalog::ReindexFacet або cron.

Чому Highload-блоки швидші за інфоблоки для довідників?

На практиці найкраща архітектура — гібридна. Товари та розділи живуть в інфоблоках — там SEO, візуальний редактор, штатні компоненти каталогу. А довідкові властивості з тисячами значень переносимо в Highload-блоки. Користувацькі дані (обране, переглянуті, порівняння) — теж у HLB, вони швидко зростають, і інфоблоки під це не заточені. Хочете дізнатися, яку архітектуру обрати для вашого каталогу? Зв'яжіться з нами — проаналізуємо структуру даних і дамо рекомендації.

SEO-фільтри: як отримати ЧПУ і не потрапити під фільтр Яндекса?

Стандартний фільтр генерує ?filter[brand]=apple&filter[color]=black — пошуковики такі URL або не індексують, або вважають дублями. А запит «ноутбуки apple чорні» — найконверсійніший низькочастотний трафік. Робимо ЧПУ: /catalog/noutbuki/brand-apple/color-black/ з унікальними title, description і H1. Не шаблонними «Купити {бренд} у Мінську», а осмисленими — з урахуванням конкретної комбінації.

• Канонічні URL — щоб /brand-apple/color-black/ і /color-black/brand-apple/ не дублювалися.
• Контроль кількості комбінацій, що індексуються — 10 властивостей по 20 значень дають мільйони сторінок, Яндекс за таке б'є фільтром.
• Автоматична sitemap для SEO-сторінок фільтрації.
• Адміністративний інтерфейс для менеджера — він сам вирішує, які перетини індексувати.

Замовте впровадження SEO-фільтрів — отримайте готовий інструмент для залучення низькочастотного трафіку зі зростанням конверсії до 30%.

Які методи дають відчутний приріст продуктивності?

• Вибірка лише потрібних полів через arSelect — жодних SELECT * по інфоблоках.
• Керований кеш із тегами: додали товар — кеш перестворився автоматично.
• Композитний кеш для анонімів: TTFB < 100 мс, HTML віддається без запуску PHP.
• Індекси на властивостях, що беруть участь у фільтрації — без них MySQL сканує b_iblock_element_property цілком.
• Моніторинг TTFB: якщо каталог відповідає довше 500 мс — ліземо в slow query log.

Що входить у комплексну розробку каталогу на 1С-Бітрікс?

Ми передаємо не просто робочий код, а повний комплект документації та інструментів для самостійного управління. До deliverables входять:

• Аудит поточної архітектури каталогу та фільтрації.
• Проєктна документація з описом схеми даних, розподілу по інфоблоках і Highload-блоках, фасетного складу.
• Готовий розумний фільтр з ajax-режимом, групуванням і збереженням стану.
• Налаштований фасетний індекс з cron-переіндексацією.
• SEO-фільтри з ЧПУ, унікальними метатегами, канонікалами та sitemap.
• Інтеграція швидкого перегляду та сортувань (AJAX, мобільна адаптація).
• Документація з експлуатації для менеджерів: як додавати властивості, керувати індексами та SEO-комбінаціями.
• Гарантійна підтримка 30 днів після здачі — виправляємо інциденти та відповідаємо на запитання.

Як ми розробляємо каталог: покроковий план

Ми не просто ставимо компоненти. Процес включає:

1. Аудит поточного каталогу — розбір структури властивостей, виявлення вузьких місць, перевірка індексів і кешу.
2. Проєктування архітектури — розподіл даних між інфоблоками та HLB, визначення фасетного складу.
3. Розробка розумного фільтра — кастомізація шаблону, ajax-режим, групування, збереження стану.
4. Налаштування фасетного індексу — створення, cron-переіндексація, моніторинг.
5. SEO-фільтри — ЧПУ, метатеги, канонікали, sitemap.
6. Інтеграція швидкого перегляду та сортувань — AJAX-модалка з фото, ціною, наявністю, попереднє завантаження при наведенні. На мобільних — bottom sheet замість попапа.
7. Навчання менеджерів — як керувати властивостями, індексами та SEO-комбінаціями.
8. Гарантійна підтримка — 30 днів після здачі.

Строки реалізації

Каталог окупається через зростання конверсії та приплив SEO-трафіку по низькочастотці. Покупець знаходить товар за два кліки, а не йде після першого тику у фільтр. Отримайте консультацію — оцінимо ваш проєкт протягом дня та надамо розрахунок вартості з roadmap робіт з розробки каталогу 1С-Бітрікс. Зв'яжіться з нами через форму на сайті — сертифіковані спеціалісти та понад 200 успішних проєктів за плечима.