Her WordPress Sitesini Yeniden Kurmayı Bırakın

Özet

Çoğu ajans, paylaşılan bir temel süreden haftalar kazandırsa bile, her WordPress sitesini boş bir temadan kurar. Bu makale, theme.json, blok desenleri ve dinamik blokların, her müşterinin kendine özgü tasarımını korurken yapısal katmanı standartlaştırmanıza olanak tanıdığını savunuyor. Takımları değişmekten alıkoyan beş itirazı doğrudan ele alıyor: 'farklı müşterilerimiz var', 'özel bloklar pahalı', 'editör kafa karıştırıcı', 'hook'larımızı ve filtrelerimizi kaybederiz' ve 'FSE üretime hazır değil'. Her itiraz, kademeli olarak benimseyebileceğiniz pratik bir karşı argüman ve somut bir desenle yanıtlanıyor. Ödül, müşteriye özel işleri ait olduğu yerde onurlandıran tekrarlanabilir bir kurulum sürecidir. Uyarı: tek tıkla sıfırlama butonu vaat edilmiyor.

Kaç müşteri siteniz tek bir kod satırını bile paylaşıyor? Telif hakkı satırını değil—gerçek kodu. Cevap "neredeyse hiç" ise, acıyı zaten hissetmişsinizdir: dokuzuncu kez yeniden inşa edilen aynı hero bölümü, bir projeden diğerine kopyalanan aynı takım-grid işaretlemesi, yarım düzine tema boyunca çapraz referanslı aynı ön işleme ince ayarları. Ayrıca savunmayı da duydunuz: "Her müşterinin farklı ihtiyaçları vardır." Doğru. Ancak herkesin çıkardığı sonuç—her sitenin özel bir temele ihtiyacı olduğu—yanlış. WordPress ekosistemi artık tasarımı standartlaştırmadan yapısal parçaları standartlaştırmanın bir yolunu sunuyor: tasarım token'ları için theme.json, tekrarlanan düzenler için blok desenleri ve gerçek sunucu tarafı mantık gerektiren birkaç özellik için dinamik bloklar. Bu makale, ajansları bu adımı atmaktan alıkoyan itirazlar ve onlara karşı çıktığınızda gerçekten işe yarayan şeyler hakkında.

"Ama her müşteri farklı" itirazı

Altında yatan ilke: temeli standartlaştırın, yüzeyi değil. Yapıyı paylaşılan bir kütüphanede tutmanın nedeni, görsel katmanı özgür bırakmaktır. Bir theme.json dosyası bir tasarım değildir—bir dizi tasarım token'ıdır. Renkler, boşluklar ve tipografi değerlerdir, işaretleme değil. Kritik değişim budur: işaretlemeyi paylaşabilirsiniz, siteye özel theme.json ise siteyi farklı bir marka için tamamen farklı gösterir.

İki müşteri düşünün: bir hukuk bürosu ve bir açık hava perakendecisi. Tasarım dilleri birbirinden çok farklı. Ama ikisinin de bir hero bölümüne, bir referans grid'ine ve bir harekete geçirici mesaj bandına ihtiyacı var. Her biri için işaretlemeyi yeniden inşa etmek yerine, üç blok deseni oluşturun ve her müşterinin theme.json'unun renkleri, yazı tiplerini ve boşlukları tanımlamasına izin verin. Yapı aynı kalır; tasarım token'ları onu bir markadan diğerine dönüştürür. Perakendeci önümüzdeki bahar renk paletini değiştirdiğinde, sitelerindeki bir dosyayı düzenlersiniz—altı şablondaki işaretlemeyi değil.

