Доработка шаблона Битрикс: где ломается вёрстка
Готовый шаблон из маркетплейса почти никогда не встаёт на проект «как есть»: он собран под усреднённый магазин, а на реальном сайте сталкивается с уже установленными модулями, своей структурой каталога и накопленными правками. Доработка шаблона Битрикс начинается не с косметики, а с диагностики — где именно расходится ожидаемое поведение компонентов и фактическая вёрстка.
Первый источник проблем — конфликт компонентов. Шаблон приносит свои версии bitrix:news.list, bitrix:catalog.section и собственные включаемые области, а на сайте уже работают другие вызовы тех же компонентов с иными параметрами кеширования и путями к шаблонам. В итоге один и тот же блок выводится дважды, ломается постраничная навигация или подтягивается чужой result_modifier.php. Разбираться приходится на уровне привязки компонентов к разделам, а не правкой одного файла.
Второй — дубли шаблонов. Мастер установки копирует файлы в /local/templates/, но часть стилей и скриптов остаётся в старом шаблоне, а часть подключается через template_styles.css нового. Правки вёрстки начинают «не применяться»: правишь один файл, а браузер отдаёт другой из-за порядка подключения. Лечится это сведением стилей к единому источнику и явным порядком подключения в header.php.
Третий и самый неприятный — потерянные стили после обновления ядра. Обновление ядра или модуля перезаписывает файлы, лежащие вне /local/, и кастомные правки вёрстки исчезают вместе с ними. Поэтому все изменения шаблона мы держим в /local/ и фиксируем в системе контроля версий: тогда обновление ядра проходит без сюрпризов, а откат к рабочему состоянию занимает минуты, а не часы поиска по логам.
Что даёт переработка шаблона вместо правок
Правки поверх готового шаблона из маркетплейса накапливаются: каждый новый блок добавляет в разметку лишние обёртки, дублирующиеся подключения и переопределения стилей, которые никто уже не отслеживает. Через несколько итераций страница начинает отдавать десятки запросов на иконки и шрифты, а браузер тратит время на пересчёт стилей вместо отрисовки. Переработка шаблона вместо точечных правок убирает этот слой целиком — мы собираем структуру заново под фактическое содержимое сайта, а не под демо-контент поставщика.
Скорость загрузки страниц здесь — не абстрактный показатель, а следствие архитектуры. Когда разметка строится из переиспользуемых компонентов, а ресурсы подключаются по факту их появления на странице, браузер получает готовую структуру раньше и не ждёт загрузки неиспользуемых файлов. На практике это даёт заметный прирост по времени до первой отрисовки и по стабильности показателей при росте контента — новые разделы не тянут за собой вес всего шаблона.
Устойчивость к обновлениям — вторая причина перерабатывать, а не латать. Правки, разбросанные по файлам поставщика, при каждом обновлении маркетплейс-решения приходится переносить заново, и часть из них теряется. Переработка шаблона выносит кастомизацию в отдельный слой поверх базовой темы: обновление ядра и модулей проходит без конфликтов, а наша логика остаётся нетронутой.
Снижение обращений в поддержку — прямой эффект от первых двух пунктов. Когда вёрстка предсказуема, а обновления не ломают блоки, отпадает поток задач вида «съехала форма» или «перестал работать фильтр». Мы фиксируем это в замерах до и после: число инцидентов по фронтенду падает, а высвободившееся время уходит на развитие, а не на тушение регрессий.
Способы доработки: правка на месте или пересборка
Выбор между правкой на месте и пересборкой определяется одним вопросом: переживёт ли доработка следующее обновление шаблона. Если файлы маркетплейс-решения меняются напрямую, при апдейте правки затираются — и всё возвращается к исходному состоянию. Дочерний шаблон решает это иначе: наследует родительский, переопределяет только нужные файлы и компоненты, а обновления родителя подтягиваются без конфликтов.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Правка на месте | Разовый фикс, шаблон больше не обновляется | Обновление затирает изменения; откат — только из бэкапа |
| Дочерний шаблон | Шаблон обновляется, правок много | Нужно переносить переопределяемые файлы; часть настроек дублируется |
| Кастомизация компонентов | Меняется логика вывода, а не вёрстка | Требует понимания структуры; при мажорном апдейте — ревизия |
| Пересборка шаблона | Накопились десятки правок, наследование не спасает | Дольше по срокам; нужна приёмка по всем страницам |
На практике чаще всего комбинируют: дочерний шаблон для вёрстки и стилей, кастомизация компонентов — для логики выборки и вывода. Так обновление родителя не ломает доработку, а изменения остаются точечными и обозримыми.
Отдельно проверяем совместимость с текущим ядром и версией решения: часть методов в старых шаблонах уже не поддерживается, и правка на месте может тянуть за собой устаревший код. Перед началом фиксируем, какие файлы переопределяем, — это и есть граница между безопасной доработкой и пересборкой.
Как мы ведём доработку шаблона Битрикс по шагам
Доработка шаблона из маркетплейса почти никогда не сводится к правке одного файла: шаблон наследует компоненты, свои настройки и переопределения, поэтому сначала нужно понять, где именно живёт нужный блок и что сломается при вмешательстве. Мы ведём работу этапами — так правки остаются предсказуемыми, а обновление шаблона не превращается в пересборку сайта.
Этапы работы
- Аудит шаблона. Разбираем структуру: какие компоненты переопределены, где лежат пользовательские стили и скрипты, какие настройки вынесены в параметры шаблона. Фиксируем точки вмешательства и места, которые трогать нельзя, чтобы не потерять совместимость с обновлениями.
- Схема правок. Согласуем перечень изменений с привязкой к конкретным файлам и компонентам. Отдельно помечаем правки в ядре и в шаблоне — первые переживут обновление, вторые придётся переносить вручную.
- Правки вёрстки и логики. Работаем в дочернем шаблоне или через переопределение компонентов, а не правкой исходников из маркетплейса. Так обновление шаблона не затирает наши изменения.
- Тестирование вёрстки. Проверяем адаптив на реальных разрешениях, поведение форм, выпадающих меню и динамических блоков. Отдельно смотрим страницы, которых не было в демо-контенте: пустые разделы, длинные заголовки, товары без изображений.
- Проверка на копии сайта. Прогоняем изменения на тестовом контуре с реальной базой, чтобы поймать конфликты с установленными модулями и кэшированием до выкладки на прод.
- Передача изменений. Переносим правки на рабочий сайт, сбрасываем кэш, фиксируем список изменённых файлов и инструкцию по обновлению шаблона.
- Сопровождение после выкладки. Отслеживаем поведение ключевых страниц и остаёмся на связи, если после обновления контента что-то поедет.
На выходе заказчик получает не набор разрозненных правок, а управляемый шаблон: понятно, что и где изменено, как это переживёт обновление и к кому вернуться при следующей доработке.
Что заказчик получает после доработки шаблона
После доработки вы получаете не набор разрозненных файлов, а комплект, по которому шаблон можно сопровождать без нас: обновлённый шаблон, схему компонентов и инструкцию по правкам. Ниже — что именно входит в передачу и зачем каждый артефакт нужен.
- Обновлённый шаблон — рабочая копия с внесёнными правками, развёрнутая на вашем стенде. Отличия от исходной версии из маркетплейса зафиксированы отдельным перечнем, чтобы при следующем обновлении поставщика было видно, что переносить.
- Схема компонентов — карта страниц и включений: какой компонент за что отвечает, где наследуются параметры, какие места шаблона переопределены. По ней новый разработчик входит в проект за часы, а не за дни разбора чужого кода.
- Инструкция по правкам — где менять тексты, баннеры, контакты и меню через админку, а где требуется вмешательство в код. С экранами и точными путями к разделам, чтобы контент-менеджер не трогал лишнего.
- Резервная копия — полный слепок сайта и базы до начала работ. Это точка возврата: если правка даст неожиданный эффект на боевом сайте, откат занимает минуты, а не часы восстановления.
- Перечень изменённых файлов — список затронутых шаблонов и стилей с пояснением, зачем менялся каждый. Позволяет точечно переносить правки на другие сайты вашей сети.
- Зафиксированные настройки окружения — какие модули и версии ядра использованы, какие права у групп пользователей. Без этого шаблон ведёт себя по-разному на стенде и в проде.
- Регламент обновлений — порядок действий при выходе новой версии шаблона от поставщика: что сравнивать, что переносить вручную, как проверять результат до публикации.
Комплект закрывает главный риск доработки готового шаблона — зависимость от одного исполнителя. Схема и инструкция описывают систему так, что её можно развивать силами своей команды или другого подрядчика. Опишите задачу — вернёмся с оценкой и планом передачи.
Кейс: переработка шаблона интернет-магазина
Клиент пришёл с магазином на готовом шаблоне из маркетплейса 1С-Битрикс: каталог на несколько тысяч позиций, десятки свойств у товара, тяжёлые баннеры на главной. Шаблон работал, но каждая правка тянула за собой каскад: меняли блок — рассыпалась сетка на соседних страницах, а на карточке товара всплывали ошибки вёрстки, которые годами никто не замечал.
Что было до
Замеры на реальном трафике показали: страница каталога отрисовывалась за 4,5 секунды, карточка товара — за 6. В консоли — 40+ ошибок вёрстки: дублирующиеся идентификаторы, вложенные блоки с фиксированной шириной, изображения без размеров. Шаблон тянул все стили и скрипты на каждой странице, включая те, что нужны только на главной.
Что изменили
Разобрали шаблон на слои: базовый каркас, компоненты каталога, карточка товара. Вынесли подключение ресурсов на уровень конкретных страниц вместо общего шаблона, переписали сетку каталога без фиксированных ширин, добавили размеры изображениям и отложенную загрузку для блоков ниже первого экрана. Отдельно прошли по всем шаблонам компонентов и убрали дублирующиеся запросы к свойствам товара.
Что стало
Отрисовка каталога — 1,8 секунды вместо 4,5, карточка товара — 2,4 вместо 6. Число ошибок вёрстки сократилось с 40+ до нуля по валидатору. Правки перестали ломать соседние страницы: новый блок добавляется в свой слой и не задевает остальные. Дальнейшие доработки шаблона идут предсказуемо — без регресса по уже проверенным страницам.
Кейс показателен тем, что шаблон из маркетплейса не нужно выбрасывать: при аккуратной переработке он даёт ту же скорость, что и кастомная вёрстка, но без затрат на разработку с нуля.
Чем отличается дочерний шаблон от копии основного?
Дочерний шаблон — это отдельная папка, которая подключает родительский шаблон и переопределяет только те файлы, которые нужно изменить: шапку, подвал, отдельные компоненты, стили. Всё остальное наследуется из родителя по цепочке. Копия основного шаблона — это полный слепок всех файлов в новую папку, после которого связь с оригиналом теряется: правки в родителе больше не приходят, а обновления приходится переносить вручную.
Разница проявляется при обновлении шаблона из маркетплейса. Если стоит дочерний шаблон, обновление родителя подтягивает исправления, новые компоненты и правки безопасности — ваши переопределённые файлы остаются нетронутыми, конфликтов нет. Если стоит копия, обновление либо перезаписывает вашу кастомизацию, либо не устанавливается вовсе: система видит изменённые файлы и требует разрулить конфликт вручную. Чем больше правок накопилось, тем дороже каждое обновление.
Наследование стилей работает по тому же принципу. Дочерний шаблон подключает стили родителя и добавляет свои поверх — каскад собирается предсказуемо, а обновление родительских стилей не ломает ваши доработки. В копии стили продублированы целиком, и любое обновление превращается в сравнение двух наборов файлов.
Практический вывод: копию делают только тогда, когда шаблон заброшен и обновлений не будет. Во всех остальных случаях — дочерний шаблон. Он сохраняет возможность обновления шаблона, изолирует ваши правки от родительских и сокращает объём кода, который нужно сопровождать.
Частые технические сомнения по доработке шаблона
Шаблон из маркетплейса — это не монолит, а набор компонентов, шаблонов компонентов и файлов в local/templates. Правки, внесённые в него напрямую, при следующем обновлении маркетплейс-решения затираются: обновление перезаписывает файлы шаблона целиком, и доработки исчезают вместе с ними. Именно поэтому первый технический вопрос — не «можно ли доработать», а «как доработать так, чтобы обновления не ломали результат».
Мы разносим доработку и шаблон: изменения уходят в дочерний шаблон, кастомные компоненты — в пространство имён проекта, а логика, которую нельзя вынести файлом, закрывается обработчиками событий. Тогда обновление маркетплейс-решения обновляет только его собственную часть, а наши правки остаются нетронутыми и продолжают работать поверх новой версии.
Обновление шаблона затрёт все наши правки?
Нет, если доработка вынесена в дочерний шаблон и собственные компоненты. Обновление перезаписывает файлы самого маркетплейс-решения, а не то, что лежит отдельно и подключается поверх. Перед каждым обновлением мы прогоняем проверку на конфликты: если новая версия меняет структуру, которую мы переопределяли, это видно до выката, а не после.
Как откатить доработку, если что-то пошло не так?
Каждый блок правок идёт отдельным коммитом с описанием, что и зачем менялось. Откат — это возврат конкретного коммита, а не восстановление сайта из резервной копии целиком. Если правка затрагивает только один компонент, откатывается только он — остальные доработки продолжают работать.
Совместимы ли правки с будущими обновлениями ядра?
Мы не трогаем ядро и не правим файлы, которые обновляются штатно. Всё, что можно сделать через события и собственные компоненты, делается именно так — это и есть залог совместимости. Там, где без вмешательства в чужой код не обойтись, мы фиксируем это отдельно и предупреждаем, что при обновлении потребуется проверка.
Что будет, если обновление всё же сломает доработку?
Такое возможно, если маркетплейс-решение меняет структуру шаблона, на которую мы опирались. Мы держим доработки изолированными, поэтому поломка локализуется в одном месте и чинится точечно. Порядок действий и точки отката описаны в документации, которую вы получаете вместе с проектом.
Обсудим вашу задачу по доработке шаблона
Чтобы оценка была предметной, а не «на глаз», нам нужен доступ к трём вещам: репозиторию шаблона с историей правок, дампу структуры инфоблоков и описанию того, что именно не устраивает в текущем поведении. С этим набором мы воспроизводим проблему на тестовом стенде, фиксируем точки вмешательства и только потом считаем трудозатраты — иначе любая цифра по доработке шаблона Битрикс окажется гаданием.
Дальше разговор идёт по существу: какие правки затрагивают только шаблон компонента, а какие тянут за собой настройки инфоблоков, правил корзины или логики обмена с 1С. От этого напрямую зависят сроки и объём работ.
- Опишите задачу: что должно измениться на странице, в корзине, в личном кабинете — с примерами «как сейчас» и «как надо».
- Приложите ссылку на стенд или скриншоты проблемных мест — так мы быстрее локализуем причину.
- Укажите, дорабатывался ли шаблон ранее и есть ли обновления ядра, которые нельзя терять.
- Скажите, нужен ли перенос правок в дочерний шаблон, чтобы обновления маркетплейса не затирали доработки.
- Обозначьте желаемые сроки и дату, к которой результат должен быть на боевом сайте.
После разбора мы возвращаемся с оценкой работ, планом доработки по этапам и реалистичными сроками — с учётом того, что часть правок делается в дочернем шаблоне и не ломает будущие обновления. Если по ходу выяснятся скрытые зависимости от 1С или сторонних модулей, скажем об этом сразу, до старта, а не в середине работ.
Опишите задачу в удобной форме — вернёмся с оценкой и планом.
