Edytor witryny odporny na klienta: Podręcznik theme.json

Podsumowanie

Gdy klient po raz pierwszy otwiera edytor witryny WordPress, możliwość edytowania każdego bloku, koloru i układu może wydawać się dla niego funkcją — a dla Ciebie zagrożeniem. W tym artykule wyjaśniamy, jak użyć theme.json, aby wytyczyć wyraźną granicę między edycją treści a kontrolą projektu. Zamiast walczyć z edytorem witryny, skonfigurujesz presety, wartości domyślne i granice, które sprawią, że nietechniczni klienci będą mogli bezpiecznie aktualizować własną witrynę. Omówimy, co zablokować, co pozostawić otwarte i dlaczego nadmierne blokowanie jest realnym ryzykiem. Podejście opiera się na tokenach projektowych i ograniczeniach na poziomie szablonu, dzięki czemu działa spójnie na każdej obsługiwanej przez Ciebie witrynie klienta. Po przeczytaniu będziesz mieć powtarzalny proces przekazywania edytora witryny bez przekazywania kluczy do swojego systemu projektowego.

Co robisz najpierw, gdy klient pisze, że „próbował tylko zaktualizować nagłówek”, a cały odstęp w witrynie się załamał?

Jeśli prowadzisz więcej niż jedną witrynę WordPress, prawdopodobnie otrzymałeś tę wiadomość w jakiejś formie. Edytor witryny dał Twojemu klientowi kluczyki do samochodu z pięcioma biegami i bez hamulca. Myśli, że wprowadza prostą zmianę tekstu, a nagle globalna typografia jest nieprawidłowa, hero strony głównej ma neonowy kolor, którego nie wybrałeś, a dwa bloki są teraz ułożone jeden pod drugim zamiast obok siebie.

Tymczasem myślisz o sześciu innych witrynach klientów, które obsługujesz, a ostatnią rzeczą, jakiej potrzebujesz, jest pułapka konserwacyjna, w której każda „pomocna” edycja klienta wymaga przywrócenia z kopii zapasowej.

Odpowiedzią nie jest odebranie edytora witryny. Chodzi o wyznaczenie w nim granic za pomocą theme.json. Według zasobów dla deweloperów WordPressa, theme.json jest centralnym źródłem prawdy dla ustawień i stylów edytora blokowego — definiuje palety kolorów, typografię i opcje układu, które są widoczne dla klienta. Oznacza to, że ten sam plik, który kontroluje Twój projekt, może również kontrolować, co klient może, a czego nie może edytować.

Przyjrzyjmy się, jak o tym myśleć, ponieważ większość samouczków skupia się na tym, co theme.json może zrobić dla deweloperów. Pytanie dla agencji jest inne: jak wykorzystać go, aby klienci byli bezpieczni, a jednocześnie nie czuli się zamknięci w pudełku?

Dlaczego edytor witryny wydaje się tak niebezpieczny?

Twój klient nie próbuje zepsuć witryny. Stara się zrobić to, czego uczyłeś go przez lata w starym edytorze: zmienić nagłówek, podmienić obraz, może dodać akapit. Zagrożenie nie wynika z jego intencji — chodzi o to, że edytor witryny pokazuje globalne elementy sterujące w tym samym miejscu, co elementy sterujące treścią.

Oto częsty scenariusz. Klient otwiera szablon w edytorze witryny i widzi blok nagłówka. Zmienia jego kolor, aby pasował do nowej próbki marki. Ale ponieważ ten nagłówek znajduje się w szablonie, zmiana dotyczy wszystkich miejsc, w których używany jest ten szablon. Dla klienta wyglądało to na jedną edycję. Dla witryny była to globalna zmiana.

Ogólna zasada: gdy dajesz komuś kreator stron, w końcu znajdzie „ustawienia z zabezpieczeniami” i wyłączy je. Ale dzięki theme.json możesz ukryć same zabezpieczenia. Zamiast mówić klientowi „nie dotykaj stylów globalnych”, po prostu nie pokazujesz mu palety kolorów, która może dać zły efekt. Definiujesz paletę zatwierdzonych kolorów, skalę rozmiarów czcionek i zestaw presetów odstępów — a klient wybiera z nich, a nie z pełnego spektrum CSS.

