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

Резюме

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

Какво е първото нещо, което правите, когато клиент пише имейл, че „току-що се опита да обнови заглавието“ и целият сайт е загубил разстоянията си?

Ако поддържате повече от един сайт на WordPress, вероятно сте получавали подобно съобщение в някаква форма. Редакторът на сайтове даде на клиента ви ключовете за кола с пет скорости и без спирачки. Те смятат, че правят проста текстова промяна, и изведнъж глобалната типография е развалена, основният банер на началната страница има неонов цвят, който не сте избрали, и два блока са подредени един върху друг вместо един до друг.

Междувременно си мислите за шестте други клиентски сайта, които поддържате, и последното нещо, от което имате нужда, е капан за поддръжка, при който всяка „полезна“ клиентска редакция изисква възстановяване от резервно копие.

Отговорът не е да отнемете редактора на сайтове. Трябва да зададете граници вътре в него с помощта на theme.json. Според WordPress Developer Resources, 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 работа, която се изплаща всеки път, когато клиент отвори редактора.

А какво да кажем за клиентите, които продължават да искат „още един цвят“?

Вашата палитра е обещание. Ако дефинирате пет маркови цвята и клиент поиска шести, отговорът не е „не“ — а „да, но той пристига като преднамерено допълнение към палитрата, а не като еднократен шестнадесетичен код в заглавие.“ Когато добавите цвят в theme.json, той става достъпен навсякъде в сайта последователно. Това е правилният начин да се справите с тези заявки.

Тук също трябва да комуникирате с клиента. Обяснете, че редакторът на сайтове им показва само цветовете и шрифтовете, които отговарят на техните маркови стандарти. Ако искат да разширят тези стандарти, вие ще се погрижите за това в дизайн системата и тогава всеки нов цвят ще бъде наличен навсякъде — включително на бъдещи страници, които все още не са създали. Това е много по-добър отговор от „ние не правим това“.

В същото време не натрупвайте палитра от четиридесет цвята. Преглеждайте я на тримесечие и премахвайте всичко, което е било еднократен инцидент. Целта е малък, целенасочен набор от опции.

Ако заключите оформлението, но оставите съдържанието, и направите палитрата жива част от взаимоотношенията си с клиента, редакторът на сайтове престава да бъде заплаха. Той се превръща в начин да дадете на клиентите си истинска автономия, без да жертвате дизайнерските стандарти, които сте платени да защитавате.