Доробка шаблону Бітрікс: де ламається верстка
Готовий шаблон з маркетплейсу майже ніколи не стає на проєкт «як є»: він зібраний під усереднений магазин, а на реальному сайті стикається з уже встановленими модулями, своєю структурою каталогу та накопиченими правками.
Доробка шаблону Бітрікс починається не з косметики, а з діагностики — де саме розходиться очікувана поведінка компонентів і фактична верстка.
Перше джерело проблем — конфлікт компонентів. Шаблон приносить свої версії 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С або сторонніх модулів, скажемо про це відразу, до старту, а не в середині робіт.
Опишіть завдання у зручній формі — повернемося з оцінкою та планом.
