Перестаньте перебудовувати кожен сайт WordPress

Резюме

Більшість агенцій створюють кожен сайт на WordPress з порожньої теми, навіть якщо спільна основа скоротила б тижні з графіка. У цій статті стверджується, що theme.json, блокові шаблони та динамічні блоки дозволяють стандартизувати структурний шар, зберігаючи при цьому унікальний дизайн кожного клієнта. Вона безпосередньо розглядає п'ять заперечень, які заважають командам змінюватися: «у нас різні клієнти», «користувацькі блоки дорогі», «редактор заплутаний», «ми втратимо наші хуки та фільтри» і «FSE ще не готовий до продакшену». Кожне заперечення отримує практичний контраргумент і конкретний патерн, який можна впроваджувати поступово. Винагорода — це повторюваний процес збірки, який все ще поважає індивідуальну роботу там, де вона потрібна. Попередження: жодних кнопок скидання в один клік вам не обіцяють.

Скільки з ваших клієнтських сайтів мають хоча б один спільний рядок коду? Не рядок копірайту — а справжній код. Якщо відповідь «майже жоден», ви вже відчули цей біль: той самий hero-розділ перебудовується вдев'яте, та сама розмітка командної сітки копіюється з проєкту в проєкт, ті самі препроцесорні правки перехресно використовуються в половині дюжини тем. Ви також чули захист: «У кожного клієнта різні потреби». Це правда. Але висновок, який усі роблять, — що кожен сайт потребує індивідуальної основи, — хибний. Екосистема WordPress тепер дає вам спосіб стандартизувати структурні елементи без стандартизації дизайну: theme.json для дизайн-токенів, блокові шаблони для повторюваних макетів і динамічні блоки для тих небагатьох функцій, які потребують справжньої серверної логіки. Ця стаття — про заперечення, які заважають агенціям зробити цей крок, і про те, що насправді працює, коли ви їм протистоїте.

Заперечення «але кожен клієнт різний»

Основний принцип: стандартизуйте фундамент, а не поверхню. Причина зберігати структуру в спільній бібліотеці полягає саме в тому, щоб залишити візуальний шар вільним. Файл theme.json — це не дизайн, а набір дизайн-токенів. Кольори, відступи та типографіка — це значення, а не розмітка. Це ключовий зсув: ви можете ділитися розміткою, а per-site theme.json робить сайт абсолютно різним для різних брендів.

Візьмемо двох клієнтів: юридичну фірму та магазин товарів для активного відпочинку. Їхні дизайн-мови відрізняються на кілометри. Але обом потрібен hero-розділ, сітка відгуків, смуга заклику до дії. Замість того, щоб перебудовувати розмітку для кожного, підтримуйте три блокові шаблони і дозвольте theme.json кожного клієнта визначати кольори, шрифти та відступи. Структура залишається ідентичною; дизайн-токени перетворюють її з одного бренду на інший. Коли продавець змінить свою палітру кольорів наступної весни, ви редагуєте один файл на їхньому сайті, а не розмітку в шести шаблонах.

Практично це означає, що ваша команда створює шаблони як код, реєструє їх у спільному плагіні та дозволяє theme.json на кожному клієнтському сайті займатися «фарбою». Імена класів шаблону стають вашою архітектурою; значення стають змінними. Ви можете піти ще далі й розширити theme.json, включивши спеціальні налаштування для типів записів або виводу плагінів, хоча в якийсь момент ви створюєте інтерфейс конфігурації, а не сайт — це пастка, обговорювана в нашому огляді розширення theme.json. Тримайте спільний шар стислим: він має містити лише те, що повторюється в клієнтів. Щойно ви помічаєте, що додаєте налаштування «про всяк випадок, якщо комусь колись це знадобиться», ви створили абстракцію, яка коштуватиме більше на підтримці, ніж заощадить.

Коли ви налаштовуєте нового клієнта, перші тридцять хвилин мають виглядати так: клонуйте плагін спільних шаблонів, створіть новий theme.json з палітрою та шкалою шрифтів клієнта та зареєструйте його логотип і футер. Це не індивідуальна збірка; це завдання конфігурації. Решта робіт, специфічних для клієнта, йде в контент, структуру та будь-які справді індивідуальні функції. Це різниця між будівництвом кожного будинку з нуля та наявністю набору збірних планів поверхів, які можна перефарбувати та переклеїти шпалери. Аналогія приблизна, але принцип діє: чим більше ви переносите у значення theme.json, тим менше вам доводиться торкатися розмітки.

Один із найпростіших виграшів — це насправді подивитися, як працюють блокові шаблони. Шаблон — це просто набір блоків із наперед визначеним вмістом і стилями. Ви можете зберегти будь-яку конфігурацію блоків як шаблон, і тоді клієнт може вставити його, не знаючи, як він побудований. Це означає, що шаблон стає «точкою входу» для нетехнічних користувачів. Коли ваша команда підтримує базовий шаблон у коді, клієнт отримує узгоджену бібліотеку, не торкаючись жодного тега PHP.

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

