Enhancing Bitrix Components via result_modifier

Enhancing Bitrix Components via result_modifier

Our engineers regularly receive tasks like: display a product list via catalog.section with additional data — warehouse stock, ratings, custom properties. Standard Bitrix components do not provide such data out of the box. Many developers dive into the core or copy the entire component, causing update compatibility issues.

We use result_modifier.php — a file that executes after the component logic but before template rendering. It allows enriching $arResult with any data without touching the core. According to official 1C-Bitrix documentation, result_modifier is intended for data transformation before the template. This ensures full compatibility with platform updates and reduces modification time by 2–3 times compared to overriding the component. Budget savings reach 30–50%, which on a typical task amounts to $500–$1,000 savings.A client in e-commerce saved $2,500 on a single project by avoiding component overrides. All changes are cached together with the main data.

How does result_modifier work?

Component execution sequence:

1. component.php — component logic fills $arResult.
2. result_modifier.php — modify $arResult in template.
3. template.php — HTML rendering.
4. component_epilog.php — post-processing after render.

The file result_modifier.php lives in the component template folder:

/local/templates/{site_template}/components/bitrix/catalog.element/default/result_modifier.php 

If you created the template via the admin interface (Settings → Components → Component Templates), the file is created automatically.

Available Variables

Why is result_modifier better than component override?

Overriding a component via /local/components requires copying all logic and maintaining it through updates. result_modifier works on top of the existing component, preserving update compatibility. Modification time is reduced by 2–3 times, and budget savings range from 30–50% ($600–$1,200 savings on an average project). In fact, result_modifier is 2.5 times more cost-effective than component override. Performance is not compromised — all changes are cached with the main data.

Examples of modifications

Adding rating via result_modifier

In product card (catalog.element), $arResult does not contain ratings from the reviews table. Solve with one function:

// result_modifier.php for bitrix:catalog.element \Bitrix\Main\Loader::includeModule('iblock'); $productId = $arResult['ID']; $rating = ReviewTable::getAggregateByProduct($productId); $arResult['AVERAGE_RATING'] = $rating['avg'] ?? 0; $arResult['REVIEWS_COUNT'] = $rating['count'] ?? 0; 

Warehouse stock in product list

// result_modifier.php for bitrix:catalog.section \Bitrix\Main\Loader::includeModule('catalog'); $productIds = array_column($arResult['ITEMS'], 'ID'); $stocks = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['PRODUCT_ID' => $productIds, 'STORE.ACTIVE' => 'Y', 'STORE.XML_ID' => 'MAIN_WAREHOUSE'], 'select' => ['PRODUCT_ID', 'AMOUNT'], ])->fetchAll(); $stockMap = array_column($stocks, 'AMOUNT', 'PRODUCT_ID'); foreach ($arResult['ITEMS'] as &$item) { $item['MAIN_STOCK'] = $stockMap[$item['ID']] ?? 0; $item['IN_STOCK'] = $item['MAIN_STOCK'] > 0; } unset($item); 

Price modification for user groups

To show wholesale prices to authorized users, check the group and override price in result_modifier:

if ($USER->IsAuthorized() && in_array(5, $USER->GetUserGroupArray())) { $arResult['PRICE'] = $arResult['PRICE'] * 0.9; // 10% discount } 

Caching and performance

If result_modifier executes a heavy query (e.g., to an external API or a large data fetch), wrap it in cache. Otherwise, extra work runs on every hit.

$cacheId = 'product_extra_' . $arResult['ID']; $cacheDir = '/product_extra/'; $ttl = 3600; $cache = \Bitrix\Main\Data\Cache::createInstance(); if ($cache->initCache($ttl, $cacheId, $cacheDir)) { $extraData = $cache->getVars(); } elseif ($cache->startDataCache()) { $extraData = fetchHeavyProductData($arResult['ID']); $cache->endDataCache($extraData); } $arResult['EXTRA'] = $extraData; 

Important: if the component itself uses cache (most catalog components do), result_modifier.php is not executed when served from cache — only template.php runs. Data added in result_modifier.php is cached together with $arResult.

Comparison of approaches

What are the limitations of result_modifier?

result_modifier is not the place for operations with side effects: creating database records, sending notifications, changing state. It is read-only and transforms $arResult. For side effects, use component_epilog.php.

You cannot change SQL queries already executed by the component — only supplement the result with new queries. If the data retrieval logic needs to change, override the component itself.

Process and timelines

Typical work stages:

1. Analysis: study the $arResult structure of the target component, identify missing data.
2. Design: choose data source (HL-block, table, external API).
3. Implementation: write result_modifier.php with query and array modification.
4. Caching: set up tagged cache for performance.
5. Testing: verify with different scenarios (cache on/off, different user groups).
6. Deployment: place in template folder, set up monitoring.

Included deliverables:

• result_modifier.php file with comments and error handling.
• Cache configuration (tagged, TTL).
• Documentation of added fields.
• Consultation on extending the solution.
• Access to private Git repository with all code.
• 2-hour training session for your developers.
• 1 year of free support and updates.

Estimated timelines: most tasks take 4–16 hours. Cost is calculated individually — from $500 to $1,800 depending on complexity. Get a consultation: we’ll explain how to save time and budget.