Pratikte bu, ekibinizin desenleri kod olarak oluşturduğu, bunları paylaşılan bir eklentiye kaydettiği ve her müşteri sitesinde boyamayı theme.json'un yapmasına izin verdiği anlamına gelir. Desenin sınıf adları mimariniz olur; değerler değişkenleriniz olur. Daha da ileri giderek theme.json'u yazı tipleri veya eklenti çıktısı için özel ayarlar içerecek şekilde genişletebilirsiniz, ancak bir noktada bir site yerine bir yapılandırma arayüzü inşa ediyorsunuz—theme.json'u genişletmeye bakışımız tartışılan bir tuzak. Paylaşılan katmanı yalın tutun: yalnızca müşteriler arasında tekrarlanan şeyleri içermelidir. Kendinizi "bir gün biri isterse" diye bir ayar eklerken bulduğunuz anda, bakımı kazandığından daha pahalıya mal olacak bir soyutlama yaratmışsınızdır.

Yeni bir müşteri kurarken ilk otuz dakika şöyle olmalı: paylaşılan desenler eklentisini kopyalayın, müşterinin paleti ve yazı tipi ölçeğiyle yeni bir theme.json oluşturun ve logolarını ile altbilgilerini kaydedin. Bu özel bir kurulum değil; bir yapılandırma görevidir. Geriye kalan müşteriye özel iş, içerik, yapı ve gerçekten kişiye özel özelliklere gider. Her evi sıfırdan inşa etmek ile yeniden boyayabileceğiniz ve yeniden duvar kağıdı yapabileceğiniz prefabrik kat planlarına sahip olmak arasındaki fark budur. Benzetme gevşek ama ilke geçerli: theme.json değerlerine ne kadar çok şey eklerseniz, işaretlemeye o kadar az dokunmanız gerekir.

En basit kazanımlardan biri, blok desenlerinin nasıl çalıştığına gerçekten bakmaktır. Bir desen, önceden tanımlanmış içerik ve stilleme ile bir dizi bloktan oluşur. Herhangi bir blok yapılandırmasını bir desen olarak kaydedebilirsiniz; böylece müşteri nasıl inşa edildiğini bilmesine gerek kalmadan onu ekleyebilir. Bu, desenin teknik olmayan kullanıcılar için bir 'giriş noktası' haline geldiği anlamına gelir. Ekibiniz altta yatan deseni kod olarak koruduğunda, müşteri tek bir PHP etiketine dokunmadan tutarlı bir kütüphane elde eder.

Şimdi sürekli geri döndüğüm uyarı: aşırı merkezileştirmeyin. Olası her nüans için bir ayar içeren bir theme.json, bakım bataklığıdır. Paylaşılan desenler fikir sahibi olmalı, her şeye gücü yeten değil. Bir müşterinin radikal derecede farklı bir düzene ihtiyacı varsa—diyelim ki büyük bir öne çıkan grid içeren bir dergi ana sayfası—standart desen kütüphanenize uymayabilir. Sorun değil. Standardizasyon, benzer olan projelerin %80'inde kazanmanız anlamına gelir, her siteyi aynı kalıba sokmanız değil.

"Özel bloklar bütçeyi aşar" itirazı

İşte sıkıcı görünen ama para kazandıran bir karşı ilke: özel blok gerektirdiğini düşündüğünüz çoğu şey gerektirmez. Çekirdek bloklar artı bir desen, düzenlerin ezici çoğunluğunu karşılayabilir. Özel blok son çaredir, ilk niyet değil.

Klasik örnek takım grid'idir. Tek seferlikse, çekirdek 'sütunlar' ve 'grup' bloklarını kullanın ve müşterinin avatarını elle eklemesine izin verin. Üç müşteri aynı grid'i, 'isim altında sosyal linkler' yapısıyla isterse, artık bir blok deseni için adayınız var. Bu desen yeni seçenekler toplamaya başladığında—hover efektleri, sıralama, oy yıldızları—desen yönetilemez bir çanta haline gelir ve işte o zaman özel bir blok yazmanın zamanı gelir. Bütçeye zarar veren hata, ilk istekte doğrudan özel bloğa atlamaktır.

