Автоматичне наповнення зображень товарів у 1С-Бітрікс

Зображення — найважчий за обсягом елемент автонаповнення. 10 000 товарів × 5 фото = 50 000 файлів, які потрібно завантажити, перевірити, оптимізувати та правильно прив'язати до інфоблоку. При цьому система повинна працювати в фоні, не навантажувати сервер у пікові години та не дублювати вже завантажені фото. Ми вирішуємо це завдання під ключ: проектуємо архітектуру завантажувача, налаштовуємо черги та забезпечуємо повний цикл — від парсингу джерела до фінальної прив'язки до товару. Оцінимо ваш проект за один робочий день і запропонуємо рішення без прихованих доробок. Ручне завантаження тисяч зображень займає тижні та коштує дорого; автоматизація дозволяє заощадити до 80% бюджету, що в 5 разів більше ніж при ручній роботі. Працюємо на ринку більше 5 років, реалізували 50+ проектів з автоматизації каталогів. Гарантуємо результат та дотримання термінів. Вартість робіт — від $500 за базовий набір.

Процес автоматизації складається з наступних кроків:

1. Аналіз джерел зображень (API, Icecat, YML, сайти виробників)
2. Розробка завантажувача (парсинг, валідація, оптимізація)
3. Система дедуплікації файлів (кешування URL)
4. Налаштування фонових черг та паралельних воркерів
5. Прив'язка зображень до інфоблоків (прев'ю, галерея)
6. Моніторинг та адміністрування

Джерела зображень

API виробника — найчистіший варіант. Виробники часто надають медіа-бібліотеки партнерам: ZIP-архів з фото за артикулами або API для завантаження за EAN.

Icecat / Syndigo — база даних контенту виробників. Платний доступ, але повністю легальний і з хорошим покриттям електроніки та побутової техніки.

Сайт виробника — парсинг. Пріоритет: знаходимо теги <meta property="og:image"> або JSON-LD image — це часто посилання на зображення в хорошій якості без парсингу галереї.

YML-фід постачальника — тег <picture> містить URL основного фото.

Як уникнути дублювання зображень?

Зберігаємо кеш завантажених URL у Highload-блоці або таблиці:

CREATE TABLE image_download_cache (
    source_url TEXT PRIMARY KEY,
    file_id INT,
    downloaded_at TIMESTAMP
);

Перед завантаженням перевіряємо кеш — якщо URL вже оброблявся і файл існує, використовуємо готовий file_id. Це називається дедуплікацією файлів.

Валідація якості зображень

Не всі знайдені зображення придатні. Обов'язкові перевірки перед збереженням: роздільна здатність не менше 400px, MIME-тип JPEG/PNG/WebP, розмір файлу від 10 КБ. Зображення з водяними знаками або биті відкидаються. Приклад коду:

Оптимізація зображень перед збереженням

Завантажені фото часто більші за потрібне (3000×3000px, 5 МБ). Перед збереженням у Бітрікс:

• Ресайз до максимуму 1500px по більшій стороні (для detail_picture)
• Конвертація CMYK → RGB (типова проблема з фото з поліграфічних джерел)
• Стиснення JPEG до quality 85

Використовуємо Intervention Image:

$image = Image::make($imageData)->resize(1500, null, fn($c) => $c->aspectRatio());
$optimized = $image->encode('jpg', 85)->getEncoded();

Бітрікс сам створює прев'ю через свій resize-механізм (CFile::ResizeImageGet), але вихідник краще віддавати вже оптимізованим.

Фонова обробка та черги

50 000 зображень не можна обробити за один запуск. Архітектура:

• Воркер 1: обходить інфоблок, знаходить елементи без зображень → додає в чергу
• Воркери 2–5: паралельно завантажують і зберігають зображення (4 потоки)
• Розклад: воркери працюють вночі 02:00–06:00, щоб не навантажувати сервер вдень
• Ліміт на сесію: не більше 1000 зображень за один запуск

Інтеграція з 1С через CommerceML дозволяє автоматично оновлювати зображення при зміні даних.

Що входить у роботу

Разом: 6–9 робочих днів. Первинне наповнення 10 000 товарів при 4 потоках — близько 3–4 годин. Вартість робіт — від $500 за базовий набір, оцінимо ваш проект індивідуально. Вартість робіт окупається протягом кількох місяців за рахунок скорочення ручної праці.

Як прискорити завантаження каталогу?

Використовуйте кілька потоків завантаження та кешування. У нашій реалізації ми застосовуємо до 4 паралельних воркерів, що скорочує час обробки 10 000 товарів з 12 годин (послідовний режим) до 3–4 годин. Економія часу очевидна — ви отримуєте готовий каталог за день, а не за тиждень.

