Структура шаблонов сайта в Битриксе и поиск header footer

22 октября 2025
11 мин.
295
22 октября 2025

Структура шаблонов сайта в Битриксе: Путеводитель от хаоса к мастерству

Каждый разработчик, впервые открывший файловую систему «1С-Битрикс», испытывал это чувство. Смесь любопытства и легкого замешательства. Где знакомые index.html или main.css? Почему все так... сложно? Он ищет привычные точки входа, пытается найти тот самый header.php, чтобы вставить код аналитики, и натыкается на лабиринт из папок с загадочными названиями. В этот момент рождается миф о «сложности» Битрикса. Но что, если этот лабиринт — не хаос, а тщательно спроектированная система, созданная для стабильности и безопасности? Что, если, поняв ее логику, разработчик превращается из блуждающего странника в архитектора, способного управлять сложнейшими проектами? Эта статья — карта того самого лабиринта.

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

Почему структура шаблонов в Битриксе так важна? Философия системы

Чтобы понять «зачем», нужно сначала ответить на вопрос «почему». Почему нельзя было сделать все проще, как в популярных CMS для блогов? Ответ кроется в трех китах, на которых держится «1С-Битрикс»: надежность, безопасность и обновляемость.

Представьте, что ядро системы, ее компоненты и ваш уникальный дизайн были бы перемешаны в одной папке. Любое системное обновление, исправляющее критическую уязвимость, с высокой вероятностью затерло бы ваши правки. Сайт бы «сломался». Чтобы избежать этого, была создана многоуровневая структура, где каждый элемент занимает свое строго определенное место.

Философия Битрикса заключается в четком разделении: «ядро» системы (engine), «логика» компонентов (components) и «представление» (templates). Ваш дизайн и кастомизация — это верхний, самый гибкий слой, который накладывается на незыблемый фундамент.

Такой подход позволяет:

  • Безопасно обновлять систему. Обновления затрагивают только ядро и системные компоненты, не трогая ваши шаблоны и настройки.
  • Минимизировать ошибки. Разработчик, даже начинающий, с меньшей вероятностью повредит критически важные файлы, так как ему просто не нужно их трогать.
  • Гибко управлять дизайном. Один сайт может иметь несколько шаблонов (например, для основной версии, для промо-акции, для мобильной версии) и легко переключаться между ними.

Поэтому, когда разработчик видит перед собой сложную иерархию папок, он должен понимать: это не усложнение, а продуманная защита. Это ценность бренда, заложенная в архитектуру — стабильность превыше сиюминутного удобства.

Анатомия шаблона сайта: что лежит в папке /bitrix/templates/?

Исторически и по умолчанию все шаблоны сайта располагаются в директории /bitrix/templates/. Каждый подкаталог здесь — это отдельный шаблон. Например, /bitrix/templates/main/. Заглянем внутрь и разберем ключевые файлы, которые составляют скелет любого шаблона.

Основные файлы шаблона

  1. header.php — Пролог. Это не просто «шапка» сайта в привычном понимании. Это файл, который выполняется в самом начале отрисовки любой страницы. Здесь подключаются ядро, мета-теги, стили, скрипты и открываются основные HTML-теги (<html>, <head>, <body>).
  2. footer.php — Эпилог. Аналогично, это не просто «подвал». Этот файл завершает отрисовку страницы: закрывает HTML-теги, подключает счетчики, всплывающие окна и скрипты, которые должны выполняться после загрузки всего контента.
  3. description.php — Паспорт шаблона. Это служебный файл, в котором хранится имя (NAME) и описание (DESCRIPTION) шаблона. Именно эти данные вы видите в административной панели при выборе шаблона для сайта.
  4. styles.css — Основные стили. Файл, который подключается к странице автоматически. В него принято выносить стили, которые определяют общую структуру и внешний вид шаблона.
  5. template_styles.css — Стили для визуального редактора. Стили из этого файла подгружаются в визуальном редакторе, когда контент-менеджер работает со страницами. Это позволяет ему видеть текст и другие элементы в том виде, в котором они будут на сайте.