To pierwsza zmiana: przestań myśleć o zasadach, a zacznij myśleć o fabrykach. theme.json to Twoja linia produkcyjna. Konfigurujesz opcje, które widzi klient, a ograniczenia są egzekwowane przez sam interfejs, a nie przez zestaw instrukcji w dokumencie przekazania.

Co właściwie powinieneś zablokować?

Nie wszystko. Jeśli zablokujesz obszar treści zbyt mocno, klient albo będzie dzwonił do Ciebie za każdym razem, gdy będzie musiał dodać akapit, albo znajdzie sposób na obejście Ciebie — często instalując jednorazową wtyczkę lub kopiując HTML ze starej witryny.

Oto praktyczna tabela tego, co zablokować, co zostawić i dlaczego:

Obszar edycji	Zablokować?	Dlaczego
Struktura szablonu i układy bloków	Zablokuj	Zapobiega przypadkowemu usunięciu lub zmianie kolejności podstawowych bloków układu
Style globalne (kolory, czcionki, presety odstępów)	Zablokuj za pomocą presetów	Klienci wybierają z zatwierdzonego zestawu, a nie dowolnych wartości
Tekst i obrazy treści	Pozostaw otwarte	To ich zadanie; pozwól im to robić bez pytania o pozwolenie
Odstępy między blokami	Częściowo zablokuj	Zapewnij presety odstępów, aby mogli dostosować rytm bez łamania wyrównania
Wyselekcjonowane wzorce bloków	Pozostaw otwarte, jeśli je sprawdziłeś	Bezpieczny sposób na dodawanie nowych sekcji przez klientów bez budowania od zera

Ważnym niuansem jest „zablokuj za pomocą presetów”, a nie „zablokuj całkowicie”. W przypadku stylów globalnych nie ukrywasz panelu ustawień; zmniejszasz liczbę wyborów do wyselekcjonowanego zestawu. Jeśli chodzi o strukturę szablonu, możesz zablokować niektóre bloki, aby nie można było ich usunąć, ale nadal pozwolić klientom na edytowanie tekstu w nich.

Jedno ostrzeżenie: zablokowanie bloku w szablonie różni się od zablokowania go na konkretnej stronie. Blokady szablonów dotyczą całej treści korzystającej z tego szablonu. Jeśli potrzebujesz różnych poziomów blokowania na różnych stronach, musisz pracować na poziomie bloków w edytorze, co jest bardziej zawodne. W powtarzalnej pracy agencyjnej projektuj szablony tak, aby zablokowane obszary były spójne.

Jak wyznaczać granice bez sprawiania, by edytor wydawał się pułapką?

Technika polega na zdefiniowaniu tokenów projektowych w theme.json, a następnie powstrzymaniu się od robienia czegokolwiek innego w CSS.

Na przykład zamiast pozwalać klientowi na ustawienie dowolnego koloru przycisku, definiujesz styl przycisku w theme.json, który używa konkretnego koloru z palety. Klient nadal może zaznaczyć przycisk i zmienić jego tekst, ale próbnik kolorów pokazuje tylko zatwierdzone próbki. To samo dotyczy rozmiarów czcionek, wysokości linii i odstępów.

Ta sama zasada dotyczy szablonów. Możesz użyć funkcji „blokada” na określonych blokach w szablonie — na przykład zablokować strukturę kolumn bloku opinii, aby klient mógł zmienić tekst cytatu, ale nie zmienić trzech kolumn w dwie. Jeśli jeszcze nie używałeś blokowania bloków, jest ono dostępne na pasku narzędzi edytora; gdy blokujesz blok, możesz wybrać, czy klient może edytować treść, przesuwać ją, czy jedno i drugie. Możesz nawet zastosować to w theme.json dla domyślnych ustawień na poziomie bloku.

Twoim celem jest edytor, w którym klient nigdy nie widzi elementu sterującego, który mógłby zepsuć projekt. Nie oznacza to, że nie mogą nic zrobić źle; oznacza to, że najgorsze, co mogą zrobić, to zmienić sformułowanie nagłówka, a nie wygląd całej witryny.

Jeśli używasz niestandardowych typów treści, te same zasady mają zastosowanie poza domyślnymi szablonami — zobacz nasz przewodnik na temat rozszerzania theme.json o niestandardowe typy treści i wyniki wtyczek.

Co się stanie, gdy zablokujesz zbyt wiele?

