Customization of a ready-made solution from the 1C-Bitrix marketplace

Customization of Ready-Made Solution from 1C-Bitrix Marketplace

A ready-made solution from the marketplace covers 70–80% of needs. The remaining 20–30% — business specifics: different delivery cost calculation logic, non-standard order form fields, custom appearance matching brand guidelines, integration with internal accounting system. Customization task — add this specificity without breaking update capability of the ready-made solution.

Main problem: updateability vs customization

Direct modification of files in /bitrix/modules/vendor.modulename/ — the fastest way to achieve results and the most destructive. On the next module update through the marketplace, all changes are overwritten. After six months, the module developer releases an important security update, client updates — and customization disappears.

The right approach — customization through extension mechanisms that Bitrix provides specifically for this.

Component template customization

Most ready-made solutions output data through standard Bitrix components. Visual layer — this is the component template, which is stored separately from logic.

Template copying for customization:

Original: /bitrix/components/vendor/component.name/templates/.default/
Custom:   /local/templates/SITE_TEMPLATE/components/vendor/component.name/CUSTOM_TEMPLATE/

Or in site template:

/local/templates/my_template/components/vendor/component.name/.default/

When the module updates, /local/ is untouched — custom template remains. Bitrix on rendering first looks for template in /local/, then in /bitrix/.

This works for template.php, style.css, script.js of component templates. Component logic (component.php, class.php) remains original.

Logic customization through events

To change business logic without editing module files, use Bitrix's event system. Event architecture allows subscribing to an action and modifying data before or after it.

Example: ready-made delivery module calculates cost through OnDeliveryGetCost event. 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 — working with infoblock elements
• OnBeforeUserLoginByHash — custom authorization
• OnAfterUserAuthorize — actions after authorization

List of available module events see in its documentation or via grep -r "AddEventHandler\|RegisterModuleDependences" /bitrix/modules/vendor.modulename/.

Customization through class inheritance

Many modern modules use OOP and allow class override. If a module declares 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 your logic before/after standard
        $this->logPaymentAttempt($payment);
        return parent::pay($payment);
    }
}

And register it instead of the original through module settings or through corresponding event handler.

Configuration customization through parameters

Part of ready-made solution behavior is managed through settings in b_option (Bitrix parameters table). Parameters are read via COption::GetOptionString('module.name', 'param_name'). Change them through module admin interface or directly:

COption::SetOptionString('vendor.modulename', 'custom_param', 'value');

This is the safest customization way — data in DB, doesn't affect files. But only parameters that the module provided are available.

Customization through D7 components and masks

In D7 architecture (modules using Bitrix\Main) for behavior extension use:

• ORM extensions — adding fields to existing tables via UserTypeTable or via addCustomSelectFields in queries
• File masks (.settings.php) — overriding module settings at site level
• DI container (Bitrix\Main\DI\ServiceLocator) — substituting module services with your implementations

What can't be customized without core editing

Some things in ready-made solutions don't support customization the "right" way:

• SQL queries inside class methods that can't be overridden
• Hard-coded redirect URLs
• Static methods without events

In such cases, either negotiate with vendor about official hooks, or accept that this part will be overwritten on update and describe customization recovery procedure.

Customization timelines