İstemciye Dayanıklı Site Editörü: theme.json Rehberi

Özet

Bir müşteri WordPress Site Editörü'nü ilk kez açtığında, her bloğu, rengi ve düzeni düzenleyebilme yeteneği onlar için bir özellik gibi görünebilir — ve sizin için bir tehdit gibi. Bu makale, içerik düzenleme ile tasarım kontrolü arasına net bir çizgi çekmek için theme.json'u nasıl kullanacağınızı açıklar. Site Editörü ile savaşmak yerine, teknik bilgisi olmayan müşterilerin kendi sitelerini güncellemelerini güvenli hale getiren ön ayarlar, varsayılanlar ve sınırlar belirlersiniz. Neyi kilitleyeceğinizi, neyi açık bırakacağınızı ve aşırı kilitlemenin neden gerçek bir risk olduğunu ele alacağız. Yaklaşım, tasarım token'ları ve şablon düzeyinde kısıtlamalar etrafında inşa edilmiştir; böylece yönettiğiniz her müşteri sitesinde tutarlı çalışır. Sonunda, Site Editörü'nü tasarım sisteminizin anahtarlarını teslim etmeden devretmek için tekrarlanabilir bir iş akışına sahip olacaksınız.

Bir müşteri "sadece başlığı güncellemeyi denedim" deyip tüm sitenin boşlukları çöktüğünde yaptığınız ilk şey nedir?

Birden fazla WordPress sitesi yönetiyorsanız, bu mesajı bir şekilde almışsınızdır. Site Editörü, müşterinize beş vitesli ve freni olmayan bir arabanın anahtarlarını verdi. Basit bir metin değişikliği yaptıklarını sanıyorlar ve aniden küresel tipografi bozuldu, ana sayfa kahramanı sizin seçmediğiniz neon bir renge büründü ve iki blok yan yana yerine üst üste dizildi.

Bu sırada siz desteklediğiniz diğer altı müşteri sitesini düşünüyorsunuz ve ihtiyacınız olan son şey, her "yardımsever" müşteri düzenlemesinin yedekten geri yükleme gerektirdiği bir bakım tuzağıdır.

Cevap, Site Editörü'nü elinden almak değil. theme.json kullanarak içine sınırlar koymak. WordPress Geliştirici Kaynakları'na göre theme.json, blok editörü ayarları ve stilleri için merkezi bilgi kaynağıdır — müşteriye görünen renk paletlerini, tipografiyi ve düzen seçeneklerini tanımlar. Bu, tasarımınızı kontrol eden aynı dosyanın, müşterinizin neleri düzenleyip düzenleyemeyeceğini de kontrol edebileceği anlamına gelir.

Bunu nasıl düşüneceğimizi adım adım inceleyelim, çünkü çoğu eğitim theme.json'un geliştiriciler için neler yapabileceğine odaklanır. Bir ajans için soru farklıdır: müşterileri kısıtlanmış hissettirmeden nasıl güvende tutarız?

Site Editörü neden bu kadar tehlikeli görünüyor?

Müşteriniz siteyi kırmaya çalışmıyor. Yıllardır eski editörde onlara öğrettiğiniz şeyi yapmaya çalışıyorlar: bir başlığı değiştirmek, bir görseli değiştirmek, belki bir paragraf eklemek. Tehlike onların niyeti değil — Site Editörü'nün global kontrolleri içerik kontrolleriyle aynı yerde göstermesidir.

Yaygın bir senaryo şudur: Bir müşteri Site Editörü'nde bir şablon açar ve bir başlık bloğu görür. Yeni marka rengine uyması için rengini değiştirir. Ancak bu başlık bir şablonda olduğu için değişiklik, bu şablonun kullanıldığı her yerde geçerli olur. Müşteriye tek bir düzenleme gibi göründü. Site için bu global bir değişiklikti.

Genel ilke: Birine bir sayfa oluşturucu verdiğinizde, eninde sonunda "korumalı ayarları" bulup kapatacaktır. Ancak theme.json ile korumaların kendisini gizleyebilirsiniz. Müşteriye "global stillere dokunma" demek yerine, ona kötü sonuç üretebilecek bir renk paleti göstermezsiniz. Onaylı renklerden oluşan bir palet, bir font boyutu ölçeği ve bir dizi boşluk ön ayarı tanımlarsınız — ve müşteri CSS'in tüm yelpazesinden değil, bunlardan seçim yapar.