Oto kontrargument: nadmierne blokowanie jest równie szkodliwe jak zbyt małe blokowanie. Klient, który nie może zmienić rozmiaru nagłówka ani dodać odstępu między sekcjami, w końcu poprosi o „po prostu doprowadź to do porządku” — a potem wracasz do bezpłatnych drobnych poprawek. Co gorsza, może uznać edytor witryny za bezużyteczny i wrócić do kreatora stron innej firmy, co znów daje mu zbyt dużą kontrolę.

Kompromis jest realny. Szczelnie zablokowane edytory generują mniej połączeń alarmowych, ale też więcej próśb typu „czy możesz przesunąć ten przycisk o pięć pikseli w górę”. Otwarte edytory dają odwrotny efekt. Twoim zadaniem jest znalezienie punktu równowagi dla każdego klienta, a nie stosowanie jednej konfiguracji uniwersalnie.

Dobry punkt wyjścia: zablokuj wszystko, co wpływa na wszystkie wystąpienia czegoś (style globalne, strukturę szablonu), a pozostaw otwarte wszystko, co wpływa na jedno wystąpienie (tekst i obrazy pojedynczej strony). Jeśli klient zepsuje pojedynczą stronę, to naprawa w 5 minut. Jeśli zepsuje styl globalny, to naprawa w 20 minut i problem bezpieczeństwa.

Jak sprawić, by to było powtarzalne u różnych klientów?

Tutaj wkracza proces agencyjny. Powinieneś mieć bazowy plik theme.json, który definiuje Twoje tokeny projektowe — paletę kolorów, skalę typografii i presety odstępów — oraz osobny plik nadpisujący dla każdego klienta, który rozszerza lub zmienia określone wartości.

Zacznij od stworzenia „startowego” motywu blokowego. Oto jak zbudować niestandardowy motyw blokowy z theme.json — gdy już go opracujesz i udokumentujesz, skopiowanie go nowemu klientowi to kwestia zamiany kolorów marki i czcionek. Nie odbudowujesz koła na nowo; wymieniasz tokeny. To dokładnie mentalność przestań odbudowywać każdą witrynę WordPress, ale zastosowana do edytora, a nie zaplecza.

Ponieważ theme.json jest pojedynczym plikiem, łatwo go również wersjonować i wdrażać w wielu środowiskach. Możesz przeglądać zmiany, sprawdzać, co klient zmodyfikował w stylach globalnych, i porównywać te zmiany z plikiem bazowym. Daje to solidny ślad audytowy dla próśb o pomoc techniczną.

Jeśli utrzymujesz wiele witryn i nie masz jeszcze skonfigurowanego motywu bazowego, to jest Twoja szansa. To jeden element niestandardowej pracy z WordPressem, który zwraca się za każdym razem, gdy klient otwiera edytor.

A co z klientami, którzy wciąż proszą o „jeszcze jeden kolor”?

Twoja paleta to obietnica. Jeśli zdefiniujesz pięć kolorów marki, a klient poprosi o szósty, odpowiedzią nie jest „nie” — ale „tak, ale pojawi się jako celowy dodatek do palety, a nie jako jednorazowy kod hex w nagłówku”. Gdy dodasz kolor do theme.json, będzie on dostępny w całej witrynie w spójny sposób. To właściwy sposób na obsługę takich próśb.

To także moment, w którym musisz porozmawiać z klientem. Wyjaśnij, że edytor witryny pokazuje im tylko kolory i czcionki zgodne z ich standardami marki. Jeśli chcą rozszerzyć te standardy, zajmiesz się tym w systemie projektowym, a wtedy każdy nowy kolor będzie dostępny wszędzie — także na przyszłych stronach, których jeszcze nie zbudowali. To znacznie lepsza odpowiedź niż „nie robimy tego”.

Jednocześnie nie gromadź palety czterdziestu kolorów. Przeglądaj ją kwartalnie i usuwaj wszystko, co było jednorazowym przypadkiem. Celem jest mały, przemyślany zestaw opcji.

Jeśli zablokujesz układ, ale pozostawisz treść, i uczynisz paletę żywą częścią relacji z klientem, edytor witryny przestaje być zagrożeniem. Staje się sposobem na przekazanie klientom prawdziwej autonomii bez poświęcania standardów projektowych, które masz chronić.