WordPress blok tema ile klasik tema: dürüst bir karşılaştırma

Tema klasörünüzü açın. İçinde index.html barındıran bir templates dizini ve kök dizinde bir theme.json varsa elinizde bir blok tema var demektir. header.php ve footer.php gibi dosyaların yanında index.php varsa ve yönetim kenar çubuğunuzda Görünüm altında Özelleştirici görünüyorsa, klasik bir temanız var.

Bu tek yapısal fark; sitenizde kimin neyi değiştirebileceğini, bu değişikliklerin nerede saklandığını ve WordPress eklenti ekosisteminin hangi yarısının normal davranacağını belirler.

30 saniyelik teşhis

İşaret	Klasik tema	Blok tema
Kök şablon dosyası	index.php	templates/index.html
Üst bilgi ve alt bilgi	header.php, footer.php	parts/header.html, parts/footer.html
Genel yapılandırma	functions.php	theme.json (isteğe bağlı olarak functions.php ile)
Yönetim menüsü	Görünüm > Özelleştirici	Görünüm > Editör
Düzenlemelerin kaydedildiği yer	Diskteki dosyalar	Veritabanı, wp_template kayıtları olarak
Bileşenler ekranı	Var	Yok

WordPress kararını templates/index.html dosyasına bakarak verir. theme.json taşıyan ama PHP şablonlarını koruyan bir tema hâlâ klasik sayılır — bu ara durum yaygındır ve bir adı vardır; aşağıda ele alıyoruz.

Kabuk erişiminiz varsa tek bir komut meseleyi kapatır:

wp eval 'var_dump( wp_is_block_theme() );'

Sizin kurmadığınız bir sitede en hızlı kontrol WP-CLI’dır; özellikle bir sayfa oluşturucu alışıldık yönetim menülerini gizlemişse.

Siteyi düzenleyen kişi için ne değişir

Klasik temada üst bilgi, alt bilgi, kenar çubuğu, renkler ve logo Özelleştirici’nin arkasında durur ve yalnızca tema yazarının kurmaya karar verdiği kontrollere sahip olursunuz. Tema, alt bilgi telif metni için bir kontrol tanımlamadıysa öyle bir kontrol yoktur. Ya bir PHP dosyasını düzenlersiniz ya da olduğu gibi yaşarsınız.

Blok temada Site Editor sayfanın tamamını açar. Üst bilgi, alt bilgi, döngü, 404 sayfası, arama sonuçları yerleşimi — hepsi bloktur ve hepsi hayatında PHP görmemiş biri tarafından düzenlenebilir. Asıl manşet özellik budur ve gerçekten büyüktür.

Bedeli ise şudur: her şey, hayatında PHP görmemiş biri tarafından düzenlenebilir. Bir müşteri gecenin ikisinde site başlığını üst bilgiden silebilir ve geri dönmek için diskte bir sürüm geçmişi yoktur — yalnızca Site Editor’ın kendi revizyonları vardır. Blok kilitleme ve editöre kimin erişeceğini sınırlamakla işleri kilitlemek mümkündür, ama bu isteğe bağlı ve hatırlamanız gereken ek bir iştir.

Pratikte canınızı yakan iki küçük kayıp daha var: blok temalarda Bileşenler ekranı yoktur (bileşen alanlarının yerini şablon parçaları ve bloklar alır) ve klasik menülerin yerini, öğelerini alışılmış Menüler ekranı yerine ayrı bir içerik türünde saklayan Navigasyon bloğu alır.

Geliştirici için ne değişir

Klasik temalar PHP şablon hiyerarşisini kullanır. WordPress bir isteği bilinen bir zincir boyunca çözer — single-{post-type}.php, sonra single.php, sonra singular.php, sonra index.php — ve sizin dosyanız çalışır, get_header() çağırır, The Loop’u döndürür ve karakteri karakterine denetlediğiniz işaretlemeyi basar.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Blok temalar aynı hiyerarşi adlarını .html uzantısıyla kullanır, ama dosyanın içinde blok işaretlemesi vardır — yorum içine gömülü blok sınırlayıcılarıyla yazılmış HTML — ve şablon etiketleri yoktur:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Geliştiricilerin hemen çarptığı üç sonuç var:

get_header() ve get_footer() asla çalışmaz. Bir eklentide ya da eski bir alt temada bu aksiyonlara bağlanmış her şey sessizce hiçbir şey yapmaz. wp_head ve wp_footer hâlâ tetiklenir, dolayısıyla kuyruğa alma işlerinin çoğu hayatta kalır; ama üst bilgiye özgü kancalar kalmaz.

