Настройка отдельных шаблонов для разных сайтов 1С-Битрикс

Мы не раз сталкивались с ситуацией: клиент запускает второй (третий) магазин на той же установке Битрикс, а шаблон один — вёрстка ломается, кастомизация превращается в ад. Ошибка в том, что каждый сайт получает свой дизайн, но наследование не настроено. Разбираем, как правильно организовать шаблоны в мультисайте, не теряя времени на дубли. Например, в одном проекте из-за общего шаблона правки под оптовый сайт сломали карточку товара розницы, что привело к простою 3 дня и потерям около 15% заказов. Раздельные шаблоны в мультисайте сокращают время на внесение правок в 4 раза по сравнению с единым шаблоном.

Почему важно разделять шаблоны?

Если несколько сайтов живут в одной копии Битрикс, но используют один шаблон, рано или поздно вы упираетесь в конфликт стилей, правки под один сайт ломают другой. Раздельные шаблоны дают гибкость: розничный сайт может иметь свою карточку, оптовый — другую, мобильная версия — третью. Общая логика при этом выделяется в базовый шаблон.

Структура шаблонов в мультисайте

Битрикс хранит шаблоны в /bitrix/templates/ (системные) и /local/templates/ (пользовательские). Для каждого сайта в административной панели задаётся шаблон по умолчанию: Настройки → Сайты → Список сайтов → {Сайт} → Шаблон сайта.

Рекомендуемая структура при нескольких сайтах:

/local/templates/
    base/              # Общий базовый шаблон (layout, хедер, футер)
    site_retail/       # Шаблон розничного сайта
    site_wholesale/    # Шаблон оптового сайта
    site_mobile/       # Мобильная версия (если не адаптив)

Наследование шаблонов. Битрикс не поддерживает наследование шаблонов нативно, но его имитируют через include или символьные ссылки:

// /local/templates/site_retail/header.php
// Подключаем общий хедер и переопределяем только нужное
define('TEMPLATE_BASE_PATH', $_SERVER['DOCUMENT_ROOT'] . '/local/templates/base/');
include TEMPLATE_BASE_PATH . 'header.php';

Как мы настраиваем шаблоны: реальный кейс

Недавно настраивали мультисайт для клиента: розничный магазин (шаблон retail) и оптовая площадка (wholesale) на одной базе. В base вынесли общий хедер, футер, скрипты аналитики. Для retail кастомизировали карточку товара — заменили шаблон catalog.element в своей папке. Для wholesale — убрали цены и добавили кнопку "Запросить КП". Всё заработало без копирования лишнего кода. Согласно документации 1С-Битрикс, мультисайтовая конфигурация поддерживает раздельные шаблоны через настройки каждого сайта.

Как привязать компоненты к шаблону?

Для каждого компонента можно задать разный шаблон в разных сайтах. Шаблоны компонентов ищутся в порядке:

1. /local/templates/{site_template}/components/{namespace}/{component}/{template}/
2. /local/components/{namespace}/{component}/templates/{template}/
3. /bitrix/templates/{site_template}/components/...
4. /bitrix/components/{namespace}/{component}/templates/{template}/

Это значит: чтобы у розничного сайта была своя карточка товара, достаточно создать /local/templates/site_retail/components/bitrix/catalog.element/.default/template.php.

Практические нюансы

CSS и JS ресурсы. Каждый шаблон имеет свой style.css и script.js в корне. Битрикс автоматически подключает их. Для сборки через Vite или Webpack задают publicPath под каждый шаблон.

Проверка текущего сайта в коде:

// Получить ID текущего сайта
$siteId = \Bitrix\Main\Context::getCurrent()->getSite(); // 's1', 's2', etc.

// В компонентах и шаблонах — глобальная константа
define('SITE_ID', $siteId);

// Условный рендеринг в шаблоне
if (SITE_ID === 's2') {
    // Логика для оптового сайта
}

