Blok Temalarda Dinamik Şablon Parçaları: Çoğaltmasız Yol

🇬🇧 English: Read this in English →

Elime gelen her blok temalı projede eninde sonunda aynı duvara toslarım. Müşteri vaka çalışması yazılarında bir kenar çubuğu ister, sıradan blog yazılarında bambaşka bir kenar çubuğu. Ya mağaza sayfasında farklı bir üst başlık, ya iniş sayfalarında sadeleştirilmiş bir alt bilgi. Blok tema el kitabının görünürde sana sunduğu en temiz çözüm ise şu: şablonu olduğu gibi çoğalt. İki şablon. Üç şablon. Derken birisi birini düzenler, ötekini unutur ve marka kimliği sayfa türleri arasında usul usul ayrışmaya başlar. Açık konuşayım, bu senaryonun sonunu ezbere biliyorum.

Bu ayrışmayı, hem editörün hem geliştiricinin işini gerçekten iyi bildiği projelerde bile gördüm. Yani mesele disiplin değil, araç. Blok temalar HTML şablonlarının içinde PHP koşullarını kasıtlı olarak desteklemiyor; o yüzden yıllardır kibar yanıt “çoğalt ve idare et” oldu. Ben bu yanıtı hiç sevmedim, çünkü faturasını hep altı ay sonraki birine kesiyor.

Bu hafta WordPress Geliştirici Bloğu temiz bir çıkış yolu yayımladı. Eklenti istemiyor, alt tema oyunbazlığı istemiyor, temayı melez bir yapıya dönüştürmeye de zorlamıyor. WordPress 5.1’den beri çekirdekte öylece duran bir filtreyi kullanıyor. Bir şablonu daha kopyalamadan önce buna dikkatle bakmaya değer — ben olsam bakardım.

Asıl yeni olan ne

18 Haziran 2026’da Justin Tadlock, WordPress Geliştirici Bloğu’nda Dynamically loading template parts in block themes başlıklı yazıyı yayımladı. Yazı, render_block_data filtresinin core/template-part bloğunun slug niteliğini, blok render edilmeden hemen önce, PHP’nin o an görebildiği bağlama göre — sorgu nesnesi, yazı kategorisi, sayfa türü, sorgulayabildiğin her ne varsa — nasıl yeniden yazabileceğini gösteriyor.

Filtrenin kendisi yeni değil. 2019’da WordPress 5.1.0 ile geldi, $parent_block argümanı 5.9.0’da eklendi. Yeni olan şey, resmi bir WordPress kanalında bu filtreyi şablon parçası bloklarına bağlamanın, blok temalarda bağlam duyarlı düzenler için doğru yanıt olduğunun açıkça söylenmesi. Bugüne kadar hâkim tavsiye ya şablonları çoğaltmak ya da kalıp tabanlı varyantlar kaydetmekti. Yani teknik yıllardır oradaydı; eksik olan, çekirdeğin “evet, bunu böyle yapabilirsin” demesiydi.

Mekanizma sade. render_block_data‘ya bağlanırsın, render edilen bloğun core/template-part olduğunu doğrularsın, mevcut slug’ın geçersiz kılmak istediğin slug olduğunu (örneğin sidebar-post) doğrularsın, tekil yazı görünümünde olduğunu ve sorgu nesnesinin WP_Post olduğunu kontrol edersin, ardından $parsed_block['attrs']['slug'] değerini bağlama özgü olana çevirirsin: sidebar-post-haberler, sidebar-post-vaka-calismasi, her ne ise. Diziyi geri döndürürsün. WordPress yeni parçayı render eder. Hedef dosya parts/ içinde yoksa değiştirme sessizce atlanır — yani kategoriye özel varyant eklemek isteğe bağlı ve hata üretmeyen bir iş.

Klasör düzeni get_block_theme_folders()‘in tanımladığı standart düzen — modern blok temalarda şablon parçaları parts/ içinde durur (block-template-parts/ eski uyumluluk için bırakıldı). Yeni dizin yok, yeni adlandırma kuralı yok. sidebar-post.html dosyasının yanına sidebar-post-haberler.html bırakırsın, filtre yönlendirir. Sevdiğim tam da bu: öğrenilecek yeni bir kavram değil, zaten bildiğin bir dosya düzeninin üstüne çakılan küçük bir zeka.

WordPress ve WooCommerce tarafı için neden önemli

Bunun gerçekten önemli olmasının dürüst nedeni şu: tam olarak bu mesele yüzünden blok temalar üç yıldır klasik temalara karşı sınır vakalarını kaybediyor. Müşteri “ürün sayfalarında farklı kenar çubuğu” der ve geliştiricinin elinde üç kötü seçenek kalır: tekil şablonu çoğaltmak (bakım maliyetini ömür boyu sırtlamak), özel şablon kaydeden bir eklenti yazmak (sürüm uyumsuzluğu maliyetini sırtlamak) ya da blok tema modeliyle çelişen melez bir PHP şablonu eklemek. Site Editor’ı geleceğin yolu diye sunarken bunların hiçbiri iyi yanıt değil.

WooCommerce mağazaları için bu konu özellikle can alıcı. Ürün kategori sayfaları, tekil ürün sayfaları, sepet, ödeme ve hesap sayfaları çoğu zaman farklı üst başlık yüksekliği, farklı alt bilgi, farklı çapraz satış kenar çubuğu ister. Klasik yanıt WooCommerce şablonlarını PHP’de geçersiz kılmaktı. render_block_data ile blok temayı bozmadan kalırsın ve parçaları is_product_category(), is_checkout() ya da WooCommerce’in zaten sunduğu herhangi bir koşulla değiştirebilirsin — on yıl önce functions.php içinde nasıl yapardıysan öyle, ama bu sefer temiz biçimde blok katmanına oturmuş olarak.

