Розробка кастомної теми Grav (Twig) під ключ

Чому типова тема гальмує проєкт на Grav

Типова тема Grav майже завжди збирається «на все одразу»: десятки шаблонів Twig, успадкування через кілька рівнів, плагіни, які тягнуть свої таблиці стилів і скрипти на кожній сторінці. Поки контенту мало, це непомітно.

Щойно каталог зростає до сотень сторінок, а на сторінку додаються десятки блоків, починають проявлятися вузькі місця CMS: ланцюжок успадкування шаблонів подовжується, і кожен рендер проходить через усі проміжні шари, навіть якщо підсумковий блок не виводиться.

Окрема проблема — неконтрольовані звернення до файлової системи. Готова тема читає конфігурацію, метадані сторінок і медіа через кілька шарів абстракції, і на кожному запиті це повторюється заново.

При кешуванні «з коробки» такі виклики частково гасяться, але варто увімкнути динамічні блоки або персоналізацію — і продуктивність Grav просідає саме на повторюваних операціях, а не на самому рендері.

Третє — залежності. Тема тягне бібліотеку заради однієї функції, плагін підключає свою версію тієї ж бібліотеки, і в підсумковій збірці опиняються дублі. Це не лише зайва вага сторінки, а й конфлікти при оновленні: незрозуміло, що можна чіпати, а що зламає верстку. Замовник у підсумку платить за кожну правку довше, бо розробник спочатку розплутує чужу структуру.

Кастомна тема Grav знімає це на рівні архітектури: шаблони Twig проєктуються під конкретні типи сторінок без зайвих рівнів успадкування, звернення до файлів кешуються усвідомлено, а залежності фіксуються і мінімізуються.

Розбираємо, як це закривається в розробці теми Grav під ключ — від структури шаблонів до політики оновлень.

Що дає кастомна тема: вимірюваний ефект

Кастомна тема на Twig збирається під конкретну структуру контенту, а не підганяється під неї. Це дає чотири вимірювані напрями виграшу: швидкість віддачі сторінок, передбачуваність оновлень, зниження навантаження на підтримку та керованість контенту для редактора. Нижче — як кожен із них влаштований і чому саме так.

Швидкість віддачі та час збирання сторінки

Тема компілюється в шаблони Twig, які Grav кешує: повторний рендер сторінки відбувається без повторного розбору розмітки. Важкі блоки — каталог, фільтри, форми — виносяться в окремі шаблони й підвантажуються на вимогу, а не збираються повністю на кожен запит.

На практиці час збирання сторінки падає із секунд до десятих часток, а стабільний час відгуку напряму впливає на поведінку відвідувачів і позиції в пошуку.

Передбачуваність оновлень і клас відмов

Ядро Grav і сторонні доповнення оновлюються незалежно від вашої теми — оновлення не ламає верстку та логіку виведення. Власний шаблонний шар прибирає цілий клас відмов, який виникає, коли правка чужого розширення тягне за собою несумісність з рештою сайту. Відкат до попередньої версії теми повертає робочий стан за хвилини, без відновлення всієї бази.

Зниження звернень до підтримки та керування контентом

Редактор працює зі зрозумілими полями й блоками замість правки розмітки: типові сторінки збираються з готових секцій, а некоректне введення відсікається на рівні шаблону.

Кількість звернень «поправте текст і картинку» падає в рази, а вартість підтримки стає передбачуваною — правки контенту не потребують розробника. Ми працюємо на Grav та актуальній гілці Twig, тому тема залишається сумісною з оновленнями ядра.

Підходи до розробки теми: порівняння варіантів

Вибір між готовою темою, доопрацюванням наявної та розробкою з нуля — це не питання смаку, а питання того, які обмеження ви готові прийняти. Нижче — чесне порівняння за трьома сценаріями, з якими найчастіше приходять замовники.

Готова тема виграє за термінами впровадження, але програє там, де структура контенту не збігається із задумом автора. Доопрацювання — розумний компроміс, поки правки локальні: щойно змінюється логіка виведення на більшості сторінок, підтримка стає дорожчою, ніж чиста розробка.