Veritabanı dosyalarınızı yener. Biri Site Editor’da bir şablonu kaydettiği anda WordPress o sürümü wp_template kaydı olarak saklar ve sizin dosyanız yerine onu sunar. HTML dosyasını bütün öğleden sonra düzenleyip ön yüzde sıfır değişiklik görebilirsiniz. O şablonun özelleştirmesini temizlemek dosya sürümünü geri getirir. Bu, gelen en yaygın “blok temam bozuk” bildirimidir ve bir hata değildir.

Stil işi theme.json içine taşınır. Renkler, boşluk ölçeği, tipografi ve blok bazlı varsayılanlar CSS yerine veri olarak tanımlanır, CSS’i WordPress üretir. Bu daha temiz ve çok daha tutarlıdır — ta ki şemanın ifade edemediği bir şeye ihtiyacınız olana kadar; o noktada zaten CSS yazıyor ve üretilen kurallara karşı özgüllük savaşı veriyor olursunuz.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

version değerini kullandığınız WordPress sürümüne göre kontrol edin — şema birden fazla kez revize edildi ve eski bir eğitim içeriğinden sürüm numarası kopyalamak sessizce yok sayılan ayarlar üretir.

functions.php dosyasının ortadan kalkmadığını da unutmayın. Blok temalar bu dosyayı hâlâ kuyruğa alma, add_image_size tanımları, özel yazı türleri ve PHP gerektiren her şey için kullanır. Yalnızca orada çok daha az şablon işi yaparsınız.

Gerçekte ne kazanırsınız, gerçekte ne kaybedersiniz

Bloka geçmek size şunları kazandırır: sayfanın tamamı üzerinde editör denetimi, theme.json ile dayatılan tasarım tutarlılığı, bakımı gereken daha az dosya ve editör ile ön yüz arasında klasik temaların hiç beceremediği ölçüde eşleşen stiller.

Bloka geçmek size şunları kaybettirir: çıktı işaretlemesi üzerindeki doğrudan denetim, kancaya dayalı basit özelleştirme, PHP şablonlarını varsayan her şeyle uyumluluk ve sitenin görünümünün sürüm denetiminde durduğu güveni.

Sonuncusunun altını çizmek gerekir. Klasik temada git log size neyin değiştiğini söyler. Blok temada sitenin görünümünün kayda değer bir kısmı, dağıtım hattınızın hiç bakmadığı veritabanında yaşar.

Klasik temanın hâlâ doğru cevap olduğu durumlar

• Siteyi bir sayfa oluşturucu yönetiyor. Elementor, Divi, Beaver Builder ve benzerleri şablon işini kendileri devralır. Altına bir blok tema sermek, hiçbir işe yaramayan ikinci bir şablon sistemi ekler.
• İşaretlemenin tam olarak belirlenmiş olması gerekiyor. Özel bileşen kitaplıkları, katı erişilebilirlik işaretlemesi, sıra dışı şema gereksinimleri — blok çıktısı blokların ürettiğiyle sınırlıdır ve buna karşı savaşmak PHP yazmaktan pahalıya gelir.
• Yoğun eklenti şablonlaması var. Üyelik, LMS, dizin ve eski ticaret eklentileri sıklıkla PHP şablon geçersiz kılmalarıyla gelir. Birçoğunun artık blok karşılığı var; birçoğunun yok.
• Site bitmiş ve çalışıyor. Beş yıllık birikmiş özelleştirmeye sahip bir temanın bloka giden bir yükseltme yolu yoktur, yalnızca yeniden yapımı vardır. “Daha yeni yaklaşım bu” bir iş gerekçesi değildir.
• Sizden başka kimse düzenlemeyecek. Site Editor’ın asıl faydası denetimi geliştirici olmayanlara devretmektir. Ortada geliştirici olmayan kimse yoksa, kimsenin kullanmadığı bir fayda için bedel ödüyorsunuz demektir.

Melez orta yol

Klasik bir tema theme.json ekleyerek global stil sistemini, renk ve boşluk ön ayarlarını ve tutarlı editör stillendirmesini alabilir — PHP şablonlarını ve Özelleştirici’yi korurken. WordPress buna blok tema demez ve Site Editor kullanılamaz kalır, ancak tasarım sistemi faydasının çoğunu işin çok küçük bir kısmıyla elde edersiniz.

Zaten büyük ölçüde çalışan mevcut bir site için doğru ilk hamle genellikle budur. theme.json ekleyin, paletinizi ve boşluklarınızı tanımlayın, yerini aldığı CSS’i silin ve gerisini hâlâ isteyip istemediğinize bakın.