Редактор сайту, безпечний для клієнта: посібник із theme.json

Summary

Коли клієнт вперше відкриває редактор сайту WordPress, можливість редагувати кожен блок, колір і макет може здаватися йому перевагою — а для вас загрозою. У цій статті пояснюється, як використовувати theme.json, щоб провести чітку межу між редагуванням контенту та контролем над дизайном. Замість того щоб боротися з редактором сайту, ви налаштовуєте пресети, значення за замовчуванням і межі, які роблять безпечним оновлення власного сайту для нетехнічних клієнтів. Ми розглянемо, що варто заблокувати, що залишити відкритим і чому надмірне блокування є реальним ризиком. Цей підхід побудований навколо дизайн-токенів і обмежень на рівні шаблонів, тому він стабільно працює на кожному клієнтському сайті, який ви обслуговуєте. Наприкінці ви отримаєте повторюваний процес передачі редактора сайту клієнту, не передаючи ключі від вашої дизайн-системи.

Що ви робите в першу чергу, коли клієнт пише, що "просто спробував оновити заголовок", а на всьому сайті з'їхали відступи?

Якщо ви підтримуєте більше ніж один сайт WordPress, ви, ймовірно, отримували таке повідомлення в тій чи іншій формі. Редактор сайту дав вашому клієнту ключі від автомобіля з п'ятьма передачами і без гальм. Вони думають, що роблять просту зміну тексту, і раптом глобальна типографіка ламається, на головній сторінці hero-блок отримує неоновий колір, який ви не обирали, а два блоки тепер стоять один під одним замість того, щоб бути поруч.

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

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

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

Чому редактор сайту здається таким небезпечним?

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

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

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

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

Що насправді варто заблокувати?

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

Ось практична таблиця: що блокувати, що залишити та чому:

Поверхня редагування	Блокувати?	Чому
Структура шаблону та макети блоків	Блокувати	Запобігає випадковому видаленню або зміні порядку основних блоків макета
Глобальні стилі (кольори, шрифти, пресети відступів)	Блокувати з пресетами	Клієнти обирають із затвердженого набору, а не довільні значення
Текст контенту та зображення	Залишити відкритим	Це їхня робота; дозвольте їм робити це без запиту дозволу
Відступи між блоками	Частково блокувати	Надайте пресети відступів, щоб вони могли регулювати ритм, не порушуючи вирівнювання
Підібрані блокові патерни	Залишити відкритим, якщо ви їх перевірили	Безпечний спосіб для клієнтів додавати нові секції без створення з нуля

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

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

Як встановити межі, не перетворюючи редактор на пастку?

Метод полягає в тому, щоб визначити свої дизайн-токени у theme.json, а потім утриматися від будь-яких інших дій у CSS.

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

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

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

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

Що станеться, якщо заблокувати занадто багато?

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

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

Хороша початкова евристика: блокуйте все, що впливає на всі екземпляри чогось (глобальні стилі, структура шаблонів), і залишайте відкритим усе, що впливає на один екземпляр (текст і зображення окремої сторінки). Якщо клієнт зламає окрему сторінку, це виправлення на 5 хвилин. Якщо він зламає глобальний стиль, це виправлення на 20 хвилин і проблема безпеки.

Як зробити це повторюваним для різних клієнтів?

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

Почніть зі створення "стартової" блокової теми. Ось як створити власну блокову тему з theme.json — щойно ви її розробили та задокументували, копіювання її для нового клієнта зводиться до заміни фірмових кольорів і шрифтів. Ви не винаходьте велосипед; ви замінюєте токени. Це саме той підхід припиніть перебудовувати кожен сайт WordPress, але застосований до редактора, а не до бекенду.

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

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

А як щодо клієнтів, які постійно просять "ще один колір"?

Ваша палітра — це обіцянка. Якщо ви визначили п'ять фірмових кольорів, а клієнт просить шостий, відповідь не "ні" — а "так, але він з'явиться як свідоме доповнення до палітри, а не як разовий hex-код у заголовку". Коли ви додаєте колір у theme.json, він стає доступним на всьому сайті послідовно. Це правильний спосіб обробляти такі запити.

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

Водночас не накопичуйте палітру з сорока кольорів. Переглядайте її щокварталу та видаляйте все, що було випадковістю. Мета — невеликий, продуманий набір варіантів.

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