Помимо этих файлов, в папке шаблона могут находиться папки для изображений (/images/), шрифтов (/fonts/), скриптов (/js/) и, что самое важное, папка /components/, о которой мы поговорим отдельно.

header.php и footer.php: Сердце и основание любой страницы

Новички часто совершают ошибку, воспринимая `header.php` Битрикс и `footer.php` Битрикс как статические HTML-фрагменты. На самом деле, это мощные PHP-скрипты, которые собирают страницу по частям, используя API системы.

В header.php вы обязательно найдете магическую строчку:

<? $APPLICATION->ShowHead(); ?>

Это не просто функция. Это точка, в которую Битрикс собирает и выводит всю служебную информацию для секции <head>:

  • Мета-теги title, keywords, description, которые задаются для каждой страницы отдельно.
  • Подключение системных CSS и JS файлов ядра.
  • Подключение стилей и скриптов, добавленных компонентами на странице.
  • Канонические ссылки, теги Open Graph и многое другое.

Пытаться заменить эту функцию статическим набором тегов — значит лишить систему гибкости. Аналогично, в footer.php часто размещают вызовы счетчиков аналитики и других скриптов, которые должны загружаться последними.

Важный момент: между header.php и footer.php находится «рабочая область» — тот уникальный контент, который принадлежит конкретной странице. Он может быть статическим (из файла) или динамическим (сгенерированным компонентами).

Эволюция подхода: Путь от /bitrix/ к /local/. Почему это революция?

На заре развития платформы все кастомные разработки, включая шаблоны, хранились внутри папки /bitrix/. Это приводило к главной проблеме, о которой мы говорили ранее, — конфликтам при обновлениях. Разработчики боялись нажимать кнопку «Установить обновления», так как это могло привести к непредсказуемым последствиям.

Появление папки /local/ стало тихой революцией и утверждением «бренд-ценностей» системы. Эта папка стала песочницей для разработчика, его личным, неприкосновенным пространством. Принцип работы гениально прост:

Битрикс при поиске любого файла (шаблона сайта, шаблона компонента, модуля) сначала ищет его в папке /local/. Если находит — использует его. Если нет — идет в системную папку /bitrix/ и берет версию по умолчанию.

Это полностью изменило подход к разработке. Теперь редактирование шаблона Битрикс стало безопасным. Правильный алгоритм работы выглядит так:

  1. Создаете в корне сайта папку /local/, если ее нет.
  2. Внутри нее создаете структуру, аналогичную /bitrix/. Например, /local/templates/.
  3. Копируете нужный вам шаблон из /bitrix/templates/ в /local/templates/ и работаете уже с копией.

Теперь вы можете спокойно обновлять систему. Ядро обновится в своей папке /bitrix/, а ваша кастомизированная версия шаблона в /local/ останется нетронутой. Это золотой стандарт разработки на Битриксе. Работа внутри папки /bitrix/ сегодня считается грубейшей ошибкой и признаком низкой квалификации.

Как правильно переопределять файлы и стили? Принцип невмешательства

Итак, мы приняли парадигму /local/. Как это работает на практике? Допустим, нам нужно изменить шапку сайта в стандартном шаблоне. Наши действия:

  1. Мы не трогаем /bitrix/templates/main/header.php.
  2. Мы копируем всю папку /bitrix/templates/main/ в /local/templates/main/.
  3. В панели управления мы проверяем, что для сайта применен именно этот шаблон (он будет один, система сама поймет, откуда его брать благодаря приоритету /local/).
  4. Теперь мы открываем /local/templates/main/header.php и вносим любые необходимые изменения.

Этот же принцип касается и стилей. Хотя файл styles.css подключается автоматически, для более сложных проектов принято использовать другой подход — подключение через API. В header.php можно добавить строку:

use Bitrix\Main\Page\Asset;
Asset::getInstance()->addCss(SITE_TEMPLATE_PATH . '/my-super-styles.css');
Asset::getInstance()->addJs(SITE_TEMPLATE_PATH . '/my-cool-script.js');

