We encountered a situation: a client bought a shipping cost module, but its logic didn't account for loyalty card discounts. Standard means — no way. Direct file editing? A module update would wipe all changes. The customization task — add this specificity without breaking updatability of a ready-made solution. Such tasks make up 30–40% of all requests for module modification.
A ready-made solution from the marketplace covers 70–80% of needs. The remaining 20–30% are business specifics: different shipping cost logic, non-standard fields in the order form, custom appearance matching the brand style, integration with an internal accounting system. Our experience customizing over 100 Bitrix modules in 6+ years confirms: with the right approach, updates do not break custom work. Bitrix customization that preserves updateability is our specialty — we succeed in 95% of cases.
Why is updateability key?
Directly editing files in /bitrix/modules/vendor.modulename/ is the fastest way to get results and the most destructive. On the next module update through the marketplace, all changes are overwritten. Six months later, the module developer releases a critical security update, the client updates — and the customization disappears. Customization via events is 10 times more reliable than file editing and reduces recovery time after an update by 90%. Using the event system is also 5 times faster than modifying core files.
According to official Bitrix documentation, the event system is the primary way to extend functionality. The correct approach is customization through the extension mechanisms that Bitrix provides specifically for this.
Customizing component templates
Most ready-made solutions output data through standard Bitrix24 components. The visual layer is a component template stored separately from the logic.
Copying a template for customization:
Original: /bitrix/components/vendor/component.name/templates/.default/ Custom: /local/templates/SITE_TEMPLATE/components/vendor/component.name/CUSTOM_TEMPLATE/ Or in the site template:
/local/templates/my_template/components/vendor/component.name/.default/ When the module is updated, /local/ is not touched — the custom template remains. When rendering, Bitrix first looks for the template in /local/, then in /bitrix/.
This works for template.php, style.css, script.js of component templates. The component logic (component.php, class.php) remains original. In 80% of cases, copying the template or subscribing to an event is enough.
Customizing logic without editing files
To change business logic without editing module files, Bitrix's event system is used. The event architecture allows subscribing to an action and modifying data before or after it.
Example: a ready-made delivery module calculates cost via the OnDeliveryGetCost event. A custom handler in /local/php_interface/init.php:
AddEventHandler('sale', 'OnDeliveryGetCost', function(&$arDelivery, &$arOrder, &$arOrderPrice) { // Modify delivery cost according to our logic if ($arOrder['REGION'] === 'CUSTOM_REGION') { $arDelivery['PRICE'] = 0; } return EventResult::SUCCESS; }); Popular events for customization:
-
OnBeforeOrderAdd/OnAfterOrderAdd— before and after order creation -
OnBeforeIBlockElementAdd/OnAfterIBlockElementUpdate— work with infoblock elements -
OnBeforeUserLoginByHash— custom authorization -
OnAfterUserAuthorize— actions after authorization
For a list of available module events, see its documentation or run grep -r "AddEventHandler\|RegisterModuleDependences" /bitrix/modules/vendor.modulename/.
Choosing the right method
If you need to change the appearance — copy the template. If you need to add new logic before or after existing logic — use events. If the module is built on D7 and classes can be overridden — inherit the class. Time saved on customization compared to development from scratch — up to 70%, and cost is 2–3 times lower than creating your own module. Customization costs range from $500 to $2000, depending on complexity. For example, a typical delivery logic change costs around $1,200, saving $2,800 versus building a custom module. Our experience shows that proper customization via events costs about $1,200 for typical logic changes, which is 2-3 times cheaper than custom development ($3,000–$4,000).Class inheritance
Many modern modules use OOP and allow overriding classes. If a module declares a class VendorPaymentHandler extends \Bitrix\Sale\PaySystem\ServiceHandler, you create your own class in /local/:
// /local/lib/CustomPaymentHandler.php namespace Custom; class CustomPaymentHandler extends \Vendor\Module\PaymentHandler { public function pay(array $payment): bool { // Add our logic before/after standard $this->logPaymentAttempt($payment); return parent::pay($payment); } } And register it instead of the original via module settings or a corresponding event handler.
D7 extensions and custom fields
In D7 architecture (modules using Bitrix\Main), the following are used to extend behavior:
-
ORM extensions — adding custom fields to existing tables via
UserTypeTableor viaaddCustomSelectFieldsin queries. -
File masks (
.settings.php) — overriding module settings at the site level. -
DI container (
Bitrix\Main\DI\ServiceLocator) — replacing module services with your own implementations.
Bitrix custom fields (UserTypeTable) allow adding arbitrary properties to infoblocks and HL-blocks without modifying module code. This is a safe way to extend.
Limitations of customization without core editing
Some things in ready-made solutions cannot be customized the "right" way:
- SQL queries inside class methods that cannot be overridden.
- Hardcoded redirect URLs.
- Static methods without events.
In such cases, the options are to either negotiate with the vendor for official hooks, or accept that this part will be overwritten on update and document the restoration procedure.
What's included in the work
Deliverables:
- Analysis of the module's source code and identification of extension points.
- Development of custom event handlers or overridden classes.
- Testing for compatibility with current and future module versions.
- Documentation of changes (which files/events are affected).
- Handover of access and instructions for module update.
- Warranty support for 30 days after delivery.
- Training your team on how to apply updates safely.
With 6+ years of experience and over 100 successful Bitrix customizations, we ensure your modifications remain updateable. Order customization with updateability guarantee — contact us to assess your module. A ready-made integration with 1C via CommerceML may require behavioral modifications of the module, and we customize that too.
Customization timelines
| Scope of changes | Timeline |
|---|---|
| Visual template edits (colors, fonts, block layout) | 1–3 days |
| Adding custom fields and their processing via events | 2–5 days |
| Business logic changes (delivery, discounts, statuses) | 3–10 days |
| Integration of a ready-made module with an external system via custom events | 1–3 weeks |
| Deep rework of a ready-made solution's functionality | 3–6 weeks |
If you're not sure whether your module can be modified without losing updateability, contact us — we'll assess and propose a solution. Get a consultation — it's free.