Daha sinsi bir senaryo: müşteri 'vaka çalışması karuseli' ister. İlk içgüdü 'bir karusel bloğuna ihtiyacım var' diye düşünmektir. Ama gerçekten bir karusele mi ihtiyaçları var? Belki de yatay kaydırılabilir bir yazı grubuna ihtiyaçları vardır; bunu çekirdek bloklar bir 'grup' bloğu ve biraz CSS ile halledebilir. Ya da belki de son vaka çalışmalarının dinamik bir listesine ihtiyaçları vardır; bu da CPT'yi sorgulayan dinamik bir bloktur. Soru 'müşteri hangi özelliği istiyor?' değil, 'hangi verilere bağlı?'dır. Veriler statikse ve müşteri tarafından düzenlenebilirse, bir desen yeterlidir. Veriler bir veritabanı sorgusundan geliyorsa, dinamik bir blok haklıdır. Verilerin bir API'den gerçek zamanlı güncellenmesi gerekiyorsa, bunun yerine bir REST API entegrasyonuna bakıyor olabilirsiniz—bu farklı türde bir kuruluma geçer.

Bir blok inşa ettiğinizde, block.json arkadaşınızdır. Nitelikler, betikler ve stiller için tek gerçek kaynaktır; bu da bloğu projeler arasında taşınabilir kılar. Ayrıca bağımlılıkları ve çevirileri temiz bir şekilde bildirmenize olanak tanır; bu da bir kütüphaneyi birçok müşteri sitesine dağıttığınızda çok önemlidir. Canlı verilere bağlı içerik için dinamik blok sunucuda işlenir, böylece her sayfa görünümünde bir JavaScript paketi göndermeniz gerekmez. Ve bloğunuz gelişirse, mevcut içeriği bozmadan kullanımdan kaldırma işlemlerini zarifçe yönetebilirsiniz—blok kullanımdan kaldırma rehberimiz tam deseni adım adım anlatır.

Bir şey inşa etmeden önce kararı şu tablodan geçirin:

Yaklaşım	En iyi olduğu durum	Kaçınılması gereken durum
Çekirdek blok	Tek seferlik içerik, basit sayfalar	Düzen birçok müşteride tekrarlanıyor ve zengin seçenekler gerektiriyor
Blok deseni	Mantık içermeyen tekrarlanabilir düzenler	Düzen koşullar, dinamik veri veya karmaşık etkileşimler gerektiriyor
Özel blok	Tekrarlanan, veri odaklı veya çok özel davranış	Tek neden, bir sınıfla halledilebilecek tek seferlik bir bölümse

Ayrıca blok adlandırmayı ilk günden düşünmek isteyeceksiniz. Bir blok adı, temelde içeriğinizle yapılmış bir sözleşmedir. Ona wagent/team-grid adını verirseniz ve daha sonra wagent/team-carousel olarak yeniden adlandırırsanız, bir kullanımdan kaldırma yolu sağlamadığınız sürece mevcut içeriği bozarsınız. Blok geliştikçe yanlış tanıtım haline gelmeyecek genel, amaca dayalı adlar seçin. Bu, herkesin eklenti öneklerinden öğrendiği adlandırma disiplininin bir çeşididir ve blok adları için de aynı derecede geçerlidir.

Buradaki muhalif görüş, söyleyebileceğim en faydalı şey: bir müşterinin 'sadece tek bir parça' istemesi üzerine inşa ettiğiniz özel blok neredeyse her zaman bir hatadır. Kibarca hayır deyin, bir sınıfla birlikte çekirdek blok gönderin ve saatleri bankaya yatırın. Müşteriden daha çok saygı görürsünüz—ve bakım bütçesinde daha küçük bir satır.

"Müşteriler editörü bozar" itirazı

Bu itiraz yarı doğru. Blok editörünün kendisi sorun değil; sorun müşterilere çok fazla serbestlik tanımak. theme.json, düzenlenebilir olanı kilitleyebilir: şablon düzenleyiciyi devre dışı bırakın, izin verilen blokları kısıtlayın ve yanlış yerleştirilmiş bir sütunun daha az hasar vermesi için varsayılan stiller belirleyin. Bazı müşteriler yine de bir şeyleri kırmayı başaracaktır, ancak bir sayfayı tek tıkla kayıtlı bir desene geri döndürebilirsiniz—klasik editörün sunamadığı bir şey.

