1C-Bitrix Project Documentation Services

Documentation for 1C-Bitrix Projects

A developer quit. The new one opens init.php — 2,000 lines, 47 event handlers via AddEventHandler, a chain of agents in b_agent, and a custom module without a single comment. "Getting up to speed" takes a month. Documentation turns that month into three days — and we create it for 1C-Bitrix projects: from architecture diagrams to step-by-step instructions for the content manager.

The Cost of Missing Documentation

Specific situations we see on every other project:

• Core update — a developer runs bitrix/tools/upgrade.php, the update overwrites modified files in /bitrix/components/bitrix/. Nobody knows which components were changed. The site breaks, rollback from backup, downtime — 4 hours
• 1C data exchange — the exchange agent CCatalogImport::PreGenerateXML fails with an error. Why was it configured non-standard? Who changed the property mapping? Without documentation — half a day of reverse engineering
• New contractor — the team receives the project, sees 12 highload blocks without descriptions, custom tables b_custom_order_log and b_product_sync_history. What do they store? How are they related to infoblocks? The answer — nowhere
• Team growth — every new developer spends three weeks following around "the person who knows" instead of opening documentation and working

Technical Documentation

For developers and DevOps — the project's internals:

Architecture:

• Bitrix modules used (sale, catalog, iblock, main, custom)
• Request path: HTTP → nginx → urlrewrite.php → component → template → response
• Server infrastructure: configuration, topology, load balancing

Data structure — the most critical part:

• Infoblocks: types (IBlock::TYPE_ID), sections, properties (PROPERTY_CODE), relationships between infoblocks via "Element binding" property type
• Highload blocks: b_hlblock_entity table, purpose of each block, field structure, user fields (UF_*), indexes
• Custom database tables — why they were created, DDL, relationships with b_iblock_element, b_sale_order, and other standard tables
• Product catalog: price types (b_catalog_group), warehouses (b_catalog_store), cart rules (b_sale_discount)

Custom development:

• Components in /local/components/ — purpose, class.php, input parameters (.parameters.php), templates, dependencies
• Modules in /local/modules/ — API, events, installation scripts
• Event handlers — list of all AddEventHandler/registerEventHandler with descriptions: which event, what it does, criticality
• Agents (b_agent) — schedule, functionality, which ones must not be stopped (1C exchange, mailings, cart cleanup)
• Modified core files — complete list. When updating bitrix/, these files will be overwritten

Integrations:

• 1C exchange: catalog module settings → "Exchange with 1C," CommerceML format, CCatalogImport schedule, property mapping, pitfalls (encodings, timeouts, import.xml size)
• Payment systems: handlers in sale.handlers, operating modes (test/production), callback URLs
• Delivery services: profiles in sale.delivery, calculation algorithms, API keys
• CRM, marketplaces, external APIs: endpoints, authentication mechanisms, sync frequency

User Instructions

For content managers and administrators:

Content manager guide:

• Catalog management: creating infoblock elements, filling properties, working with sections. Which fields are required, which affect the display on the site
• Images: accepted sizes (is auto-resize configured or not?), formats, upload process to DETAIL_PICTURE and PROPERTY_GALLERY
• Promotions and discounts — how to set up a cart rule in "Marketing" → "Cart rules" without breaking pricing. Verification via test order

Administrator guide:

• Users: groups (b_group), access rights to modules and infoblocks
• Order processing: statuses (b_sale_status), payments, refunds
• Backup via "Settings" → "Backup" — with the caveat that for large projects, the built-in backup isn't sufficient

Format:

• Step-by-step with numbering
• Screenshots with annotations — arrows, highlights, labels
• FAQ from real questions collected during training
• Video instructions for non-trivial operations (on request)

API Documentation

For projects with a custom REST API:

• All endpoints: method, URL, purpose, parameters (required/optional), response format
• Authentication: token acquisition mechanism, TTL, refresh
• Rate limiting: limits, HTTP codes on exceeding
• Examples — working cURL commands, not theoretical ones

Tools: Swagger/OpenAPI for interactive documentation, Postman Collection for testing.

Architecture Diagrams

One diagram replaces 10 pages of text:

• Infrastructure — servers, networks, load balancer, database (master-slave?), Redis, CDN. Physical and logical topology
• Components — Bitrix modules, custom components in /local/, external services, relationships
• ER diagram — b_iblock_element, b_sale_order tables, highload blocks, custom tables. Fields, relationships, indexes. Especially critical for custom tables that aren't in the Bitrix documentation
• Data flows — how information moves between Bitrix, 1C, marketplaces, CRM, payment systems
• Site map — what's an infoblock, what's a static page, what's a custom section on a component

Formats: Draw.io, Mermaid (version-controlled in Git), PlantUML.

Operations Procedures

Deploy:

• Step-by-step instructions for staging and production
• Post-deploy checklist: verify homepage, catalog, checkout, 1C exchange
• Rollback procedure — which symlink to switch, which database backup to restore

Backups:

• Schedule: database, upload/, configurations
• Where they're stored and for how long
• Restore procedure — tested, not theoretical
• Monthly test restore

Core update:

• Staging → testing → production. Strictly in this order
• Compatibility check for custom components and modified core files
• bitrix/updates/ — what was updated

Incidents:

• Classification: site down / 500 errors / broken 1C exchange / performance issues
• Contact persons and areas of responsibility
• Action templates for each type

Timeline

We host documentation in Confluence, GitBook, Notion, or Wiki — with access control. We update it with every significant change, because outdated documentation is worse than no documentation — it creates false confidence.