WordPress tam site duzenleme: 2026'da Uygulayici Rehberi

WordPress tam site duzenleme: 2026'da Uygulayici Rehberi

WordPress tam site duzenleme artık erken benimseyenlerin meselesi değil. WordPress 6.9 verileri, yeni site kurulumlarının %68'inin blok tabanlı mimariye varsayılan olarak geçtiğini gösteriyor. Müşteri için klasik PHP temaları teslim eden serbest çalışanlar ve ajanslar için soru artık FSE'yi benimseyip benimsememek değil; mevcut üretim iş akışlarını bozmadan bunu nasıl yapacaklarını bulmak.

Bu folio mekanizmaları ele alır, tanıtım materyallerini değil. WordPress 6.8 ve 6.9 çalıştıran gerçek müşteri sitelerinde test edilmiştir.

FSE'nin Neyin Yerini Aldığı, Neyi Koruduğu

Full Site Editing, WordPress'in şablon sistemini PHP'den blok tabanlı bir düzenleme katmanına taşır. functions.php kaybolmaz; index.php kaybolur. Klasik bir temada şablon hiyerarşisi PHP dosyalarıyla ifade edilirdi: single.php, archive.php, 404.php. Blok temada bu dosyaların her biri, templates/ klasöründe yaşayan HTML tabanlı blok işaretleme dosyasıyla karşılık bulur.

wp_head() ve wp_footer() hâlâ çalışır; sadece artık PHP şablonunda değil, functions.php aracılığıyla kuyruğa alınmış betikler ve stiller üzerinden beslenir. Gutenberg API'leri de hâlâ mevcuttur: blok kaydı, blok varlıkları, REST uç noktaları değişmez. Değişen şey, şablon katmanının nasıl oluşturulduğudur.

Pratik etkisi şudur: bir müşteri, sitenizi canlıya aldıktan sonra bir şablonu değiştirmek istediğinde artık FTP ve PHP editörüne ihtiyaç duymaz. Site Editörü'nde bunu yapabilir. Bu, kötüye kullanımın da kapısını açar; ama doğru kurgulandığında son derece güçlüdür. Müşteri teslim iş akışınızı yeniden düşünmenizi gerektirir, ancak PHP bilgisi gerektirmeden şablon değişikliği yapılabilmesi, pek çok ajans için işin doğasını değiştiriyor.

Minimal Blok Tema Anatomisi: Sadece Üç Dosya

Bir blok temanın çalışması için gereken minimum şey şudur:

• style.css: Tema başlığını içerir (Author, Version, Template vb.)

• templates/index.html: Tek zorunlu şablon

• theme.json: Tema yapılandırması

Bu üç dosyayla WordPress, sitenizi bir blok tema olarak tanır ve Site Editörü'ne erişim açılır. Uygulamada bunun yanına bir functions.php, birkaç şablon parçası ve bir patterns/ klasörü eklenir; ancak minimum bu üç dosyadır.

Bu yapının size söylediği şey önemlidir: FSE, PHP'yi ortadan kaldırmaz. Şablon katmanını HTML blok işaretlemesine kaydırır. Şablonlarınızı doğrudan dosyalarda tutabilir ya da Site Editörü üzerinden düzenlenen sürümlerin veritabanına kaydedilmesine izin verebilirsiniz. Uygulayıcılar için bu tercih, uzun vadeli bakım açısından belirleyicidir. Dosya tabanlı şablonlar sürüm kontrolüne girer; veritabanına kaydedilen sürümler ise güncelleme süreçlerinde dikkat gerektirir.

Create Block Theme eklentisi bu geçişi kolaylaştırır: mevcut aktif blok temasını alır, Site Editörü'nde yapılan değişiklikleri tema dosyalarına yazar ve dışa aktarır. Ajans ortamında çalışıyorsanız bu eklenti, iş akışının ayrılmaz bir parçası haline gelir.

Site Editörü'nde Beş Alan ve Tek Hiyerarşi (WP 6.9)