Чому варто замовити автоматизацію?

Ручне завантаження зображень для тисяч товарів — це тижні роботи менеджера та висока ймовірність помилок: переплутані фото, неправильні роздільні здатності, дублікати. Автоматизація виключає людський фактор, а всі операції проходять валідацію та логування. Syndigo і Icecat — перевірені джерела, але ми також підтримуємо інтеграцію з будь-яким REST API або YML-фідом. Маємо 5 років досвіду в автоматизації e-commerce, гарантуємо результат. Отримайте консультацію — ми підготуємо комерційну пропозицію з детальним планом робіт і термінами.

З чого почати розробку парсера для 1С-Бітрікс?

XMLReader, а не SimpleXML — вибір інструмента визначає долю проекту. SimpleXML завантажує весь XML у пам’ять, і при файлі постачальника на 800 МБ PHP впаде з fatal error на ліміті 512 МБ. XMLReader обробляє потоково, node за node, споживаючи 20–30 МБ — в 30 разів ефективніше. З цієї деталі стартує будь-яка розробка парсерів під Бітрікс. Ми робимо такі системи вже понад 10 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (CSV з CP1251, XML у CommerceML, Excel з об’єднаними комірками) перетворюються на єдиний каталог із загальною системою властивостей інфоблоку.
• Збагачення карток — підтягуємо характеристики, інструкції, 3D-моделі з сайтів виробників. Без цього картка товару — пустушка для SEO.
• Оновлення асортименту — товари, які зникли з фіду постачальника, деактивуються через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Нові — створюються. Каталог синхронізовано.

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

Статичні сайти — PHP (Goutte, Symfony DomCrawler) або Python (Scrapy, lxml). Швидкість: 50–100 сторінок/сек. Вистачає для каталогів без JS-рендерингу.

SPA та динамічні сайти — Puppeteer або Playwright. Нескінченний скрол, AJAX-фільтри, lazy-load картинок — headless-браузер все це обробить. Швидкість падає до 1–10 сторінок/сек, але альтернативи немає: дані існують лише після виконання JavaScript.

Файли постачальників:

• Excel (XLS, XLSX) — PhpSpreadsheet. Обережно з об’єднаними комірками та формулами — вони ламають автоматичний мапінг.
• CSV — fgetcsv() з правильною кодуванням. Постачальники люблять CP1251, BOM у UTF-8 та крапку з комою замість коми. Все це потрібно детектувати та обробляти.
• XML/YML — XMLReader для великих файлів, SimpleXML для фідів до 50 МБ.
• CommerceML — стандартний формат обміну з 1С. Розбираємо import.xml та offers.xml, мапимо на структуру інфоблоків.

API — REST-ендпоінти постачальників, API маркетплейсів (Ozon Seller API, Wildberries API). Працюємо в рамках rate limits, обробляємо пагінацію.

Як влаштований пайплайн автонаповнення?

Чотири етапи. Кожен може зламатися по-своєму.

1. Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.

2. Нормалізація. Тут основна робота:

   • Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
   • Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
   • Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі

3. Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.

4. Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.

Моніторинг цін конкурентів: необхідність та реалізація

Окрема підсистема зі своєю специфікою:

Результат — дашборд: ваш товар vs конкуренти, історія цін, тренди. Менеджер бачить, де можна підняти ціну без втрати позиції, а де потрібно реагувати.

Модуль імпорту CSV/XML: налаштування під ваш формат

Для файлів від постачальників — кастомний модуль з адмінкою:

• Налаштовуваний мапінг: «колонка B у файлі → властивість BRAND інфоблоку»
• Автодетект кодування (CP1251, UTF-8, UTF-16) через mb_detect_encoding() з перевіркою
• Завантаження зображень за URL з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• Cron-розклад, звіт: створено 145, оновлено 892, помилок 3 (з деталями)

Великі файли: CSV обробляємо батчами по 1000 рядків через fgetcsv(), XML потоково через XMLReader, фонове виконання через чергу агентів Бітрікс — ніяких PHP-таймаутів.

Правова сторона — що важливо врахувати

• robots.txt — поважаємо. Crawl-delay — дотримуємося.
• Частота запитів — 1–2 в секунду, не більше. Не потрібно DDoS-ити чужий сайт.
• Контент виробників — використовуємо. Унікальні авторські тексти — не копіюємо.
• Персональні дані — не збираємо.

Що входить в розробку парсера під ключ?

Скільки часу займає розробка парсера?

Процес і терміни:

1. Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
2. Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
3. Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
4. Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
5. Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.

Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.