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

Elimize gelen her blok temalı projede aynı duvara çarpıyoruz. Müşteri vaka çalışması yazılarında farklı bir kenar çubuğu istiyor, sıradan blog yazılarında başka bir kenar çubuğu istiyor. Ya da mağaza sayfasında farklı bir üst başlık. Ya da iniş sayfalarında sadeleştirilmiş bir alt bilgi. Blok tema el kitabının görünürde sunduğu en temiz çözüm ise şu: şablonu olduğu gibi çoğalt. İki şablon. Üç şablon. Sonra birisi birini düzenliyor, diğerini unutuyor ve marka kimliği sayfa türleri arasında ayrışmaya başlıyor.

Bu senaryoyu, editörün de geliştiricinin de işini iyi bildiği projelerde bile şablonların birbirinden kopmasıyla bitiyor gördüm. Disiplin meselesi değil, araç meselesi. 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.

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

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 render edilmeden hemen önce, PHP’nin o anda görebildiği bağlama göre — sorgu nesnesi, yazı kategorisi, sayfa türü, sorgulayabildiğiniz herhangi bir şey — 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ğlama 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.

Mekanizma sade. render_block_data‘ya bağlanırsınız, render edilen bloğun core/template-part olduğunu doğrularsınız, mevcut slug’ın geçersiz kılmak istediğiniz slug olduğunu (örneğin sidebar-post) doğrularsınız, tekil yazı görünümünde olduğunuzu ve sorgu nesnesinin WP_Post olduğunu kontrol edersiniz, ardından $parsed_block['attrs']['slug'] değerini bağlama özgü olana çevirirsiniz: sidebar-post-haberler, sidebar-post-vaka-calismasi, her ne ise. Diziyi geri döndürürsünüz. 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 hatasızdır.

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ız, filtre yönlendirir.

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” diyor ve geliştiriciye üç kötü seçenek kalıyor: tekil şablonu çoğaltmak (bakım maliyetini ömür boyu üstlenmek), özel şablon kaydeden bir eklenti yazmak (sürüm uyumsuzluğu maliyetini üstlenmek) ya da blok tema modeliyle çelişen melez bir PHP şablonu eklemek. Site Editor’ı geleceğin yolu olarak sunarken bunların hiçbiri iyi yanıt değil.

WooCommerce mağazaları için bu konu özellikle önemli. Ü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ız ve parçaları is_product_category(), is_checkout() ya da WooCommerce’in zaten sunduğu herhangi bir koşulla değiştirebilirsiniz — on yıl önce functions.php içinde nasıl yapardıysanız öyle, ama temiz biçimde blok katmanında uygulanmış 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 çalışır. 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 anlamına geliyor. Çift render yok. Önbellek karmaşası yok.

Varsayılan tema tarafı için bu, Twenty Twenty-Five ve onun 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şan birkaç dergi projemiz var. Bu örüntü onları tekrar tek haneli rakamlara çekebilir.

Ne yapardım, ne yapmazdım

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

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

İki: kalıp olması gerekeni ifade etmek için bu filtreyi kullanmayın. Eğer varyant tamamen görseldeyse ve editörlerin kendileri ekleyebilmesi gerekiyorsa, senkronize ya da senkronizesiz bir kalıp kaydedin ve seçimi editöre bırakın. 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ın. Editöryal kararlar editörün işidir. Yönlendirme kararları kodun işidir.

Üç: değiştirilen dosyaları tutarlı adlandırın. sidebar-post.html varsayılan, sidebar-post-{kategori-slug}.html geçersiz kılma. Bir kural belirleyin ve projede ona sadık kalın. Altı ay sonra projeyi soğuk açan gelecek-siz, sevimli adlandırma yapmayan şimdiki-size teşekkür edecektir.

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

Blok tema modeli karmaşıklaşmadan daha kullanışlı hâle geldi. Sevdiğim güncelleme türü bu — sessiz bir filtre, doğru kullanıldığında gerçek kod tabanlarından bir çoğaltma kategorisini kaldırıyor.