Bu ilk değişim: kurallar hakkında düşünmeyi bırakın ve fabrikalar hakkında düşünmeye başlayın. theme.json sizin üretim hattınız. Müşterinin gördüğü seçenekleri siz yapılandırırsınız ve kısıtlamalar, teslim belgesindeki bir dizi talimatla değil, arayüzün kendisi tarafından uygulanır.

Gerçekte neyi kilitlemelisiniz?

Her şeyi değil. İçerik alanını çok sıkı kilitlerseniz, müşteri her paragraf eklemesi gerektiğinde sizi arar ya da sizi atlatmanın bir yolunu bulur — genellikle tek seferlik bir eklenti ekleyerek veya eski sitelerinden HTML kopyalayarak.

İşte neyin kilitleneceği, neyin açık bırakılacağı ve nedenine dair pratik bir tablo:

Düzenleme yüzeyi	Kilitlensin mi?	Neden
Şablon yapısı ve blok düzenleri	Kilit	Çekirdek düzen bloklarının yanlışlıkla kaldırılmasını veya yeniden sıralanmasını önler
Global stiller (renkler, fontlar, boşluk ön ayarları)	Ön ayarlarla kilitle	Müşteriler keyfi değerler değil, onaylı bir setten seçer
İçerik metni ve görseller	Açık bırak	Bu onların işi; izin istemeden yapsınlar
Bloklar arası boşluk	Kısmen kilitle	Hizalamayı bozmadan ritmi ayarlayabilmeleri için boşluk ön ayarları sağlayın
Kürasyonlu blok desenleri	İncelediyseniz açık bırakın	Müşterilerin sıfırdan oluşturmadan yeni bölümler eklemesi için güvenli bir yol

Önemli nüans "ön ayarlarla kilitle", "dışarıda kilitle" değil. Global stiller için ayarlar panelini gizlemiyorsunuz; seçenekleri küratediğiniz bir sete indiriyorsunuz. Şablon yapısı için belirli blokları kaldırılamayacak şekilde kilitleyebilir, ancak müşterilerin içlerindeki metni düzenlemesine yine de izin verebilirsiniz.

Bir uyarı: Bir şablondaki bloğu kilitlemek, belirli bir sayfadaki kilitlemekten farklıdır. Şablon kilitleri, şablonu kullanan tüm içeriği etkiler. Farklı sayfalarda farklı kilit seviyelerine ihtiyacınız varsa, editör içinde blok düzeyinde çalışmanız gerekecektir; bu daha kırılgandır. Tekrarlanabilir ajans çalışması için şablonlarınızı kilitli alanlar tutarlı olacak şekilde tasarlayın.

Editörü tuzak gibi hissettirmeden sınırları nasıl belirlersiniz?

Teknik, theme.json'da tasarım token'larınızı tanımlamak ve ardından CSS'te başka hiçbir şey yapmaktan kaçınmaktır.

Örneğin, müşterinin bir düğmeye keyfi bir renk vermesine izin vermek yerine, paletinizden belirli bir rengi kullanan theme.json'da bir düğme stili tanımlarsınız. Müşteri yine de düğmeyi seçip metnini değiştirebilir, ancak renk seçici yalnızca onaylı örnekleri gösterir. Font boyutları, satır yükseklikleri ve boşluk için de aynıdır.

Aynı ilke şablonlar için de geçerlidir. Belirli bloklarda "kilit" özelliğini kullanabilirsiniz — örneğin, bir referans bloğunun sütun yapısını kilitleyerek müşterinin alıntı metnini değiştirebilmesini ancak üç sütunu ikiye çevirememesini sağlayabilirsiniz. Blok kilitlemeyi henüz kullanmadıysanız, editör araç çubuğunda mevcuttur; bir bloğu kilitlediğinizde, müşterinin içeriği düzenleyip düzenleyemeyeceğini, taşıyıp taşıyamayacağını veya her ikisini birden yapıp yapamayacağını seçebilirsiniz. Bunu theme.json'da blok düzeyinde varsayılanlar için bile uygulayabilirsiniz.

Hedeflediğiniz şey, müşterinin tasarımı bozabilecek bir kontrolü asla görmediği bir editördür. Bu, yanlış bir şey yapamayacakları anlamına gelmez; en kötü yanlış şeyin, tüm sitenin görünümünü değil, bir başlığın ifadesini değiştirmek olduğu anlamına gelir.

Özel içerik türleri kullanıyorsanız, aynı ilkeler varsayılan şablonların ötesinde de geçerlidir — theme.json'u özel içerik türlerine ve eklenti çıktısına genişletme rehberimize bakın.

Çok fazla kilitlediğinizde ne olur?

