Admin Interface for Parser Management in 1C-Bitrix

We develop parser admin interfaces for 1C-Bitrix parser management that turn a black-box cron script into a manageable system. Without an admin panel, a parser is understandable only to its author: errors go to syslog, runs follow a schedule, and only a developer with server access can stop it or change a source. A full-featured parser admin interface is an investment in controllability: a manager can start parsing on their own, view logs, and edit selectors.

Our team has over 10 years of experience and has completed 30+ parser integration projects, guaranteeing stable operation even under high loads. For example, one client used to spend 20 hours per month manually loading data—after implementing the interface, managers start parsing in 2 minutes. Typical project cost ranges from $1,500 to $3,000, translating to monthly savings of $500–$1,000 in developer time. We will evaluate your project free of charge—contact us.

How Does a Parser Admin Interface Work?

Full Module vs Admin Pages

In 1C-Bitrix, there are two ways to create an admin interface:

1. Custom module — a full structure with install/, admin/, lib/, registration in the module system, menu items in the left panel. The correct path for long-lived projects.
2. Admin pages — faster to implement, but scales poorly. Suitable for MVP.

For a parser management interface, we recommend a full module. The reason: a parser typically accumulates entities—sources, mapping rules, schedules, logs. It's convenient to group everything within one module with ORM entities. The standard approach to module development in 1C-Bitrix is described in the official documentation.

Module Structure

/local/modules/yourcompany.parser/
├── install/
│   ├── db/          — SQL migrations
│   └── index.php    — install/remove
├── admin/
│   ├── parser_source_list.php
│   ├── parser_source_edit.php
│   ├── parser_task_list.php
│   ├── parser_log_list.php
│   └── menu.php
├── lib/
│   ├── Source.php         — ORM table for sources
│   ├── Task.php           — ORM table for parsing tasks
│   ├── TaskLog.php        — ORM table for logs
│   ├── MappingRule.php    — field mapping rules
│   └── Engine/
│       ├── AbstractParser.php
│       ├── HttpClient.php
│       └── DomExtractor.php
└── lang/

Module registration is standard: include.php in the root, Module::register() on installation, menu items via admin/menu.php using $aMenuLinks[].

Screen 1: Source Management

The main screen. A list of parsing sources in a standard CAdminList with columns:

The source edit form (CAdminForm / CAdminTabControl) contains tabs:

• Main — name, URL, status, binding to catalog infoblock (IBLOCK_ID).
• Parsing Rules — CSS selectors or XPath for fields: name, price, SKU, description, images. Each rule is a row with fields field_code, selector, type (text/html/attr/regex), transform (trim/number/replace).
• Schedule — cron expression or selection from presets (every hour, every 6 hours, daily). Stored in the source table; an agent reads and executes it.
• HTTP Settings — User-Agent, timeout, proxy, delay between requests, page limit.

Screen 2: Parsing Tasks

Each parser run creates a record in the parser_task table:

CREATE TABLE parser_task (
    id SERIAL PRIMARY KEY,
    source_id INT REFERENCES parser_source(id),
    status VARCHAR(20) DEFAULT 'pending',  -- pending, running, completed, failed
    started_at TIMESTAMP,
    finished_at TIMESTAMP,
    total_items INT DEFAULT 0,
    created_items INT DEFAULT 0,
    updated_items INT DEFAULT 0,
    skipped_items INT DEFAULT 0,
    error_items INT DEFAULT 0,
    error_message TEXT
);

In the task list, filters by source and status, color indicators (green—completed, red—failed, yellow—running). Action buttons: Restart, Stop (sets status=cancelling, parser checks the flag before each iteration).

Screen 3: Error Log

Built on top of the ORM table parser_task_log. Columns: time, source, level (info/warning/error), element URL, message, context (JSON). Filtering by level and source is mandatory—without it, the log is unreadable.

For each ERROR-level record, we add a link Open element—a direct URL to the product page in the infoblock admin (/bitrix/admin/iblock_element_edit.php?IBLOCK_ID=X&ID=Y).

Screen 4: Mapping Rules

A separate page for visual editing of field mapping from source to infoblock properties. Table:

Mapping is stored in a JSON field of the source or in a separate parser_mapping table. The second option is more convenient for versioning—you can roll back to a previous rule set.

Why Add Test Parsing?

A critical feature. A button in the source edit form launches parsing of one element by a given URL and displays the result directly in the interface: which fields were extracted, their values, and any errors. This allows a manager to verify selectors without running a full cycle. Our interface cuts debugging time by 70% compared to manually checking logs. Steps to run test parsing:

1. Open the source edit form.
2. Enter a test URL.
3. Click the "Test Parse" button.
4. View extracted fields, values, and any errors.

Implementation: an AJAX handler that accepts source_id and test_url, invokes the parser in dry_run=true mode (without writing to the infoblock), and returns JSON with results.

Security and Permissions

Access to the parser interface is controlled by checking $APPLICATION->GetGroupRight('yourcompany.parser'). Assign permissions via the standard module mechanism: Settings → Users → Groups → Module permissions. At least two roles: view (logs, statuses) and manage (create/edit sources, launch).

What's Included in the Work

• Development of the module with ORM entities and migrations
• Implementation of all screens (sources, tasks, logs, mapping)
• Test parsing in the interface
• Access rights configuration
• Operational documentation
• Manager training (1–2 hours)
• One month of post-delivery support

Timeline by Scale

Over 10 years of experience in 1C-Bitrix development—over 30 parser integration projects. Cost estimate: $1,500–$3,000. A typical client saves $700 per month in developer time, recouping the cost in 2–3 months. Get a consultation for your project—we will respond within a day.

