Parsing Product Images for 1C-Bitrix Catalog Population
A catalog without images doesn't sell. We know this firsthand: on one electronics e-commerce project, we needed to upload 15,000 photos from 50 suppliers. Manual upload would have taken a month. We wrote a parser that did it in two days. Recently, an auto parts store approached us with a catalog of 20,000 items. The supplier provided images only via an API, but the API returned time-limited links. We developed a script that downloaded photos in parallel, handled errors, and bound them to infoblocks. Result: a complete catalog with images in 3 days. In this article, we'll show how to automate image loading for products in 1C-Bitrix, what pitfalls exist, and how to avoid them.
How Bitrix Stores Product Images
Images are stored in the b_file table, physically in /upload/iblock/. As per the official documentation on file storage, an info-block element connects to an image through the fields: Product images are stored in the b_file table, and connection with info-block elements is done via the PREVIEW_PICTURE and DETAIL_PICTURE fields.
-
PREVIEW_PICTURE— preview for listing (ID of record in b_file) -
DETAIL_PICTURE— main photo for the product card - Property of type
F(file) orG(gallery) — for additional images
For a gallery, a property of type F with flag MULTIPLE = Y is used. The standard component bitrix:catalog.element takes images from this property.
Downloading and Saving: Step-by-Step
The process consists of three stages: download the file, save via CFile, bind to the element.
// Step 1: download file (with timeout and retries) $imageData = file_get_contents($imageUrl); // Step 2: save via CFile::MakeFileArray() $tmpFile = tempnam(sys_get_temp_dir(), 'img_'); file_put_contents($tmpFile, $imageData); $fileArray = CFile::MakeFileArray($tmpFile); $fileArray['name'] = $filename; $fileId = CFile::SaveFile($fileArray, 'iblock'); // Step 3: bind to the gallery property CIBlockElement::SetPropertyValuesEx($elementId, $iblockId, [ 'MORE_PHOTO' => ['n0' => ['VALUE' => $fileId]] ]); For multiple images, use indices n0, n1, n2, etc. Important: with a large number of files, use agents or queue processing to avoid execution limits.
Problems When Downloading Images
Hotlinking protection. Many source sites check the Referer. Pass the correct header:
$client->get($url, ['headers' => ['Referer' => 'https://source-site.com']]); Image quality. Not all found photos are suitable for the catalog. Check the minimum size before saving:
$imageInfo = getimagesizefromstring($imageData); if ($imageInfo[0] < 300 || $imageInfo[1] < 300) continue; // skip small ones Duplicates. The same URL may appear on different pages. Cache already downloaded URL → file_id in memory or in a separate table.
Extracting Image URLs from the Source
For one main photo:
$src = $crawler->filter('.product-image img')->attr('src'); For a gallery — images are often in data-attributes or inside JavaScript. Example with data-attributes:
$crawler->filter('[data-image]')->each(function($node) use (&$urls) { $urls[] = $node->attr('data-image'); }); If the image array is in JSON-LD, parse it with standard json_decode.
Handling Existing Images
Do not overwrite images uploaded manually or from 1C. Logic:
- Check
PREVIEW_PICTURE— if 0 or empty, add. - For gallery — add only if the property
MORE_PHOTOis empty. - Mark parsed images with a label in the filename (
parsed_prefix) for later identification.
Why Parsing is More Profitable than Manual Upload?
Parsing images is 10 times faster than manual filling and costs 3-5 times less. This significantly saves the catalog filling budget.
| Parameter | Manual Upload | Parsing |
|---|---|---|
| Time for 10,000 photos | 20–30 working days | 2–4 days |
| Input errors | High probability of typos and mismatches | Minimal (after script debugging) |
| Cost | High (payment of managers) | Low (one-time development) |
| Scalability | Limited by human resources | Easily scalable to any volume |
Parsing pays off already with a catalog of 500 items. In addition, automation eliminates the "human factor" — mixed-up photos or incorrect bindings become a thing of the past.
How to Avoid Duplicates During Parsing?
Duplicates occur when the same URL is downloaded multiple times. Solution: keep track of already processed URLs. The simplest way: store an array url => file_id in script memory or in a separate HL-block. When encountering the URL again, immediately use the saved file_id.
What Our Work on Image Parsing Includes?
- Source analysis — determining page structure, access methods (API, HTML parsing), volume estimation.
- Parser development — script in PHP, taking into account source features (AJAX, protection, captcha).
- Error handling — retry on temporary failures, logging failures, notification of problems.
- Binding to infoblocks — creating new elements or updating existing ones, filling PREVIEW_PICTURE, DETAIL_PICTURE, and gallery properties.
- Testing — run on 100–500 products, checking image quality, size compliance.
- Documentation — description of script architecture, instructions for launch and support.
- Maintenance — if the source changes, we adapt the parser (support contract).
Estimated Timeline
| Stage | Time |
|---|---|
| Source structure analysis | 2–4 hours |
| Downloading, validation, saving via CFile | 1–2 days |
| Binding to info-block elements (preview + gallery) | 4–8 hours |
| Error handling, retry, logging | 4 hours |
| Test run on 500 items | 4 hours |
| Total | 3–5 working days |
For catalogs over 10,000 images, add 1–2 days for parallel loading. Exact timelines depend on source complexity and quality requirements.
Our Experience and Guarantees
We have been developing on 1C-Bitrix for over 5 years and have completed 30+ catalog filling projects. Our engineers are certified and know all the nuances of the API. We guarantee that after parsing, all images will be correctly bound and duplicates excluded. Contact us for an assessment of your project — we will prepare a proposal within a day. Get a consultation on catalog automation.







