Custom 1C-Bitrix Modules: Architecture, ORM, Events, Marketplace

Custom 1C-Bitrix Modules: Architecture, ORM, Events, Marketplace

Made a mistake—modified the core? After an update everything broke, and a year later nobody remembers what was changed or why. A familiar situation? A custom module solves this problem once and for all. We develop modules that never touch the core, are easy to update, and are thoroughly documented. Our experience: over 10 years of 1C-Bitrix development, dozens of successful projects across various industries.

Support cost reduction can reach 40%, and investment in a module pays back in 3–6 months. We guarantee quality and deadline compliance. Contact us to evaluate your project—we will prepare a commercial proposal.

Why avoid core modifications?

A custom module is not just a set of files. It is an architectural solution that must be resilient to updates, maintainable, and secure. Direct SQL queries in code are an outdated approach. Bitrix D7 ORM is better in terms of security and flexibility: it prevents SQL injections and makes data structure changes easy. We use modern patterns: Repository, Service, Event-driven. Certified specialists with experience writing modules for Marketplace ensure your module passes moderation and works stably.

How is the module architecture structured?

A 1C-Bitrix module is a directory in /bitrix/modules/<vendor>.<modulename>/ with a strictly defined structure. Bitrix uses the naming convention <vendor>.<name>, where vendor is the developer's short name.

vendor.modulename/ ├── install/ │ ├── index.php # Installer class (extends CModule) │ ├── db/ │ │ └── mysql/ │ │ ├── install.sql # SQL to create tables │ │ └── uninstall.sql # SQL to drop tables │ └── files/ # Files copied during installation │ └── bitrix/ │ └── components/ ├── lib/ # Classes in namespace Vendor\Modulename\ │ ├── Repository.php │ ├── Service.php │ └── Orm/ │ └── EntityTable.php # ORM entity (D7) ├── lang/ │ ├── ru/ │ │ └── install/ │ │ └── index.php # Language labels │ └── en/ ├── options.php # Module settings page └── include.php # Included via \Bitrix\Main\Loader::includeModule() 

How does ORM D7 work in a module?

Modern modules use Bitrix D7 ORM instead of direct SQL queries. The table class is declared by inheriting from \Bitrix\Main\ORM\Data\DataManager:

namespace Vendor\Modulename\Orm; use Bitrix\Main\ORM\Data\DataManager; use Bitrix\Main\ORM\Fields\{IntegerField, StringField, DatetimeField, BooleanField}; class RequestTable extends DataManager { public static function getTableName(): string { return 'vendor_modulename_requests'; } public static function getMap(): array { return [ new IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new StringField('NAME', ['required' => true, 'size' => 255]), new StringField('EMAIL', ['size' => 255]), new BooleanField('ACTIVE', ['default_value' => true]), new DatetimeField('CREATED_AT'), ]; } } 

Usage:

// Get records $result = RequestTable::getList([ 'filter' => ['ACTIVE' => true], 'select' => ['ID', 'NAME', 'EMAIL'], 'order' => ['CREATED_AT' => 'DESC'], ]); // Add a record RequestTable::add(['NAME' => 'Test', 'EMAIL' => '[email protected]']); 

ORM D7 automatically escapes values, preventing SQL injections, and supports tagged caching. This is important for high-load catalogs.

Events and their registration

A module can subscribe to platform events and generate its own. Registration of an event handler:

\Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', // module 'OnSaleOrderBeforeSaved', // event ['\Vendor\Modulename\EventHandlers', 'onOrderBeforeSaved'] ); 

Generating a custom event for extensibility:

$event = new \Bitrix\Main\Event('vendor.modulename', 'OnRequestAdded', ['REQUEST' => $request]); $event->send(); 

Events allow integrating the module with other systems without changing core code. For example, you can subscribe to an order added event and send data to 1C via CommerceML.

How does module installation work?

The installation process includes several steps:

1. Copy the module to /bitrix/modules/<vendor>.<name>/.
2. Go to admin panel → "Marketplace" → "Installed Solutions".
3. Click "Install". The system runs the installer script (creates tables, copies files).
4. Configure access rights and module parameters via options.php.

Administrative interface

The section in the admin panel is registered via a menu item (/bitrix/menu.php or automatically through the menu.php file in the module folder). Admin section pages reside in /bitrix/admin/vendor_modulename_*.php. For modern projects, the admin interface is implemented as an Inertia/React SPA or as classic Bitrix admin pages using CAdminList, CAdminForm.

Versioning and Marketplace

A module can be distributed through 1C-Bitrix Marketplace. Publication requires: error-free code, language files for ru/en, documentation, compatibility with current PHP and platform versions.

Development process

Estimated timelines

What's included in development?

Within the project, we provide:

• Architectural documentation (ER-diagrams, API description).
• Source code with comments and PHPDoc.
• Language files for ru/en.
• Access to the repository and task management system.
• Administrator training on module operation.
• Warranty support (bug fixes) for 1 month.

Typical mistakes during development and installation

• Incorrect permissions on the module folder (must be 755).
• Missing required dependencies (e.g., sale module).
• Errors in SQL scripts—duplicate indexes.
• Forgot to add an agent for background tasks.

Agents are another powerful mechanism: you can schedule code execution. This is useful for synchronization with external services or cleaning up outdated data.

Get a consultation—we'll show you how to solve your task optimally and save your budget. Learn more about the platform on the official 1C-Bitrix site.