Где SITE_TEMPLATE_PATH — это специальная константа Битрикса, которая всегда указывает на папку текущего активного шаблона (неважно, в /local/ или /bitrix/ он лежит). Такой подход дает больше контроля над порядком подключения файлов и является более современным.

Компоненты – строительные блоки сайта. Где их шаблоны?

Если header.php и footer.php — это скелет, то компоненты — это мышцы и органы сайта. Новости, каталоги, формы обратной связи, меню — все это компоненты Битрикс в шаблоне. У каждого компонента есть своя логика (в файле component.php) и свое представление (шаблон).

По умолчанию шаблоны всех системных компонентов лежат здесь:

/bitrix/components/bitrix/

Например, для компонента «Список новостей» (news.list) путь будет таким:

/bitrix/components/bitrix/news.list/templates/

Внутри этой папки обычно лежит шаблон с названием .default — это и есть его внешний вид по умолчанию. В нем вы найдете файлы template.php (основной HTML-код вывода), style.css (стили компонента) и иногда result_modifier.php (файл для дополнительной обработки данных перед выводом).

Понимание этой структуры — ключ к кастомизации практически любого элемента на сайте.

Кастомизация компонентов: Создаем собственный вид без боли

И здесь нам снова на помощь приходит принцип переопределения файлов в Битриксе и волшебная папка /local/. Ни в коем случае нельзя редактировать шаблон компонента в его системной папке /bitrix/components/! Это верный путь к проблемам при обновлении.

Правильный и безопасный способ — скопировать шаблон компонента внутрь вашего шаблона сайта. Звучит сложно, но на деле все логично.

Пошаговый алгоритм кастомизации компонента:

  1. Найти системный шаблон. Допустим, мы хотим изменить внешний вид списка новостей. Идем в /bitrix/components/bitrix/news.list/templates/ и находим там папку .default.
  2. Создать место для копии. В папке нашего шаблона сайта (например, /local/templates/main/) создаем иерархию папок: /components/bitrix/news.list/. Мы в точности повторяем путь, но уже внутри своего шаблона.
  3. Скопировать и переименовать. Копируем папку .default из системного расположения в нашу новую папку (/local/templates/main/components/bitrix/news.list/). Крайне рекомендуется сразу переименовать ее, например, в my-news-list. Это поможет избежать путаницы.
  4. Внести изменения. Теперь мы можем смело редактировать файлы внутри /local/templates/main/components/bitrix/news.list/my-news-list/. Например, изменить верстку в файле template.php.
  5. Подключить новый шаблон. В вызове компонента на странице (обычно это делается в визуальном редакторе или в коде страницы) нужно указать имя нашего нового шаблона — my-news-list.

Все! Теперь компонент новостей на сайте использует наш кастомный шаблон. При этом системный шаблон остался нетронутым, и мы можем обновлять платформу без всяких опасений. Это и есть гибкое управление шаблонами компонентов Битрикс.

description.php и page_templates: Забытые, но полезные инструменты

В тени гигантов header.php и footer.php скрываются менее известные, но полезные файлы. Один из них — description.php. Как уже говорилось, он задает имя шаблона для админки. Это простой, но важный элемент для поддержания порядка в проекте с несколькими шаблонами.

Еще один интересный элемент — шаблоны страниц. Внутри папки шаблона сайта можно создать папку page_templates. В ней можно разместить файлы с готовой версткой и вызовами компонентов (например, news_page.php). В файле templates.php (рядом с description.php) нужно описать эти шаблоны. После этого контент-менеджер при создании новой страницы сможет выбрать готовый шаблон из списка «Тип страницы», что значительно ускоряет его работу и снижает количество ошибок.

Управление стилями и скриптами: От styles.css до современных бандлеров

Подход к работе с CSS и JS тоже эволюционировал. Изначально, все стили и скрипты в шаблоне Битрикс сваливались в styles.css и подключались вручную в header.php. Это работало, но для больших проектов превращалось в хаос.