Bir senaryo çizeyim. Bir müşteri arayıp 'Bir bölümü taşıdım ve şimdi sayfanın tamamı yanlış görünüyor' diyor. Klasik bir temada, giriş yapar, CSS'i inceler ve muhtemelen düzeni düzeltmek için bir saat harcarsınız. Blok kurulumunda, sayfayı açabilir, içerik alanını seçebilir ve kayıtlı desene sıfırlayabilirsiniz. Desen temeldir; müşterinin değişiklikleri katmandır. Katman bozulduğunda, onu kaldırırsınız. Bu sadece daha iyi bir iş akışı değil; temelde daha affedici bir editördür.

Şimdi nüans: çoğu müşteri hiç düzenleme yapmak istemez. Metin değiştirmek, fotoğraf değiştirmek ve belki bir bölümü yeniden sıralamak isterler. Blok deseni, sitenin tamamını açığa çıkarmadan size tam olarak bunu verir. Bu anlamda editör bir oyuncak değildir; bir vizördür. Sizin işiniz, müşterilerin ne görebileceğini kalibre etmektir. Bu, 'Şablonlar' ayarlarını devre dışı bırakabileceğiniz, blok ekleyiciyi seçilmiş bir listeyle sınırlandırabileceğiniz ve hatta boş desenleri yer tutucu çalışmayla önceden doldurabileceğiniz anlamına gelir. Editör, bir web tasarım tuvalinden ziyade bir içerik giriş formu haline gelir.

Erişilebilirlik tarafında, blok editörünün odak yönetimi ve klavye desteği genellikle klasik bir editörün şablon alanlarından daha iyidir. Ancak yine de desenlerin uygun başlık hiyerarşisine ve erişilebilir adlara sahip olduğundan emin olmanız gerekir. Desen müşteriler arasında paylaşıldığından, bu sorunları yalnızca bir kez çözersiniz; bu da standardizasyonun bir başka gizli kazancıdır.

Gerçekten zor olan kısım içseldir. Ekibiniz için bloklarla prototiplemeyi öğrenmek, 'PHP'de yap' alışkanlığını unutmayı gerektirir. Bu gerçek bir maliyettir, ancak kişi başına bir kerelik bir maliyettir. Yaklaşımdan kaçınmak için bir neden değildir; her yerde uygulamaya koymadan önce tek bir desen kütüphanesi ve affedici bir müşteriyle başlamak için bir nedendir. 'Müşterilerim bloklarla baş edemiyor' nakaratının, onlarla yarı yolda buluşacak bir blok kurulumu henüz yapılandırmadığınız gerçeğini gizlemesine izin vermeyin.

"Zaten hook'larımız ve filtrelerimiz var" itirazı

Buradaki ilke şudur: hook'ları atmıyorsunuz; üstüne bir katman ekliyorsunuz. Bloklar sunum sınırıdır; hook'lar hâlâ mantık enjekte etme yolunuzdur. Dinamik bir bloğun oluşturma geri çağrısı PHP'de çalışır; bu, aynı işlevleri çağırabileceğiniz ve zaten güvendiğiniz filtreleri uygulayabileceğiniz anlamına gelir.

Herhangi bir yazıya bir filtre kullanarak 'öne çıkan ürün' alanı eklemenizi sağlayan bir eklenti hayal edin. Dinamik bir blokla, bu filtreyi çalıştıran ve çıktıyı bloğun sarmalayıcısı içinde yazdıran sunucuda işlenen bir blok ekleyebilirsiniz. Müşteri bloğu ekler; mevcut PHP mantığı ağır işi yapar. Hiçbir şey atılmaz. Daha somut bir örnek için, son proje yazılarını listeleyen özel bir blok düşünün. Oluşturma geri çağrısında get_posts() işlevini çağırır, ardından döngü yapar ve the_title() ile the_permalink() uygularsınız—yıllardır kullandığınız aynı şablon etiketlerini.

