Редактор сайта, защищённый от клиента: руководство по theme.json

Краткое содержание

Когда клиент впервые открывает редактор сайта WordPress, возможность редактировать каждый блок, цвет и макет может казаться ему преимуществом, а вам — угрозой. В этой статье объясняется, как использовать theme.json, чтобы провести чёткую границу между редактированием контента и контролем дизайна. Вместо того чтобы бороться с редактором сайта, вы настраиваете пресеты, значения по умолчанию и ограничения, которые делают обновление сайта безопасным для нетехнических клиентов. Мы рассмотрим, что следует заблокировать, что оставить открытым и почему чрезмерная блокировка — реальный риск. Подход строится на дизайн-токенах и ограничениях на уровне шаблонов, поэтому он стабильно работает на всех клиентских сайтах, которые вы поддерживаете. В итоге у вас будет повторяемый процесс передачи редактора сайта клиенту, не передавая при этом ключи от вашей дизайн-системы.

Что вы делаете в первую очередь, когда клиент пишет, что «просто попробовал обновить заголовок», а все отступы на сайте съехали?

Если вы поддерживаете более одного сайта на WordPress, вы, скорее всего, получали подобное сообщение в той или иной форме. Редактор сайта дал вашему клиенту ключи от автомобиля с пятью передачами и без тормозов. Он думает, что вносит простое изменение текста, и вдруг глобальная типографика сбивается, главный экран получает неоновый цвет, который вы не выбирали, а два блока выстраиваются друг над другом вместо того, чтобы быть рядом.

А вы тем временем думаете о шести других клиентских сайтах, которые поддерживаете, и последнее, что вам нужно, — это ловушка сопровождения, где каждое «полезное» изменение клиента требует восстановления из резервной копии.

Ответ не в том, чтобы отобрать редактор сайта, а в том, чтобы установить границы внутри него с помощью 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, он становится доступен на всём сайте единообразно. Это правильный способ обрабатывать такие запросы.

Здесь также важно общаться с клиентом. Объясните, что редактор сайта показывает только те цвета и шрифты, которые соответствуют их фирменным стандартам. Если они хотят расширить эти стандарты, вы сделаете это в дизайн-системе, и тогда каждый новый цвет будет доступен везде — включая будущие страницы, которые они ещё не создали. Это гораздо лучше, чем ответ «мы так не делаем».

В то же время не накапливайте палитру из сорока цветов. Пересматривайте её ежеквартально и удаляйте всё, что было разовой случайностью. Цель — небольшой, осознанный набор вариантов.

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