Тема з нуля окупається, коли контент-модель нестандартна: власні типи сторінок, колекції, блоки для повторного використання. Тут розмітка й шаблони проєктуються під задачу, а не підганяються під чужу сітку — це і дає передбачувану підтримку надалі.

Ми розбираємо структуру контенту та вимоги до сторінок, після чого говоримо прямо: де достатньо готового рішення, де потрібне доопрацювання, а де чесніше зібрати тему з нуля.

Як ми ведемо розробку теми Grav: етапи

Розробку теми Grav ведемо як інженерний проєкт із фіксованими етапами: кожен крок закінчується артефактом, який можна перевірити до переходу до наступного.

Так вимоги не «розпливаються» по ходу, а успадкування шаблонів і структура контенту проєктуються до першого рядка розмітки — переробки на середині коштують дорожче, ніж аудит на початку.

Сім етапів роботи

1. Аудит вимог. Розбираємо типи сторінок, блоки, модулі та сценарії редактора: що наповнюється вручну, що збирається з колекцій, де потрібні фрагменти для повторного використання. На виході — карта контенту та список шаблонів із пріоритетами.
2. Схема шаблонів і успадкування. Проєктуємо дерево Twig-шаблонів: базовий каркас, партіали, перевизначення за типами сторінок. Фіксуємо, який блок успадковується, а який перевизначається — це прибирає дублювання розмітки.
3. Налаштування середовища. Піднімаємо локальний стенд, репозиторій і збірку стилів та скриптів, налаштовуємо чернетковий і робочий контури. Правки йдуть через гілки, а не напряму на живому сайті.
4. Складання компонентів. Збираємо секції, форми, навігацію та медіа-блоки на реальній структурі контенту, а не на заглушках. Кожен компонент перевіряємо на адаптивність і на поведінку при порожніх даних.
5. Перевірка верстки. Прогоняємо сторінки на різних роздільних здатностях і браузерах, звіряємо з макетом, перевіряємо доступність і швидкість завантаження. Помилки закриваємо до передачі, а не після запуску.
6. Навчання редакторів. Показуємо, як додавати сторінки, збирати блоки та змінювати контент без розробника. Віддаємо коротку інструкцію щодо типових дій.
7. Передача проєкту. Передаємо репозиторій, конфігурацію, документацію щодо шаблонів і доступи, розгортаємо на робочому контурі та фіксуємо регламент оновлень.

Після передачі тема залишається підтримуваною: структура шаблонів і правила успадкування описані, тому нові блоки додаються передбачувано. Опишіть завдання — повернемося з оцінкою та планом за етапами.

Структура теми, шаблони Twig і успадкування

Тема в Grav — це не набір окремих сторінок, а ієрархія шаблонів Twig із чітким порядком успадкування. Базовий base.html.twig описує каркас: підключення стилів, мета-теги, спільні блоки.

Дочірні шаблони успадковують його через {% extends %} і перевизначають лише потрібні блоки — {% block content %}, {% block header %}. Так правка в одному місці поширюється на всі сторінки, а не вимагає ручного обходу десятків файлів.

Повторювані елементи — меню, футер, картка товару, форма підписки — виносяться в партіали й підключаються через {% include %} з передаванням параметрів.

Той самий блок використовується на головній, у каталозі та в статті, тому розбіжність у верстці між розділами виключена технічно, а не на дисципліні розробника.

Окремий шар — blueprint-конфігурація. Для кожного типу сторінки описується набір полів: заголовок, зображення, текстові блоки, галерея, повторювані секції. Редактор заповнює їх через адмінку, і шаблон збирає сторінку з цих даних.

Додати новий блок або змінити порядок секцій можна без правки коду — розробник підключається лише тоді, коли змінюється сама логіка виведення.

Така структура теми дає передбачувану підтримку: новий розділ збирається з готових партіалів за години, а не переписується з нуля. Шаблони залишаються читабельними, бо кожен відповідає за свою зону відповідальності, а не змішує розмітку, дані та логіку в одному файлі.

Що замовник отримує на руки після здачі