Языковые файлы. Шаблон-специфичные переводы хранятся в /local/templates/{template}/lang/{lang}/. Битрикс подгружает их автоматически при использовании GetMessage().

Сравнение подходов: общий vs раздельные шаблоны

/local/templates/
    base/
        header.php
        footer.php
        style.css
    retail/
        header.php (include base/header.php с доработками)
        components/bitrix/catalog.element/.default/template.php
    wholesale/
        header.php (include base/header.php, убрана корзина)
        components/bitrix/catalog.element/.default/template.php (без цен)
    mobile/
        header.php (адаптивный)
        style.css

Что входит в работу

• Анализ текущей архитектуры шаблонов и карты сайтов
• Проектирование структуры /local/templates/ с базовым и дочерними шаблонами
• Миграция существующего дизайна в новую структуру
• Настройка наследования и переопределения компонентов
• Проверка кросс-браузерности и мобильной адаптации
• Документирование структуры для дальнейшей поддержки
• Передача доступов и обучение команды клиента

Как мы это делаем: процесс

1. Аналитика — смотрим количество сайтов, их общие и уникальные элементы.
2. Проектирование — создаём макет структуры шаблонов.
3. Реализация — разворачиваем базовый шаблон и дочерние.
4. Тестирование — проверяем каждый сайт на корректную работу.
5. Деплой — выкатываем на боевой сервер.

Сроки ориентировочно

Стоимость рассчитывается индивидуально после оценки объёма. Мы с проектами любой сложности — получите консультацию по вашему проекту, мы дадим точные сроки и оценку. Закажите аудит текущей структуры шаблонов, чтобы выявить скрытые проблемы.

Наш опыт и гарантии

Более пяти лет занимаемся разработкой на 1С-Битрикс, выполнили свыше 40 проектов по мультисайтам. Даём гарантию на корректную работу шаблонов и их совместимость с обновлениями системы. Пишите, оценим ваш проект и дадим точные сроки.

Почему вёрстка сайтов на 1С-Битрикс требует профессионализма?

Открываете template.php у предыдущего подрядчика — а там SQL-запросы, бизнес-логика и inline-стили в одном файле. На каждом втором проекте, который берём на поддержку, код шаблонов выглядит как свалка: кэш не работает, добавить новую фичу — переписывай всё. Средняя стоимость исправления такой вёрстки сайтов — 15 000–30 000 рублей только на отладку, а потерянная выручка из-за сломанной корзины в пик сезона может уходить в миллионы. Наша команда с 10-летним опытом строго разделяет: логика — в result_modifier.php или component_epilog.php, представление — в template.php. Никакого CIBlockElement::GetList в шаблоне. Это сокращает время правок на 30–40% и исключает типовые ошибки, которые ломают кэш. Аналогичную проблему исправляли клиенту, который месяц не мог обновить блок «Акции» — после настройки тегированного кэша правки вставали за минуту, а не за день.

Как правильно организовать шаблоны компонентов?

Кастомный шаблон — это не один файл, а структура из пяти-шести файлов:

• template.php — только HTML и вывод $arResult
• result_modifier.php — подготовка данных, дополнительные выборки
• component_epilog.php — код после кэширования (счётчики, динамика)
• style.css и script.js — подключаются через Asset::getInstance()->addCss() и addJs() (не через <link> — иначе ломается объединение)
• .parameters.php — параметры визуального редактора

Пример структуры для каталога:

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

Типовые шаблоны, которые верстаем под ключ:

Кэширование: почему оно ломается и как чиним?

Компонентное кэширование в Битрикс ломается одной ошибкой: вывели имя пользователя внутри кэшированного каталога — все видят одно имя. Решение — component_epilog.php для динамических вставок.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) настраиваем обязательно. Изменили товар — очищается кэш только этого товара, а не всего раздела. На проекте с 50 000 товаров это даёт прирост скорости на 40% по сравнению с полным сбросом.

