Component Template Markup for 1C-Bitrix

The task sounds simple: "change the product card." In practice, the card turns out to be the template for the bitrix:catalog.element component, located at /bitrix/components/bitrix/catalog.element/templates/.default/ — which must not be touched (it will be overwritten on update). The override must be created in /local/ or in the site template folder, and the template.php itself uses $arResult variables whose structure is only partially documented.

Component Template Markup for 1C-Bitrix

The Template Override Mechanism

Bitrix looks for a component template in the following order (simplified):

1. /local/templates/<site_template>/components/<namespace>/<component>/<template_name>/
2. /bitrix/templates/<site_template>/components/<namespace>/<component>/<template_name>/
3. /local/components/<namespace>/<component>/templates/<template_name>/
4. /bitrix/components/<namespace>/<component>/templates/<template_name>/

The correct location for custom templates is /local/templates/<template>/components/ or /local/components/. This guarantees that templates survive core and module updates.

The minimum contents of a component template folder: template.php (required), style.css and script.js (connected automatically if present).

What Is Available Inside template.php

Inside template.php, the following are automatically available:

• $arResult — data prepared by the component (structure depends on the specific component)
• $arParams — parameters passed when the component was called
• $APPLICATION, $USER, $DB — global Bitrix objects
• $this — the component object (CBitrixComponent), providing methods such as $this->GetPath()

Before writing markup, always study the $arResult structure — via documentation, var_dump() / print_r() during development, or the bitrix:main.ajax.json component for debugging without polluting the cache.

Common Components for Custom Markup

bitrix:news.list / bitrix:news.detail — news, blog, portfolio. Most often, the list card and the detail page need to be changed. $arResult['ITEMS'] contains an array of elements with info block fields and properties.

bitrix:catalog.element / bitrix:catalog.section — product card and catalog section page. $arResult['ELEMENT'] contains product data, $arResult['OFFERS'] contains trade offers (variants).

bitrix:form.result.new — web form. The template contains HTML form fields generated from $arResult['FIELDS'].

bitrix:main.include — inclusion of static areas: banners, ad blocks, arbitrary HTML.

Case Study: Product Card Template with Tabs

An online medical equipment store. The standard bitrix:catalog.element template displayed the description, specifications, and documents as a single text block. Task: split into tabs — "Description", "Specifications", "Documents" (PDF files from a "File" type info block property).

We created an override at /local/templates/main/components/bitrix/catalog.element/detail/template.php. The template: tabs in pure CSS (:target selectors, no JS dependency), specifications from $arResult['ELEMENT']['DISPLAY_PROPERTIES'], documents from the "File" property with a check for non-empty values. Component caching was left untouched — the template works with the already-prepared $arResult.

Caching and Templates

Bitrix caches the component execution result, but not template.php itself — the template is rendered on every request against cached data. This is important: changes to template.php are visible immediately without clearing the cache. However, if a new field needs to be added to $arResult, either the component parameters must be changed (CACHE_GROUPS, CACHE_TIME), or a custom component must be created.

Timeline