Здача — це не архів із файлами, а комплект, за яким ваша команда зможе працювати без нас. Тема Grav живе у вигляді вихідних кодів і конфігурації, тому передаємо і те, і інше: без розуміння, який шаблон за що відповідає, будь-яка правка перетворюється на археологію по коду.

• Вихідні коди теми — повний репозиторій з історією змін: шаблони на Twig, стилі, скрипти, схема наслідування. Розгортається однією командою на чистому середовищі.
• Схема шаблонів — карта відповідності: який Twig-файл рендерить яку сторінку, від якого батька наслідується, де підключаються блоки та партіали. За нею новий розробник орієнтується за годину, а не за тиждень.
• Конфігураційні файли — blueprints і налаштування теми: які поля доступні редактору, які значення за замовчуванням, де зберігаються тексти та медіа. Правки контенту не потребують правок коду.
• Інструкція для редактора — як додати сторінку, змінити блок, завантажити зображення, що робити при помилці. Написана під людину без технічного бекграунду, зі скриншотами реальних екранів.
• Регламент оновлень — порядок оновлення ядра Grav, плагінів і залежностей: що перевіряється до, як робиться відкат, які гілки вважаються стабільними. Оновлення перестає бути ризиком.
• Журнал перевірок — протокол приймання: які сценарії протестовано, на яких браузерах і роздільних здатностях, які зауваження закрито. Видно, що саме перевірялося, а не «начебто працює».

Плюс доступи до репозиторію та середовища, зафіксовані версії залежностей і контакти для питань на період супроводу. Усе це описано в одному місці — не потрібно збирати знання по листуванню. Опишіть задачу — повернемося з оцінкою та планом передачі.

Кейс: перенесення каталогу на кастомну тему Grav

Каталог на Grav у замовника — виробника обладнання — жив на темі, зібраній із готового шаблону з десятком розширень. Кожна правка верстки тягла за собою ланцюжок залежностей, а редактор не міг опублікувати новий розділ без розробника.

Ми перенесли каталог на кастомну тему під ключ: власні шаблони Twig, єдиний набір блоків і винесені в конфігурацію поля карток товарів.

Що змінили

Зібрали тему з нуля під структуру каталогу: окремі шаблони для категорій, карток і лендингів, спільний шар компонентів замість копій розмітки.

Редактор отримав готові блоки — галерею, таблицю характеристик, блок документів — і збирає сторінку з них через панель керування, без правки коду. Важкі зображення перевели на відкладене завантаження, статику віддаємо через кеш, а не через обробник.

Метрики до і після

Окремо зняли навантаження з команди: типові задачі — новий розділ, банер, зміна структури каталогу — редактор закриває сам. Розробники повертаються до продуктових задач, а не до правок розмітки.

Якщо у вас каталог упирається у швидкість віддачі або редактор залежить від розробника — опишіть задачу, повернемося з оцінкою та планом перенесення.

Чим відрізняється кастомна тема від доопрацювання готової?

Різниця не в обсязі робіт, а в тому, де проходить межа застосовності. Готова тема — це вже прийнята кимось архітектура: своя ієрархія шаблонів Twig, свої partial-блоки, свої домовленості щодо наслідування.

Доопрацювання дешевше й швидше, поки завдання вкладається в цю архітектуру: змінити розмітку блоку, додати секцію на головну, перевизначити один шаблон через механізм наслідування. Поки правки локальні, ви платите за години й отримуєте результат за дні.

Доопрацювання перетворюється на постійні латки, коли вимоги починають сперечатися із закладеною структурою. Типова ознака: щоб додати одну сторінку, доводиться чіпати п'ять шаблонів, а кожне оновлення теми затирає ваші правки й їх потрібно переносити заново.

Друга ознака — контент-модель. Якщо типи сторінок, таксономії та поля описуються в темі, а не конфігурацією, редактор не може зібрати нову сторінку без розробника.