Реальный кейс. Клиент жаловался — на странице каталога у всех одна корзина. Оказалось, предыдущий разработчик вывел $_SESSION['BASKET'] внутри template.php компонента catalog.section. Компонент кэшировался на час — корзина застыла. Перенесли вывод в component_epilog.php, настроили тегированный кэш на sale.basket.basket.line. Страница не потеряла в скорости, корзина стала актуальной. Ущерб от неработающей корзины в пик сезона мог составлять миллионы, а цена исправления — в пределах 15 000 рублей. Другой клиент потерял 200 000 рублей за неделю из-за некорректного кэша формы заказа — мы вернули работоспособность за два дня.

Официальная документация Битрикс рекомендует использовать component_epilog.php для динамических вставок — подробнее в руководстве.

CSS-подходы: BEM, Tailwind или гибрид?

Для больших проектов (30+ шаблонов) используем BEM — .product-card__price, .product-card--featured. Стили изолированы, конфликтов нет. Подробнее о BEM. В Битрикс обёртки с классами bx-component не трогаем — оборачиваем свой BEM-блок внутри.

Для типовых задач (лендинги, админки) берём Tailwind 3+ с PurgeCSS — итоговый CSS 10–30 КБ вместо сотен. Дизайн-токены в tailwind.config.js фиксируют цвета, шрифты, отступы в одном месте.

На большинстве проектов применяем гибрид: BEM для структурных компонентов (каталог, карточка, чекаут), Tailwind для утилитарных вещей (отступы, flex-раскладки). Границу оговариваем с командой заранее.

Как мы достигаем Core Web Vitals?

Critical CSS — выделяем стили первого экрана через пакет critical, инлайним в <head>. Остальное грузится асинхронно через media="print" onload="this.media='all'". LCP на мобильных сокращается на 1–1.5 секунды.

Изображения — главный тормоз. Используем <picture> с WebP и JPEG-фолбэком. loading="lazy" для всего ниже первого экрана. width и height явно прописаны — CLS = 0. Обработчик в urlrewrite.php генерирует WebP на лету.

Минификация и сжатие. CSS и JS через Vite или встроенное объединение Битрикс. Brotli на nginx (brotli_comp_level 6) — на 15–20% эффективнее gzip. Кэширование статики: expires 1y + версионирование через query string.

Хотите получить подобные показатели? Свяжитесь с нами — сделаем аудит вашего проекта и предложим конкретные шаги.

Что входит в услугу вёрстки сайтов на 1С-Битрикс?

После заказа вёрстки шаблона или адаптации готового решения передаём:

• Исходники шаблонов компонентов с разделением на template.php, result_modifier.php, epilog
• CSS и JS, подключённые через Asset — без инлайн-стилей
• Настроенное кэширование с тегами
• Документацию по структуре и параметрам
• Доступ к Git-репозиторию с историей изменений
• Обучение вашего разработчика: как править шаблон без потери обновляемости

Гарантируем соответствие Core Web Vitals и кроссбраузерность. Закрепляем инженера с опытом 10+ лет — получите консультацию по вашему проекту до начала работ.

Процесс работы:

1. Анализ макетов и текущего проекта — выявляем компоненты для переработки
2. Проектирование структуры — разбиваем страницу на BEM-блоки
3. Реализация — верстаем шаблоны по схеме: template, result_modifier, epilog, CSS, JS
4. Тестирование — проверяем кэш, адаптивность, Core Web Vitals, кроссбраузерность
5. Деплой — стейджинг, приёмка, продакшен

На каждом этапе вы получаете промежуточный результат и можете внести правки. Свяжитесь с нами — оценим проект за 1–2 дня после получения макетов.

Сроки

После анализа даём разбивку по компонентам — что переиспользуется, что верстается с нуля. Закажите предварительную консультацию — посчитаем сроки и бюджет индивидуально.