WordPress 6.9'daki Site Editörü beş ana alandan oluşur:

1. Sayfalar: Bireysel sayfa şablonlarını düzenleme

2. Şablonlar: Index, tekil gönderi, arşiv, 404 vb.

3. Şablon Parçaları: Header, footer, sidebar

4. Kalıplar (Patterns): Yeniden kullanılabilir blok grupları

5. Stil: Global renk, tipografi, boşluk değerleri

Bu beş alan bir hiyerarşiyle çalışır. Stil en genelden özele doğru iner: global stiller, blok stilleri, blok varyantları. Bir bölümde renk değiştirdiğinizde, aynı renkle tanımlanmış her bloğu etkilersiniz. Bunu bilmeden üretim sitesinde düzenleme yapmak, beklenmedik görsel değişikliklere yol açar.

Bu hiyerarşi, özellikle müşteriye teslim aşamasında kritik hale gelir. Hangi değişikliğin nereye etki ettiğini bilmeden çalışmak, saatlik hata ayıklama oturumlarına davetiye çıkarır. Site Editörü'nü ilk kez kullanan bir müşteriyle çalışıyorsanız, global stiller panelini kilitlemek için Pattern Overrides ve theme.json kısıtlamalarını birlikte kullanmayı düşünün.

Query Loop Bloğu ve theme.json: PHP Olmadan Döngü, JSON ile Tasarım Kontrolü

Query Loop bloğu, WP_Query'nin görsel editördeki karşılığıdır. Gönderi türü, taksonomi, yazar, tarih aralığı ve özel sorgu değişkenlerine göre filtreleme yapılabilir. PHP yazmadan, bir arşiv şablonu oluşturmanıza izin verir.

Sınırlaması gerçektir: karmaşık meta sorguları ve JOIN gerektiren işlemler hâlâ PHP gerektirir. Bir müşteri sitesinde posts_clauses filtresiyle bir şey yapıyorsanız, Query Loop tek başına yeterli olmayacaktır. Ancak çoğu listeleme sayfası için; blog, portfolyo, ürün arşivi; bu blok yeterlidir. WP 6.9'da eklenen önbellekleme iyileştirmeleriyle performans da belirgin biçimde artmıştır.

theme.json v3, WP 6.7 ile tanıtıldı ve tema denetimini kapsamlı biçimde genişletti. Renk paleti, tipografi ölçeği, boşluk değerleri, kenarlık yarıçapları ve gölgeler artık doğrudan theme.json içinde tanımlanır. Bir müşteriye "bu renkler asla değişmeyecek" diyorsanız, bunu kod düzeyinde kilitleyebilirsiniz.

Uygulamada şu anlama gelir: settings.color.palette ile ana renkleri tanımlarsınız, settings.color.custom: false ile yeni renk eklemeyi engellersiniz. Müşteri Site Editörü'nü açtığında yalnızca sizin belirlediğiniz palet seçenekleri görünür. Bu, ajansların uzun süredir sayfa oluşturuculardan beklediği bir özelliktir ve artık yerel olarak mevcut.

Pattern Overrides: Müşteri Teslimatında 2026'nın Kilit Özelliği

Pattern Overrides, WP 6.8'de Block Bindings API'si üzerine inşa edildi ve müşteri teslimatı iş akışını köklü biçimde değiştirdi.

Uygulamada şu anlama gelir: bir kalıp oluşturursunuz, örneğin bir fiyat kartı veya hizmet bölümü, bazı blokları düzenlenebilir, diğerlerini kilitli olarak işaretlersiniz. Müşteri kalıbı bir sayfaya ekler; yalnızca işaretlediğiniz alanları düzenleyebilir. Arka planı, düzeni ve tipografi hiyerarşisini korur.

Bu özellik, önce ajans perspektifinden şöyle okunur: müşteri tesliminde fark oluşturan bir mekanizma. Sayfa oluşturucuların "kilitli bölümler" olarak sattığı şey, şimdi yerel bir WordPress özelliğidir. Elementor veya Divi gerektirmez.