Современный подход предполагает более гранулярное и управляемое подключение:

  • Asset Manager (API D7): Использование класса Bitrix\Main\Page\Asset (как в примере выше) — это стандарт де-факто. Он позволяет избегать дублирования, управлять зависимостями и подключать ассеты из любого места в коде (включая шаблоны компонентов).
  • Стили компонента: У каждого шаблона компонента есть свой файл style.css. Стили из него применяются только тогда, когда компонент выводится на странице. Это обеспечивает инкапсуляцию и предотвращает конфликты стилей.
  • Интеграция с системами сборки: Продвинутые разработчики интегрируют в свои шаблоны современные инструменты, такие как Webpack или Gulp. Они собирают, минифицируют и оптимизируют все CSS и JS файлы в один или несколько «бандлов», которые затем подключаются через Asset Manager. Это значительно повышает производительность сайта.

Такой путь развития показывает, как система адаптируется к современным веб-стандартам, сохраняя при этом свою базовую архитектуру незыблемой.

Типичные ошибки новичков: Чего следует избегать при работе с шаблонами?

На пути освоения структуры шаблонов Битрикса разработчиков поджидает несколько типичных ловушек. Знание их поможет сэкономить массу времени и нервов.

  1. Редактирование ядра. Повторим еще раз: никогда, ни при каких обстоятельствах не редактируйте файлы в папках /bitrix/components/ и /bitrix/modules/. Всегда используйте механизм копирования в /local/.
  2. Игнорирование кэша. Битрикс агрессивно кэширует все, что можно. Если вы внесли изменения в шаблон компонента, а на сайте ничего не поменялось, — в первую очередь сбросьте кэш.
  3. Жестко прописанные пути (хардкод). Никогда не используйте в коде пути вроде "/local/templates/main/images/logo.png". Вместо этого используйте константу SITE_TEMPLATE_PATH. Это сделает ваш код переносимым и устойчивым к смене названия шаблона.
  4. Чрезмерная логика в `header.php`. Не стоит превращать шапку и подвал в место для сложных вычислений и запросов к базе данных. Это замедлит загрузку каждой страницы сайта. Для сложной логики есть компоненты и другие механизмы.
  5. Один шаблон для всего. Не бойтесь создавать несколько шаблонов компонентов для разных разделов. Например, список новостей на главной может выглядеть иначе, чем в разделе «Новости». Для этого достаточно скопировать и настроить второй шаблон и подключить его в нужном месте.

Понимание этих нюансов отличает опытного разработчика от новичка и позволяет создавать по-настоящему качественные и поддерживаемые проекты.

Ключевые выводы:

  • Золотое правило: Вся кастомная разработка (шаблоны сайта, шаблоны компонентов) должна вестись в папке /local/. Папка /bitrix/ — неприкосновенна.
  • Основа шаблона: Файлы header.php и footer.php являются динамическими PHP-скриптами, а не статичным HTML. Они обрамляют контент каждой страницы.
  • Ключевая функция: Вызов $APPLICATION->ShowHead() в header.php критически важен для корректной работы SEO-модуля, подключения стилей и скриптов.
  • Кастомизация компонентов: Происходит путем копирования их шаблонов по умолчанию (из /bitrix/components/) в специальную папку внутри вашего шаблона сайта (/local/templates/your_template/components/).
  • Приоритет: Система всегда ищет нужный файл сначала в /local/, и только потом в /bitrix/. Это основа безопасной разработки и обновлений.
  • Современное подключение ассетов: Для подключения CSS и JavaScript рекомендуется использовать API-класс Asset Manager вместо прямого прописывания тегов в header.php.
  • Константа SITE_TEMPLATE_PATH: Используйте эту константу для построения путей к файлам внутри шаблона, чтобы избежать проблем при его переименовании или переносе.
  • Разделение ответственности: Структура шаблонов Битрикса специально спроектирована для разделения ядра системы, логики и представления, что обеспечивает стабильность и безопасность.

Заключение

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

Поняв эту логику, разработчик перестает бороться с системой и начинает использовать ее мощь себе во благо. Он обретает уверенность, зная, что его правки не сломаются после очередного обновления, а созданный им сайт будет надежной и стабильной платформой для бизнеса на долгие годы. И в этом переходе от замешательства к мастерству и кроется истинная красота инженерного подхода «1С-Битрикс».