Ayrıca neyin aktarılamayacağı konusunda dürüst olmanın yeri de burası. Bazı akıllı eski temalar, sayfa bağlamına göre argüman alan karmaşık koşullar içeren template-parts kullanır. Bunu bir blok olarak yeniden yaratmak dağınık olabilir. Ancak hepsini aynı anda yeniden yaratmak zorunda değilsiniz. Kademeli yol, PHP mantığını korumak, onu dinamik bir bloğa sarmak ve işaretlemeyi blok şablonuna taşımaktır. Mevcut filtre desenlerinizin yeni çıktıyı işleyebildiğini sık sık göreceksiniz. Ve mantık bir şablon hiyerarşisine sıkı sıkıya bağlıysa (örneğin, 'arama sonuçlarında bunu farklı göster'), normal sayfalar için bloklar kullanırken belirli görünümler için yine de klasik şablonu kullanabilirsiniz.

REST API ayrıca farklı bir kapı açar: diğer WordPress sitelerinden veya üçüncü taraf hizmetlerden veri çeken bloklar oluşturabilirsiniz. Dinamik bir blok, JSON almak ve ön yüzde işlemek için wp_remote_get() çağrısı yapabilir. Bu, müşterilerin ayrı bir entegrasyon yönetmeden sosyal akışları, ürün listelerini veya dahili verileri göstermek istediği ajans kurulumları için güçlü bir desendir. Ödünleşim önbelleğe alma ve hata işlemedir—uzak API yavaşsa, sayfanız da yavaş olur. API tabanlı blokları kritik üst-ekran içeriğin dışında tutun veya uygun bir yükleme durumuyla istemci tarafı işleme kullanın.

Actions ve filtreler kaydetme ve işleme etrafında hâlâ çalışır; blokları benimsediğinizde hook mimarisi yok olmaz, sadece yeni bir bağlama taşınır. Actions ve filtrelerin bu yeni blok dünyasıyla nerede buluştuğuna dair anlayışınızı tazelemeniz gerekiyorsa, hook'lara derin dalışımız yararlı bir tazelemedir.

"FSE üretime hazır değil" itirazı

Haklısınız, ama 'riskli'nin gerçekte ne anlama geldiğini sorun. Tam Site Düzenleme birkaç sürümden geçti ve theme.json istikrarlı bir şemaya oturdu. Risk, editörün 'aniden bozulması' değildir—risk, ekibinizin özel kodunun blok şablonlarıyla garip bir şekilde bir arada var olan eski tarz PHP şablonlarına dayanmasıdır. Ayrıca bazı üçüncü taraf eklentiler hâlâ klasik editörü veya özelleştiriciyi varsayar. Bu bir uyumluluk kararıdır, tüm modeli çöpe atmak için bir neden değildir.

Bunun hakkında düşünmenin yararlı bir yolu: bloklarla yazılmış içeriğe sahip basit, tekrarlanabilir siteler en az risklidir. Yüksek riskli müşteriler, kendi ön yüzünü işleyen derinden özelleştirilmiş klasik temalara veya tescilli eklentilere sahip olanlardır. Bu küçük niş için klasik temalara sadık kalmak için meşru bir nedendir. Hata, 'üretime hazır'ın açık ya da kapalı tek bir anahtar olduğunu varsaymaktır.

Bir müşteriye blok teması önermeden önce hızlı bir kontrol listesinden geçin:

• Müşterinin göç gerektirecek yoğun şekilde özelleştirilmiş bir teması var mı?
• Olmazsa olmaz eklentiler Site Düzenleyici ve REST API'yi destekliyor mu?
• Barındırma ortamı, blok temasının beklediği dosya erişimine izin veriyor mu?
• Sadece blok kaydı için değil, desen tasarımı için de zaman ayırdınız mı?
• Müşterinin ekibi editör değişikliklerine tahammül edecek mi, yoksa kilitli bir şablona mı ihtiyaçları var?

