Auto-Filling Product Descriptions from External Sources in 1C-Bitrix
Auto-filling descriptions differs from a one-off scraping run: the system must operate in the background, process new products as they appear in the catalog, and not overwrite text that has been manually edited. This requires a well-designed trigger and priority architecture — not simply a script that loops over all products.
Triggers for Filling Descriptions
Auto-filling is initiated in three situations:
When a new product is added — the OnAfterIBlockElementAdd event handler fires. The product has just been created with empty fields; the system goes to the sources to fetch a description.
On a schedule for unfilled items — a cron job finds elements with an empty DETAIL_TEXT and adds them to the queue.
On manual request — a manager clicks "Fetch description" for a specific product in the admin panel.
Source Chain with Fallback
Descriptions are sought in sequence: if the first source yields no result, the next one is tried:
- Manufacturer API by
VENDOR_CODE - Icecat database by EAN/barcode
- Manufacturer website scraping
- AI generation based on name and attributes (last resort)
Each source implements DescriptionProviderInterface::getDescription(string $sku): ?string. The orchestrator iterates through providers in priority order.
Protecting Manual Edits
The key element is a DESCRIPTION_LOCKED property (type S, values Y/N). When a manager manually edits a description in the admin panel:
-
DESCRIPTION_LOCKED = Yis set - The auto-fill system skips that element
The flag is set via the OnBeforeIBlockElementUpdate handler — the system checks whether DETAIL_TEXT has changed relative to its previous value. If it has, and the change did not originate from the auto-fill system, the flag is set.
Queue and Prioritization
Not all products are equally important. Queue priority:
- High: products with active orders or views (data from
b_sale_order_item,b_stat_session) - Medium: new products without descriptions
- Low: old products not viewed in more than 30 days
Implemented via a priority field in the queue table; workers select tasks ORDER BY priority DESC.
Project Timeline
| Phase | Duration |
|---|---|
| Provider architecture, interfaces | 4–8 hours |
| Provider development (1–2 days each) | 2–6 days |
| Triggers, queue, prioritization | 1–2 days |
| Manual edit protection | 4–6 hours |
| Admin management interface | 1 day |
Total: 6–12 working days depending on the number of sources.