Заперечення «користувацькі блоки знищують бюджет»

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

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

Більш підступний сценарій: клієнт просить «карусель кейсів». Перший інстинкт — подумати: «Мені потрібен блок каруселі». Але чи потрібна йому карусель? Можливо, йому потрібна горизонтально прокручувана група матеріалів, з якою основні блоки впораються за допомогою блоку «група» та трохи CSS. Або, можливо, йому потрібен динамічний список останніх кейсів, який є динамічним блоком, що запитує CPT. Питання не в тому, «яку функцію хоче клієнт?», а «від яких даних вона залежить?». Якщо дані статичні та доступні для редагування клієнтом, шаблон підійде. Якщо дані надходять із запиту до бази даних, виправданий динамічний блок. Якщо дані потрібно оновлювати в реальному часі з API, можливо, вам потрібна інтеграція з REST API — це вже інший тип збірки.

Коли ви все ж створюєте блок, block.json — ваш друг. Це єдине джерело істини для атрибутів, скриптів і стилів, що робить блок переносимим між проєктами. Він також дозволяє чітко оголошувати залежності та переклади, що необхідно при розповсюдженні бібліотеки на багатьох клієнтських сайтах. Для контенту, який залежить від живих даних, динамічний блок рендериться на сервері, тому вам не потрібно надсилати JavaScript-бандл на кожному перегляді сторінки. І якщо ваш блок розвивається, ви можете оновлювати його без поломки існуючого контенту — наш посібник із застарівання блоків описує точний патерн.

Перш ніж щось створювати, проганяйте рішення через цю таблицю:

Підхід	Найкраще для	Уникайте, коли
Основний блок	Разовий контент, прості сторінки	Макет повторюється у багатьох клієнтів і потребує багатих опцій
Блоковий шаблон	Повторювані макети без логіки	Макет потребує умов, динамічних даних або складних взаємодій
Користувацький блок	Повторювана, керована даними або вузькоспеціальна поведінка	Єдина причина — разова секція, яку можна обробити класом

Також варто подумати про іменування блоків з першого дня. Ім'я блоку — це по суті контракт із вашим контентом. Якщо ви назвете його wagent/team-grid, а потім перейменуєте на wagent/team-carousel, ви зламаєте існуючий контент, якщо не надасте шлях міграції. Вибирайте загальні, змістовні імена, які не стануть неправдивою рекламою, коли блок розвиватиметься. Це варіант дисципліни іменування, якої всі ми навчилися з префіксів плагінів, і вона так само застосовна до імен блоків.

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

Заперечення «клієнти зламають редактор»

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

Дозвольте описати сценарій. Клієнт телефонує і каже: «Я перемістив секцію, і тепер уся сторінка виглядає неправильно». З класичною темою ви б увійшли, перевірили CSS і, ймовірно, витратили годину на виправлення макета. З блоковою конфігурацією ви можете відкрити сторінку, вибрати область контенту та скинути її до збереженого шаблону. Шаблон є базовою лінією; зміни клієнта — це оверлей. Коли оверлей іде не так, ви його видаляєте. Це не просто зручніший робочий процес; це принципово більш поблажливий редактор.

Тепер нюанс: більшість клієнтів взагалі не хочуть багато редагувати. Вони хочуть змінювати текст, замінювати фото та, можливо, переставляти секцію. Блоковий шаблон дає вам саме це, не відкриваючи всю структуру сайту. У цьому сенсі редактор — не іграшка, а видошукач. Ваше завдання — відкалібрувати, що клієнти можуть бачити. Це означає, що ви можете вимкнути налаштування «Шаблони», обмежити вставку блоків відібраним списком і навіть попередньо заповнити порожні шаблони заглушками. Редактор стає формою введення контенту, а не полотном веб-дизайну.

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

Справді складна частина — внутрішня. Для вашої команди навчання прототипуванню з блоками вимагає відучитися від звички «робити в PHP». Це реальна ціна, але це разова ціна на людину. Це не причина уникати підходу; це причина почати з однієї бібліотеки шаблонів і одного поблажливого клієнта, перш ніж розгортати всюди. Не дозволяйте рефрену «мої клієнти не впораються з блоками» приховувати той факт, що ви ще не налаштували блокову конфігурацію, щоб зустріти їх на півдорозі.

Заперечення «у нас уже є хуки та фільтри»

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

Уявіть плагін, який дозволяє додати поле «рекомендований продукт» до будь-якого запису за допомогою фільтра. За допомогою динамічного блоку ви можете включити блок, що рендериться на сервері, який запускає цей фільтр і виводить результат усередині обгортки блоку. Клієнт вставляє блок; наявна PHP-логіка робить важку роботу. Нічого не викидається. Для ще конкретнішого прикладу розглянемо користувацький блок, який виводить список останніх проєктів. У його зворотному виклику рендерингу ви викликаєте get_posts(), потім циклічно застосовуєте the_title() і the_permalink() — ті самі теги шаблону, які ви використовували роками.