İşte karşıt görüş: aşırı kilitleme, eksik kilitleme kadar zararlıdır. Bir başlığı yeniden boyutlandıramayan veya bölümler arasına boşluk ekleyemeyen bir müşteri, sonunda sizden "şunu düzgün göstermeni" isteyecektir — ve sonra ücretsiz küçük düzenlemeler yapmaya geri dönersiniz. Daha da kötüsü, Site Editörü'nün işe yaramaz olduğuna karar verip, onlara tekrar çok fazla kontrol veren üçüncü taraf bir sayfa oluşturucuya geri dönebilirler.

Buradaki denge gerçektir. Kilitli editörler daha az acil çağrı üretir, ancak daha fazla "şu düğmeyi beş piksel yukarı taşır mısın" talebi üretir. Açık kilitli editörler tam tersini üretir. Sizin işiniz, her müşteri için denge noktasını bulmaktır, evrensel olarak tek bir yapılandırma uygulamak değil.

İyi bir başlangıç sezgisel kuralı: bir şeyin tüm örneklerini etkileyen her şeyi kilitleyin (global stiller, şablon yapısı) ve tek bir örneği etkileyen her şeyi açık bırakın (tek bir sayfanın metni ve görselleri). Bir müşteri tek bir sayfayı bozarsa, bu 5 dakikalık bir düzeltmedir. Global bir stili bozarsa, bu 20 dakikalık bir düzeltme ve bir güvenlik endişesidir.

Bunu müşteriler arasında nasıl tekrarlanabilir hale getirirsiniz?

Ajans iş akışı burada devreye girer. Tasarım token'larınızı — renk paleti, tipografi ölçeği ve boşluk ön ayarları — tanımlayan bir temel theme.json dosyanız ve ardından belirli değerleri genişleten veya değiştiren müşteri başına bir geçersiz kılma dosyanız olmalıdır.

Bir "başlangıç" blok teması oluşturarak başlayın. theme.json ile özel bir blok teması nasıl oluşturulur — geliştirip belgeledikten sonra, yeni bir müşteriye kopyalamak marka renklerini ve fontlarını değiştirmek meselesidir. Tekerleği yeniden icat etmiyorsunuz; token'ları değiştiriyorsunuz. Bu tam olarak her WordPress sitesini yeniden oluşturmayı bırakma zihniyetidir, ancak arka uç yerine editöre uygulanmıştır.

theme.json tek bir dosya olduğu için, birden fazla ortamda sürüm kontrolü ve dağıtımı da kolaydır. Değişiklikleri inceleyebilir, bir müşterinin global stillerde ne değiştirdiğini görebilir ve bu değişiklikleri temel dosyanızla karşılaştırabilirsiniz. Bu size destek talepleri için güçlü bir denetim izi sağlar.

Birden fazla site yönetiyorsanız ve henüz bir temel tema kurmadıysanız, şimdi tam zamanı. Bu, müşteri editörü her açtığında kendini amorti eden özel WordPress işinin tek parçasıdır.

"Bir renk daha" isteyen müşterilere ne dersiniz?

Paletiniz bir sözdür. Beş marka rengi tanımlarsanız ve bir müşteri altıncı bir renk isterse, cevap "hayır" değil — "evet, ancak palete bilinçli bir ekleme olarak gelir, bir başlıktaki tek seferlik bir hex kodu olarak değil." theme.json'a bir renk eklediğinizde, site genelinde tutarlı bir şekilde kullanılabilir hale gelir. Bu tür talepleri ele almanın doğru yolu budur.

Ayrıca müşteriyle iletişim kurmanız gereken yer burasıdır. Site Editörü'nün onlara yalnızca marka standartlarına uygun renkleri ve fontları gösterdiğini açıklayın. Bu standartları genişletmek isterlerse, bunu tasarım sisteminde halledersiniz ve ardından her yeni renk her yerde kullanılabilir olur — henüz oluşturmadıkları gelecek sayfalar da dahil. Bu, "bunu yapmıyoruz" demekten çok daha iyi bir cevaptır.

Aynı zamanda, kırk renkten oluşan bir palet biriktirmeyin. Üç ayda bir gözden geçirin ve tek seferlik bir kaza olan her şeyi kaldırın. Amaç küçük, bilinçli bir seçenek setidir.

Düzeni kilitler ama içeriği açık bırakırsanız ve paleti müşteri ilişkinizin yaşayan bir parçası haline getirirseniz, Site Editörü bir tehdit olmaktan çıkar. Müşterilerinize, korumakla yükümlü olduğunuz tasarım standartlarından ödün vermeden gerçek bir özerklik vermenin bir yolu haline gelir.