Herhangi bir cevap hayırsa, kapsamı ayarlayın veya hibrit bir yaklaşım kullanın. Bu bir taviz değildir; mühendislik kararıdır. Ve hibrit inşa ediyorsanız, yukarıdaki hook'lar ve filtreler hikayesini hatırlayın—theme.json genel görünümü hallederken eski mantığı dinamik bloklara sarabilirsiniz.

theme.json dosyanızı sürümlemek yalnızca teorik bir endişe değildir. Bir ajansın özel blok kütüphanesinin, müşteri WordPress'i güncellediğinde ve bloğun style dosyası değiştirilmiş bir tanımlayıcıyla wp_register_style() ile kaydedildiğinde bozulduğunu gördüm. Düzeltme kolaydı, ancak panik gerçekti. Basit bir test süreci—güncellemeyi sitenin bir hazırlık kopyasında çalıştırın, önemli sayfaları tıklayın, sonra yayınlayın—bu sürprizlerin çoğunu çözer.

Kendinize yapmadığınız itiraz

Ajansları standartlaşmaktan alıkoyan meta-itiraz şudur: 'Bu büyük bir değişiklik ve müşteri işleri sırasında yapmaya zaman yok.' Bu doğru—bu yüzden bunu müşteri işleri sırasında yapmayın. Dahili bir proje veya küçük bir müşteri seçin ve bir desen kütüphanesi oluşturun. theme.json'u tasarım token sistemi olarak kullanın. Yalnızca gerekçelendirildiğinde özel bir blok ekleyin. Eski hook'ları işe yaradıkları yerde sarın. Yineleyin.

İşte kabaca ilk 30 gün:

1. Son beş müşteri kurulumunuzu denetleyin ve en çok tekrarlanan on düzen parçasını listeleyin.
2. Bu on parçayı, küçük bir CSS sınıfları setiyle blok desenlerine dönüştürün.
3. Bu desenleri kaydeden paylaşılan bir eklenti (veya mu-plugin) oluşturun. Bunun için eklenti organizasyonunu düşünmediyseniz, önce sağlam eklentiler oluşturma rehberine göz atın.
4. Temel tasarımınıza uyan bir theme.json oluşturun; projeleri başlatırken müşteriye özel değerler ekleyin.
5. Küçük bir dahili proje veya dostça bir müşteri seçin ve bu yığına taşıyın.
6. Sizi aramadan ana sayfasını düzenleyen bir müşteriye dair bir kahraman hikayesi belgeleyin.

Bu deneyin sonunda, duvara asacak bir 'blok-öncelikli' rozetiniz olmayacak. Paylaşılan bir temelden yeni bir müşteri sitesi kurabilen, zaman çizelgesi için özür dilemeyen bir ekibiniz olacak. Ayrıca müşterinin 42'nci özel blok isteğine hayır demek için daha iyi bir konumda olacaksınız—çünkü çekirdek blokların tam olarak neler yapabileceğini biliyorsunuz veya dinamik bir bloğun gerçekten daha hızlı olacağını gösterebilirsiniz.

Hâlâ bazı kişiye özel siteler inşa edecek misiniz? Evet. Bazı müşteriler her zaman özel bir şablon, kişiye özel bir sayfa veya paylaşılan modele zorlamaya değmeyecek tescilli bir entegrasyona ihtiyaç duyacaktır. Amaç kişiye özel işi ortadan kaldırmak değil—onun varsayılan yerine istisna olmasını sağlamak.

Tekrarlanabilirlik sıkıcı kısımlardan gelir: sağlam bir theme.json şeması, net bir desen kütüphanesi ve paylaşılan katmanı yalın tutma disiplini. Bu, webinerlerde duyduğunuz gösterişli sürüm değil. Pazartesi sabahı boş tema hüznünü yenen sürüm.