Це також місце, де слід чесно визнати, що не переноситься. Деякі розумні старі теми використовують template-parts зі складними умовами, які приймають аргументи залежно від контексту сторінки. Відтворити це як блок може бути безладно. Але вам не потрібно відтворювати все одразу. Інкрементальний шлях — зберегти PHP-логіку, загорнути її в динамічний блок і перенести розмітку в шаблон блоку. Ви часто виявите, що ваші наявні патерни фільтрів можуть обробити новий вивід. А якщо логіка тісно пов'язана з ієрархією шаблонів (наприклад, «у результатах пошуку показувати це інакше»), ви все одно можете використовувати класичний шаблон для цих конкретних переглядів, використовуючи блоки для звичайних сторінок.

REST API також відкриває інші двері: ви можете створювати блоки, які отримують дані з інших сайтів WordPress або сторонніх сервісів. Динамічний блок може викликати wp_remote_get() для отримання JSON і рендерити його на фронтенді. Це потужний патерн для агенцій, де клієнти хочуть показувати соціальні стрічки, списки продуктів або внутрішні дані без керування окремою інтеграцією. Компроміс — кешування та обробка помилок: якщо віддалений API повільний, ваша сторінка повільна. Тримайте блоки на основі API подалі від критичного контенту над згином або використовуйте клієнтський рендеринг із належним станом завантаження.

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

Заперечення «FSE не готове до продакшену»

Справедливо, але запитайте, що насправді означає «ризиковано». Повне редагування сайту (Full Site Editing) пройшло через кілька релізів, і theme.json став стабільною схемою. Ризик не в тому, що редактор «раптово зламається» — ризик у тому, що ваш власний код команди може покладатися на старі PHP-шаблони, які незграбно співіснують із блоковими шаблонами. Крім того, деякі сторонні плагіни досі розраховані на класичний редактор або кастомізер. Це рішення про сумісність, а не причина викидати всю модель.

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

Перш ніж пропонувати клієнту блокову тему, пройдіться швидким чеклістом:

• Чи є у клієнта сильно кастомізована тема, яка потребуватиме міграції?
• Чи підтримують необхідні плагіни редактор сайту та REST API?
• Чи дозволяє хостинг доступ до файлів, який очікує блокова тема?
• Чи виділили ви час на дизайн шаблонів, а не лише на реєстрацію блоків?
• Чи готова команда клієнта до змін у редакторі, чи їм потрібен зафіксований шаблон?

Якщо хоч одна відповідь «ні», скоригуйте обсяг або використовуйте гібридний підхід. Це не компроміс; це інженерне судження. А якщо ви будуєте гібрид, згадайте історію про хуки та фільтри вище — ви все ще можете загортати стару логіку в динамічні блоки, поки theme.json керує загальним виглядом.

Версіювання вашого theme.json — це не лише теоретичне занепокоєння. Я бачив, як власна бібліотека блоків агенції ламалася, коли клієнт оновлював WordPress, а файл style блоку, зареєстрований через wp_register_style(), отримував змінений дескриптор. Виправлення було простим, але паніка реальною. Простий процес тестування — запустіть оновлення на staging-копії сайту, пройдіться по ключових сторінках, потім випускайте — вирішує більшість таких сюрпризів.

Заперечення, яке ви собі не висловлювали

Ось мета-заперечення, яке заважає агенціям стандартизувати: «Це велика зміна, і немає часу на неї під час роботи з клієнтами». Це правда — тому не робіть цього під час роботи з клієнтами. Виберіть внутрішній проєкт або невеликого клієнта та створіть одну бібліотеку шаблонів. Використовуйте theme.json як систему дизайн-токенів. Додавайте користувацький блок лише тоді, коли це виправдано. Загортайте старі хуки там, де вони допомагають. Ітеруйте.

Ось приблизні перші 30 днів:

1. Проведіть аудит останніх п'яти клієнтських збірок і складіть список десяти найповторюваніших елементів макета.
2. Перетворіть ці десять елементів на блокові шаблони з невеликим набором CSS-класів.
3. Створіть спільний плагін (або mu-плагін), який реєструє ці шаблони. Якщо ви ще не думали про організацію плагінів, спершу прогляньте цей посібник зі створення надійних плагінів.
4. Створіть один theme.json, який відповідає вашому базовому дизайну; додавайте значення для клієнта в міру запуску проєктів.
5. Виберіть один невеликий внутрішній проєкт або дружнього клієнта та мігруйте його на цей стек.
6. Задокументуйте одну історію успіху клієнта, який відредагував свою головну сторінку, не телефонуючи вам.

Наприкінці цього експерименту у вас не буде бейджа «блоки перш за все», який можна повісити на стіну. У вас буде команда, яка може швидко створити новий клієнтський сайт на спільній основі без вибачень за терміни. Ви також будете в кращій позиції, щоб відмовити клієнту в 42-му користувацькому блоці — тому що ви точно знаєте, на що здатні основні блоки, або тому що можете показати, чому динамічний блок справді буде швидшим.

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

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