Kullanım adımları:

1. Kalıbı patterns/ klasöründe tanımlayın ve Synced olarak işaretleyin

2. Her düzenlenebilir bloğu Block Bindings panelinden core/pattern-overrides kaynağına bağlayın

3. Kalıbı müşterinin sayfasına ekleyin

Kalan her şey kilitlidir. Müşteri içeriği değiştirir, tasarım bütünlüğünü bozmaz. Bir kalıp birden fazla sayfada kullanılıyorsa, merkezi sürümü güncellemek tüm sayfaları etkiler. Belirli sayfa örneklerine özgü içerikler ise override mekanizmasıyla o sayfaya özgü kalır.

Bu, özellikle kurumsal müşteri sitelerinde; aynı şablonun onlarca sayfa boyunca kullanıldığı durumlarda; önemli bir bakım kolaylığı sağlar. Ajans olarak bir fiyat değişikliği geldiğinde yalnızca kalıbı güncellersiniz: değişiklik kalıbı kullanan tüm sayfalara anında yansır. Müşteriyle "neden sadece bu sayfada güncelledi" tartışması ortadan kalkar.

Üretimde Hâlâ Kırılan Şeyler

Dürüst bir değerlendirme.

Şablon veritabanı geçersiz kılması. Bir şablonu Site Editörü'nde düzenlediğinizde, WordPress bu sürümü veritabanına kaydeder. Tema güncellemesi yaparsanız, veritabanındaki sürüm dosyadaki sürümü geçersiz kılar. Müşteri, sitenizin güncellemeden sonra neden farklı göründüğünü anlayamazsa, bu mekanizma suçludur. Create Block Theme eklentisiyle değişiklikleri tema dosyalarına geri yazarak bu sorunu çözebilirsiniz; ama süreç manuel müdahale gerektirir.

RTL boşlukları. Arapça veya İbranice içerik üzerinde çalışıyorsanız, birçok blok hâlâ LTR mantığıyla davranıyor. Özellikle Cover ve Group bloklarında. Bu düzeltmeler çekirdekte yavaş ilerliyor; bazı RTL düzeltmeleri için hâlâ özel CSS gerekiyor. WP 6.9 bu alanda iyileştirmeler getirdi, ancak eksiksiz RTL desteği henüz sağlanamadı.

Derin iç içe DOM yapısı. Karmaşık düzenler, Gutenberg çıktısında derin iç içe div yapılarına yol açar. Bu, erişilebilirlik denetimleri ve Core Web Vitals puanları için sorun yaratabilir. Özellikle birden fazla Group bloğunun iç içe geçtiği düzenlerde DOM derinliği ciddi boyutlara ulaşabilir.

Çekirdek blok CSS yükleme davranışı. Bazı bloklar, sayfada kullanılıp kullanılmadığına bakılmaksızın CSS dosyalarını evrensel olarak sıralar. Optimize edilmiş bir performans bütçesiyle çalışıyorsanız, bu fazladan yük fark edilir. Bu davranış WP 6.8'de kısmen iyileştirildi, ancak sorun tamamen çözülmedi.

Kilitli kalıp düzenleme akışı. Pattern Overrides mükemmel çalışır; ancak kilitli bir kalıbı kök düzeyinde (şablon veya kalıp editörünün kendisinde) düzenlemek, müşterilerin zaman zaman karıştırdığı iki ayrı akışı gerektirir. Eğitim materyalleri bu ayrımı net biçimde açıklamalıdır.

FSE Üretim Çalışması için Bilmeye Deger Araçlar

Create Block Theme eklentisi: Aktif bir blok temasını kaydeder ve dışa aktarır. Site Editörü üzerinden yapılan değişiklikleri tema dosyalarına geri yazmak için temel araçtır. Birden fazla geliştirici üzerinden çalışıyorsanız, bu eklentinin getirdiği dosya tabanlı sürüm kontrolü iş akışı kritik öneme sahiptir.