Кастомна тема — це коли структуру шаблонів проєктуємо під вашу контент-модель, а не підлаштовуємо контент під чужу. Наслідування вибудовується так, щоб новий тип сторінки додавався одним шаблоном і набором partial-блоків, а логіка вибірки жила в конфігурації, а не в розмітці. Тоді правка контенту не потребує релізу, а оновлення ядра не ламає верстку.

Межа застосовності рахується за вартістю володіння, а не за ціною першої версії. Доопрацювання виграє на короткому горизонті та вузькому наборі правок.

Щойно правки стають регулярними, а оновлення теми — ризиком, сумарні витрати на підтримку обганяють розробку з нуля, і настає момент переписування.

Переписування — це не переробка верстки, а перенесення контент-моделі та маршрутів на нову структуру шаблонів; чим раніше воно зроблено, тим дешевше обходиться.

Часті технічні сумніви замовників

Перед стартом майже кожна команда ставить один і той самий набір питань — і це правильні питання, бо відповіді на них визначають, на що перетвориться сайт через рік експлуатації. Нижче — те, як ми закриваємо кожне з них на рівні архітектури, а не обіцянок.

Як бути із сумісністю плагінів?

Ми не тягнемо десяток сторонніх розширень: типові задачі — форми, меню, пошук, виведення медіа — закриваємо своїм кодом у темі. Якщо плагін усе ж потрібен, перевіряємо його на конфлікти з шаблонами та правами доступу, а його налаштування виносимо в конфігурацію проєкту. Так оновлення одного розширення не валить решту сайту.

Як переноситься контент зі старого сайту?

Контент мігруємо скриптом: розбираємо структуру сторінок, переносимо тексти, медіа та метадані в нові шаблони, зберігаючи адреси або налаштовуючи коректні перенаправлення. Після перенесення звіряємо дерево сторінок і карту посилань, щоб не втратити позиції в пошуку. Редактори отримують уже наповнений сайт, а не порожній каркас.

Що входить у підтримку після здачі?

Передаємо репозиторій, конфігурацію оточень та інструкції з розгортання, фіксуємо регламент оновлень і резервного копіювання. Далі ведемо супровід: правки шаблонів, доопрацювання блоків, розбір інцидентів. Відкат на попередню версію можливий у будь-який момент — історія змін зберігається повністю.

Чи зможе редактор працювати із сайтом без розробника?

Так, і це закладається в структуру заздалегідь: контент редагується через зрозумілі поля та модульні блоки, які збираються в сторінку без верстки. Проводимо навчання редакторів на їхньому ж контенті та залишаємо коротку інструкцію за типовими сценаріями. Розробник підключається лише до нових типів блоків.

Опишіть вашу задачу — повернемося з оцінкою та планом робіт за темою.

Обговоримо ваше завдання щодо розробки теми

Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен мінімум вступних даних. Перша розмова триває 20-30 хвилин і йде по суті: що за проєкт, які сторінки та типи контенту, хто буде вести наповнення після запуску.

За підсумками ми говоримо, чи вкладається завдання в кастомну тему на Twig, чи частина закривається штатними засобами — це чесніше, ніж тягнути все в розробку.

Що надіслати для оцінки

• Посилання на поточний сайт або прототип — навіть чорновий, якщо він є.
• Перелік шаблонів сторінок: головна, каталог, картка, блог, форми, особистий кабінет.
• Схему контенту: які типи записів і поля потрібні редактору, що він має змінювати сам.
• Референси: 2-3 сайти, де подобається структура або поведінка блоків, із позначкою що саме.
• Вимоги до інтеграцій: CRM, оплата, розсилки, зовнішні сервіси — списком, без деталей реалізації.
• Обмеження: терміни, прив'язка до наявного хостингу, вимоги безпеки або доступності.

Як проходить перша розмова

Ми розбираємо завдання за шаблонами та типами контенту, а не за «зробіть красиво». На цьому етапі випливають вузькі місця: нестандартні поля, складна логіка виведення, міграція наявного контенту.

Якщо частина вимог конфліктує між собою, скажемо прямо і запропонуємо варіант, який вирішує початкове завдання простіше.

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

Опишіть завдання у зручній формі — повернемося з оцінкою та планом робіт.