Bir başka önemli yön de platformun geri kalanıyla iyi anlaşması. Filtre blok render edilmeden önce çalışır; yani bloğun render_callback‘inden önce, blok bağlamaları çözülmeden önce, blok biçimlendirmesi yanıta gitmeden önce. Bu sıralama, aşağı akıştaki her şeyin — görünüm geçişleri, spekülatif yükleme, WordPress 7.1‘e yönelik gelecek AI Client gömme çalışmaları — yer tutucu yerine son değiştirilmiş çıktıyı görmesi demek. Çift render yok. Önbellek karmaşası yok. Bu tür sessiz doğru sıralamalar, bir mimarinin kağıt üstünde değil sahada sağlam olduğunun işaretidir.

Varsayılan tema tarafı için bu, Twenty Twenty-Five‘i ve ardından gelen blok temalarını editöryal siteler için çoğaltma vergisi olmadan yeterince esnek kılan örüntü. Şablon sayısı yirmiyi aşmaya başlamış birkaç dergi projemiz var. Bu örüntü onları rahatlıkla tekrar tek haneli rakamlara çekebilir — ve bunu söylerken içim rahat.

Bir uyarı: tam sayfa önbelleği ile bağlamı karıştırma

Şimdi coşkuyu bir dakikalığına kesip masaya bir uyarı bırakayım, çünkü bu tekniği ilk kez heyecanla benimseyen birinin ayağı buraya takılır. Filtre “o an PHP ne görüyorsa” mantığıyla çalışıyor. Ama önünde tam sayfa önbelleği varsa — bir CDN, bir page cache eklentisi, barındırıcının kendi kenar önbelleği — o çıktı bir kez üretilip donduruluyor ve sonraki ziyaretçilere aynı HTML servis ediliyor. Yani bağlamın istikrarlı olduğundan emin ol: URL’ye sabitlenmiş bağlam (kategori arşivi, ürün kategorisi, tekil yazı) güvenli, çünkü o URL için doğru varyant zaten önbelleğe yazılır.

Tehlikeli olan, aynı URL’de kişiye göre değişen bağlama yaslanmak: kullanıcı rolü, giriş yapıp yapmama durumu, sepet doluluğu, günün saati. Bunlardan birine göre parça değiştirirsen ve o sayfa da agresif önbelleğe alınıyorsa, ilk ziyaretçinin varyantı herkese servis edilir. Ben olsam kuralı şöyle koyardım: render_block_data ile yalnızca önbellek anahtarının bir parçası olan bağlama göre değiştir. Kişiye özel varyant istiyorsan orası ya blok düzeyinde önbellek dışı bırakma ister ya da bambaşka bir çözüm — bu filtre o iş için yanlış alet. Test ederken de önbelleği açık bir staging ortamında dene, temiz bir yerel kurulumda değil; sorun tam olarak orada saklanır.

Ne yapardım, ne yapmazdım

Bu örüntüyü benimserdim, ama dikkatle. Yirmi yıl üretim temalarına dokunmaktan kalan üç kural.

Bir: filtre geri çağırmasını bir mu-plugin içinde ya da temanın functions.php dosyasında tut, dosyalara dağıtma. Filtre her blok render’ında çalışır. İçinde pahalı bir iş yaparsan maliyet katlanarak büyür. Mümkün olduğunca erken geri dön. Önce blok adını, sonra slug’ı, sonra bağlamı kontrol et. En ucuz karşılaştırmayı en başa koy.

İki: kalıp olması gerekeni ifade etmek için bu filtreyi kullanma. Varyant tamamen görselse ve editörlerin kendisi ekleyebilmesi gerekiyorsa, senkronize ya da senkronizesiz bir kalıp kaydet ve seçimi editöre bırak. render_block_data‘yı yalnızca değişiklik editöre görünmez olmalı ve bir sistem kuralına — kategori, içerik türü, kullanıcı rolü, yerel dil, günün saati — bağlanmalıysa kullan. Editöryal kararlar editörün işidir. Yönlendirme kararları kodun işidir. Bu ayrımı bulanıklaştıran her proje, altı ay sonra kimin neyi nereden değiştireceğini kimsenin bilmediği bir bataklığa döner.

Üç: değiştirilen dosyaları tutarlı adlandır. sidebar-post.html varsayılan, sidebar-post-{kategori-slug}.html geçersiz kılma. Bir kural belirle ve projede ona sadık kal. Altı ay sonra projeyi soğuk açan gelecekteki sen, sevimlilik olsun diye tuhaf isimler vermeyen bugünkü sana teşekkür edecek.

Yapmayacağım şey: bu tekniği gezinti bloğuna ya da yazı içeriği bloğuna uygulamak. Yazı bunu haklı olarak şablon parçalarıyla sınırlamış. O bloklardaki slug davranışı farklıdır ve çözmeye çalıştığından daha zor sorunlar yaratırsın.

Blok tema modeli karmaşıklaşmadan daha kullanışlı hâle geldi. Sevdiğim güncelleme türü tam olarak bu — sessiz bir filtre, doğru kullanıldığında gerçek kod tabanlarından koca bir çoğaltma kategorisini kaldırıyor. Gösterişi olmayan ama gündelik hayatını kolaylaştıran türden bir kazanç, ki bence en değerlileri de bunlardır.