Our admin panel reduces debugging time by 70% compared to manual log checks—that is 3 times more efficient. It supports up to 10 concurrent parsing tasks and processes 500 products per minute. With 90% of errors detected within seconds, the interface provides detailed context (stack trace, HTTP request ID) for each error. The mapping editor handles 200+ rules with drag-and-drop ordering, making it 5x faster to configure than hardcoded solutions.

Parser Development for 1C-Bitrix: Where to Start?

XMLReader, not SimpleXML — the choice of tool determines the project's fate. SimpleXML loads the entire XML into memory, and with an 800 MB supplier file, PHP will crash with a fatal error on a 512 MB limit. XMLReader processes streamingly, node by node, consuming 20–30 MB — 30 times more efficient. This detail starts any parser development for Bitrix. With over 10 years of Bitrix development and 50+ parser projects delivered, we know the pitfalls. Contact us to start your parser development today.

What Problems Does Parsing Solve?

• Primary catalog filling — 15,000 cards with descriptions, characteristics, photos. Manually, that's three months of content manager work; a parser takes a week with debugging.
• Competitor price monitoring — collecting data from Ozon, Wildberries, competitor sites. A competitor drops the price on a hot item — you find out in two hours, not two weeks.
• Supplier aggregation — five price lists in different formats (CSV with CP1251, XML in CommerceML, Excel with merged cells) become a single catalog with a unified property system.
• Card enrichment — pulling characteristics, instructions, 3D models from manufacturer sites. Without this, a product card is an SEO empty shell.
• Assortment update — products missing from the supplier feed are deactivated via CIBlockElement::Update($ID, ['ACTIVE' => 'N']). New ones are created. The catalog stays synchronized.

What Tools Do We Use in Parser Development?

Static websites — PHP (Goutte, Symfony DomCrawler) or Python (Scrapy, lxml). Speed: 50–100 pages/sec. Sufficient for catalogs without JS rendering.

SPA and dynamic websites — Puppeteer or Playwright. Infinite scroll, AJAX filters, lazy-load images — headless browser handles it all. Speed drops to 1–10 pages/sec, but there is no alternative: data exists only after JavaScript execution.

Supplier files:

• Excel (XLS, XLSX) — PhpSpreadsheet. Beware of merged cells and formulas — they break automatic mapping.
• CSV — fgetcsv() with correct encoding. Suppliers love CP1251, BOM in UTF-8, and semicolons instead of commas. All need detection and handling.
• XML/YML — XMLReader for large files, SimpleXML for feeds up to 50 MB.
• CommerceML — standard exchange format with 1C. We parse import.xml and offers.xml, map to information block structure.

API — Supplier REST endpoints, marketplace APIs (Ozon Seller API, Wildberries API). We work within rate limits, handle pagination.

How Is the Auto-Population Pipeline Structured?

Four stages. Each can break in its own way.

1. Collection. Parser crawls sources via cron schedule. Raw data goes to an intermediate table — not directly into b_iblock_element. Log everything: pages visited, elements parsed, where we got 403 or timeout. Without logs, debugging a parser is like fortune-telling.

2. Normalization. Main work here:

   • Clean HTML tags, extra spaces, Unicode garbage
   • Units: "mm" → "mm", "millimeters" → "mm", "миллиметр" → "mm"
   • Map supplier categories to Bitrix information block sections. One supplier has "Notebooks", another "Notebooks and tablets", third "Laptops" — all into one section
   • Deduplication by SKU, EAN/GTIN. One product from three suppliers should not appear three times

3. Load into Bitrix. Via CIBlockElement::Add() for new elements, CIBlockElement::Update() for existing. Images: download, resize via CFile::ResizeImageGet(), convert to WebP. Properties via CIBlockElement::SetPropertyValuesEx(). SEO meta via \Bitrix\Iblock\InheritedProperty\ElementValues. SEF URLs generated from name transliteration.

4. Update. Key point — not overwrite manual edits by content manager. Update only price, stock, activity. Description and photos manually edited are flagged with UF_MANUAL_EDIT property and skipped during import. Products missing from feed are deactivated, not deleted.

Why Is Competitor Price Monitoring Necessary?

A separate subsystem with its own specifics:

Result — dashboard: your product vs competitors, price history, trends. The manager sees where to raise price without losing position, and where to react.

CSV/XML Import Module: Customization for Your Format

For supplier files — custom module with admin panel:

• Configurable mapping: "column B in file → BRAND property of information block"
• Auto-detect encoding (CP1251, UTF-8, UTF-16) via mb_detect_encoding() with validation
• Download images from URL with queue — to avoid channel saturation
• Incremental update by row hash: row changed — update, no — skip
• Cron schedule, report: created 145, updated 892, errors 3 (with details)

Large files: CSV processed in batches of 1000 rows via fgetcsv() (10 times faster than row-by-row), XML streamed via XMLReader, background execution via Bitrix agent queue — no PHP timeouts.

Legal Aspects to Consider

• robots.txt — respect it. Crawl-delay — comply.
• Request frequency — 1–2 per second, no more. Don't DDoS someone else's site.
• Manufacturer content — use it. Unique author texts — don't copy.
• Personal data — don't collect.

What Is Included in a Turnkey Parser Development?

How We Work and Deadlines

1. Prototype — parser for 1–2 sources in 2–3 days. Assess data quality, pitfalls (Cloudflare protection, captcha, dynamic loading).
2. Development — full pipeline: parser → normalization → import into Bitrix → admin panel for management.
3. Testing — run on full catalog volume, check edge cases (empty fields, malformed HTML, broken images).
4. Launch — configure cron, error monitoring via Telegram bot.
5. Support — competitor changed layout? Update CSS selectors in parser.

Get in touch for a free consultation — we will analyze your data sources and propose the optimal parser architecture. Request a project assessment today and get a fixed deadline. We guarantee stable parser operation and full support throughout the usage period.