Gutenberg eklentisi: Kararlı WP sürümüne göre 4-6 hafta önce çekirdek özelliklerine erişim sağlar. Üretim için değil; geliştirme ortamında gelen değişiklikleri takip etmek ve müşteri projelerine hazırlanmak için kullanışlıdır.

Theme JSON Generator: theme.json yapılandırmasını arayüz üzerinden oluşturmak için kullanılabilir; özellikle tipografi ölçeği kurmak ve renk sistemini belgelemek için işe yarar. Çıktısını doğrudan tema klasörünüze kopyalayabilirsiniz.

WP Playground: WordPress'i tarayıcıda çalıştırır, kurulum gerektirmez. Yeni FSE özelliklerini yerel bir ortam kurmadan test etmek ve müşterilere canlı demo göstermek için idealdir.

Noonwp'nin Pattern Forge aracı, kalıp kütüphanelerini doğrudan Site Editörü'ne entegre eder ve Scribe planından ($12/ay) itibaren kullanılabilir. RTL Concordance modülü, çift yönlü içerik sitelerinde blok hizalama sorunlarını otomatik olarak tespit eder ve üretimde saatler kazandırır.

Uygulamada görmeden satın almayın; ama gerçek bir müşteri sitesinde deneyin. FSE'nin 2026 durumu, benimsenmesi için yeterince kararlı; ancak üretim sürtünmesini görmezden gelecek kadar kusursuz değil. Gerçek bir müşteri sitesinde test edin: fark orada ortaya çıkar.

Sik Sorulan Sorular

Klasik PHP temalarım hâlâ WordPress 6.9'da çalışıyor mu? Evet. WordPress geriye dönük uyumlulukla tasarlanmıştır. Klasik temalar tam işlevselliğini korur. FSE'ye geçiş isteğe bağlı olup zaman içinde aşamalı biçimde yapılabilir.

Bir blok teması, bir sayfa oluşturucuyla (Elementor, Divi) birlikte kullanılabilir mi? Teknik olarak mümkündür, ancak genellikle önerilmez. Elementor ve benzerleri kendi şablon sistemlerini getirir ve bunlar FSE şablon hiyerarşisiyle çakışabilir. En temiz deneyim, ikisinden birini seçmekle gelir.

Pattern Overrides, çoklu dil sitelerinde nasıl çalışır? Aynı kalıbın birden fazla dil sürümü için ayrı Pattern Override örnekleri oluşturmanız gerekir. WPML ve Polylang entegrasyonu bu senaryolarda hâlâ manuel ayar gerektirir; otomatik senkronizasyon eklentiye özgü yapılandırma istiyor.

theme.json tüm tasarım kararlarını kapsar mı? Hayır. theme.json, global renk, tipografi ve boşluk değerlerini kapsar. Blok bazında özel stiller, block.json ve bağlı varlık dosyalarıyla tanımlanır. Bazı ayrıntılar hâlâ geleneksel CSS dosyalarına gönderme yapıyor.

Site Editörü'ndeki şablon değişiklikleri tema güncellemelerini ezer mi? Evet, bu gerçek bir üretim riskidir. Site Editörü'nde düzenlenen şablonlar veritabanına kaydedilir ve tema dosyası güncellemelerini geçersiz kılar. Create Block Theme eklentisiyle bu değişiklikleri tema dosyalarınıza geri yazarak sorunu çözebilirsiniz.

Geliştiriciler için FSE öğrenme eğrisi ne kadar dik? PHP şablon hiyerarşisi bilen bir geliştirici için, blok tema mantığını kavramak birkaç günlük yoğun pratik gerektirir. Asıl güçlük, FSE'nin teknik mekaniklerini öğrenmek değil; müşteri teslim iş akışlarını bu yeni modele göre yeniden kurgulamaktır.