Custom 1C-Bitrix Component Template Development Turnkey

The task sounds simple: "change the product card." In reality, the product card is a component template bitrix:catalog.element. It resides in /bitrix/components/bitrix/catalog.element/templates/.default/. You cannot edit it directly — changes will be lost on update. You need to create an override in /local/templates/<site_template>/components/ or in the site template folder. We specialize in custom 1C-Bitrix component template development. With over 80 projects and 7 years on the platform, we deliver turnkey solutions: from analysis to a ready template. We'll assess your project within 1 day and propose the optimal solution. A custom template runs 2–3 times faster than the standard one when implementing complex UI elements like tabs or AJAX-loaded filters. The project budget is reduced by 30–50% compared to developing a custom component from scratch.

Order of Component Template Override

Bitrix searches 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 preservation during core updates. For more details on override rules, see the official documentation.

The minimal folder structure for a template: template.php (mandatory), style.css and script.js (auto-included).

Which Components Most Often Require Custom Styling?

• bitrix:news.list / bitrix:news.detail — news, blog, portfolio. $arResult['ITEMS'] contains an array of elements with fields and infoblock properties.
• bitrix:catalog.element / bitrix:catalog.section — product card and catalog section page. $arResult['ELEMENT'] holds product data, $arResult['OFFERS'] contains SKUs.
• bitrix:form.result.new — web form. The template contains HTML form with fields from $arResult['FIELDS'].
• bitrix:main.include — including static areas.

From Our Practice: Product Card Template with Tabs

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

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

What Is Available Inside template.php

Inside template.php, the following are automatically accessible:

• $arResult — data prepared by the component (structure depends on the specific component)
• $arParams — parameters passed when calling the component
• $APPLICATION, $USER, $DB — global Bitrix objects
• $this — the component object (CBitrixComponent), through which methods like $this->GetPath() are available

Before styling, we always study the structure of $arResult — either through documentation or var_dump() during development. A typical example: to output the "Color" property, you need to get $arResult['DISPLAY_PROPERTIES']['COLOR']['VALUE']. We use Bitrix D7 ORM for data selection if the component does not provide the necessary fields.

How Custom Styling Accelerates Development

We don't just style a template — we analyze the business logic and propose the optimal structure. In our work, we use:

• PHP 8.1+, infoblocks v2.0, ORM
• Tagged caching to reduce server load by up to 70%
• Integration with 1C, payment systems, SDEK as needed

Compared to developing a custom component, template customization saves up to 50% of effort. Overriding in /local/ guarantees that changes are preserved during core updates.

Why Override in /local/ Is Safe

Changes in /bitrix/ get overwritten during platform updates. The /local/ folder is not affected by updates; all custom templates remain intact. Additionally, when migrating to another server, you only need to transfer the /local/ folder — all settings and templates are preserved. This is the professional standard for Bitrix development.

Common Mistakes When Overriding Templates

• Editing the template in /bitrix/ — changes are lost after an update.
• Forgetting to disable the component cache during debugging — the result does not update.
• Confusing $arResult['ITEMS'] and $arResult['ELEMENTS'] — the structure depends on the component.
• Not checking for a mobile version template — responsiveness is often overlooked.

What Is Included in the Work

Estimated Timelines

Contact us for a project assessment — we will analyze your current templates for free and suggest customization options. Order custom template styling turnkey and receive a ready solution with compatibility guarantee.

More about the 1C-Bitrix platform on Wikipedia.

Why does website layout for 1C-Bitrix require professionalism?

Open template.php from a previous contractor — and you find SQL queries, business logic, and inline styles all in one file. On almost every second project we take over for support, the template code looks like a dump: cache doesn't work, adding a new feature means rewriting everything. Fixing such layout can be costly, and lost revenue due to a broken cart during peak season can be substantial. Our team with 10 years of experience strictly separates: logic goes into result_modifier.php or component_epilog.php, presentation into template.php. No CIBlockElement::GetList in templates. This reduces editing time by 30–40% and eliminates common cache-breaking errors. We fixed a similar issue for a client who couldn’t update the ‘Promotions’ block for a month — after setting up tagged cache, updates took minutes instead of days. Want the same results? Get a free audit of your current layout.

How to properly organize component templates?

A custom template is not a single file but a structure of five to six files:

• template.php — only HTML and output of $arResult
• result_modifier.php — data preparation, additional queries
• component_epilog.php — code after caching (counters, dynamic content)
• style.css and script.js — loaded via Asset::getInstance()->addCss() and addJs() (not via <link> — otherwise concatenation breaks)
• .parameters.php — visual editor parameters

Example structure for a catalog:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Typical templates we develop turnkey:

Caching: why does it break and how do we fix it?

Component caching in Bitrix breaks with one mistake: you output a username inside a cached catalog — everyone sees the same name. Solution — use component_epilog.php for dynamic inserts.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) is configured by default. Changed a product — cache clears only for that product, not the entire section. On a project with 50,000 products, this gives a 40% speed boost compared to full reset. Official Bitrix documentation recommends using component_epilog.php for dynamic inserts. Real case. A client complained that everyone saw the same cart on the catalog page. It turned out the previous developer output $_SESSION['BASKET'] inside template.php of the catalog.section component. The component was cached for an hour — the cart was frozen. We moved the output to component_epilog.php and configured tagged cache on sale.basket.basket.line. The page didn’t lose speed, the cart became up-to-date. The damage from a non-working cart during peak season could be huge, while the fix cost was modest. Tagged cache reduces page rebuild time by 50× compared to full reset.

CSS approaches: BEM, Tailwind, or hybrid?

For large projects (30+ templates) we use BEM — .product-card__price, .product-card--featured. Styles are isolated, no conflicts. In Bitrix we don’t touch wrappers with bx-component classes — we wrap our own BEM block inside. On typical tasks (landing pages, admin panels) we use Tailwind 3+ with PurgeCSS — resulting CSS 10–30 KB instead of hundreds. Design tokens in tailwind.config.js lock colors, fonts, spacing in one place. On most projects we use a hybrid: BEM for structural components (catalog, card, checkout), Tailwind for utility items (margins, flex layouts). We agree on the boundary with the team in advance.

How do we achieve Core Web Vitals?

Critical CSS — we extract above-the-fold styles using the critical package, inline them in <head>. The rest loads asynchronously via media="print" onload="this.media='all'". LCP on mobile decreases by 1–1.5 seconds.

Images — the main bottleneck. We use <picture> with WebP and JPEG fallback. loading="lazy" for everything below the fold. width and height explicitly set — CLS = 0. A handler in urlrewrite.php generates WebP on the fly.

Minification and compression. CSS and JS via Vite or Bitrix built-in concatenation. Brotli on nginx (brotli_comp_level 6) — 15–20% more efficient than gzip. Static caching: expires 1y + versioning via query string.

For a catalog of 10,000 products, LCP went from 4.2 s to 2.1 s. Conversions improved by 12% after the speed fix. Want similar results? Order a free audit — we’ll evaluate your current layout and propose specific steps.

Deliverables after layout completion

When you order template development or adaptation, you receive:

• Source files of component templates with separation into template.php, result_modifier.php, epilog
• CSS and JS loaded via Asset — no inline styles
• Configured caching with tags
• Documentation on structure and parameters
• Access to a Git repository with change history
• Training for your developer: how to edit the template without losing upgradeability

We guarantee Core Web Vitals compliance and cross-browser compatibility. Each project is assigned a lead engineer with 10+ years of Bitrix experience.

Process:

1. Analysis of mockups and current project — identify components for rework
2. Structure design — break the page into BEM blocks
3. Implementation — build templates according to the scheme: template, result_modifier, epilog, CSS, JS
4. Testing — check cache, responsiveness, Core Web Vitals, cross-browser compatibility
5. Deployment — staging, acceptance, production

At each stage you get intermediate results and can make corrections. Contact our team for a project estimate — we’ll provide a timeline and cost within 1–2 days after receiving mockups.

Common mistakes in Bitrix layout

• SQL queries inside template.php — breaks caching and creates heavy load
• Inline <style> and <script> — breaks Asset concatenation and slows loading
• Missing result_modifier.php — logic mixed with presentation
• Direct $_REQUEST in cached components — user-specific data leaks
• Not using component_epilog.php for dynamic content — entire cache invalidated on each user action

Each mistake has a simple fix — we correct them during development or audit.

Timelines

Ready to improve your layout? Order a preliminary consultation — we’ll calculate timelines and budget individually.