WordPress 7.1 icin Tasarim Sistemi Temalandirma Onerisi

🇬🇧 English: Read this in English →

Birkaç yılda bir birileri WordPress yönetim panelinin altına düzgün bir tasarım sistemi koymayı deniyor ve her seferinde iş “ilkesel olarak hemfikiriz” aşamasında takılıp kalıyor. Dün Make/Core’da yayımlanan öneri bundan farklı. Gerçek bir API yüzeyi olan, gerçek bir stil dosyası olan, gerçek bir React bileşeni olan ve hedef sürümü açıkça belirtilmiş bir birleştirme önerisi. Ve bu son kısım, koddan bile önemli.

Bu tartışmaları uzun süredir izliyorum, o yüzden dikkatli konuşayım: bu bir yeniden tasarım değil. Yarın tarayıcında wp-admin’in görünüşünde hiçbir şey değişmeyecek. Bu önerinin yaptığı şey, ileride yeniden tasarım işi başladığında eklenti geliştiricilerin, WooCommerce eklentilerinin ve özel yönetim sayfalarının hepsinin aynı belirteç sistemini miras alabilmesi için altyapıyı yerine koymak. Yani herkesin kendi tekerleğini yeniden icat etmesi bitsin diye.

WordPress için profesyonel iş çıkarıyorsan buna 5.0’daki blok düzenleyiciye baktığın gözle bak: öneriyi şimdi oku, API’nin biçimini anla ve kendi özel yönetim yüzeylerinin nereye bağlanacağını çıkar.

Aslında yeni olan ne

7 Temmuz 2026’da Andrew Duthie, Make/Core’da Birleştirme Önerisi: Tasarım Sistemi Temalandırma yazısını yayımladı. Hedef WordPress 7.1 (Beta 1 için 15 Temmuz, genel sürüm 19 Ağustos). Öneri, aylardır Gutenberg deposu üzerinden ilerleyen çalışmayı toparlayıp çekirdekten yönetim panelinin temalandırma birincili olarak kabul etmesini istiyor.

Birleşirse üç somut şey iniyor:

• Çekirdekte kayıtlı yeni bir stil sayfası tutamağı, wp-theme, önceden derlenmiş bir design-tokens.css ile geliyor. Her yönetim sayfasında ve düzenleyici iframe’inin içinde kuyruğa alınıyor, böylece :root belirteç bloğu hiçbir bileşen çizilmeden önce hazır oluyor.
• Çekirdekte kayıtlı yeni bir JavaScript modülü, yine wp-theme, eklentilerin yönetim panelinin belirli bir bölümündeki varsayılan temayı genişletmesine veya geçersiz kılmasına olanak veren React ThemeProvider bileşenini dışa açıyor.
• Renk, tipografi, kenarlık ve yükseklik konularını kapsayan, W3C Design Tokens Community Group belirtimine uygun kapsamlı bir tasarım belirteci kümesi. Buna ek olarak bir vurgu ile bir arka plan tohum renginden renk rampaları üreten bir araç da geliyor.

Kaynak koddaki iş gerçek. Marco Ciampini’nin yazdığı Gutenberg PR #78664 zaten 16 Haziran 2026’da birleşti — bu, önceden derlenmiş bir stil dosyası göndererek belirteç varsayılanlarını çalışma zamanı <ThemeProvider> sarmalayıcısından ayıran, eski --wp-components-* takma adlarını yeni belirteçleri işaret edecek biçimde güncelleyen, isRoot özelliğini ve iframe’ler arası kullanım örüntülerini belgeleyen değişiklik. Aynı PR ThemeProvider‘ı @wordpress/theme paketinin genel dışa aktarımı olarak da açıyor.

Gutenberg 23.5, 1 Temmuz 2026’da yayımlandı ve boru hattı çalışmaya devam etti: ThemeProvider’a köşe yuvarlaklığı hazır ayarları (PR #78816), boyut belirteçlerine Figma kapsamları (PR #79032), marka ve hata etkileşim renkleri için devre dışı varyantlar (PR #79124), bg/fg belirteç gruplarının background/foreground olarak yeniden adlandırılması (PR #79098) ve tasarım belirteçleri için bakımcı rehberi (PR #79157). Yani bu bir vakumda hazırlanan öneri değil; kod haftalardır eklentide gerçek şekilde ilerliyor.

Önerinin kapsamı dürüst çizilmiş. 7.1’deki varsayılan tema, bugünkü yönetim paneliyle görsel olarak hizalı kalıyor — sürpriz bir kabuk değişikliği yok. Kullanıcıya dokunan tek somut kazanç Site Düzenleyici’ye kullanıcının renk şemasının uygulanabilmesi ve bunu yeni temalandırma katmanı temiz biçimde mümkün kılıyor. Geri kalan her şey — tüm yönetim ekranlarında daha geniş benimsenme, daha derin özelleştirme, karanlık mod — 7.1 sonrası yol haritasına açıkça bırakılmış.

Bir adım geri çekildiğinde bu, Anne McCarthy’nin 19 Haziran 2026’da yayımladığı 7.1 yol haritasına ve Duthie’nin kendi açtığı uzun soluklu Tasarım Sistemi genel bakış konusuna #71196 doğrudan bağlanıyor. Her ikisi de bunu Faz 3 yönetim yeniden tasarımının altyapısı olarak konumluyor: paylaşılan belirteçler, bileşen bazlı arayüz, kullanıcı renk şemaları ve ileride karanlık mod için daha iyi temalandırma desteği, ve daha az CSS-in-JS yükü.

Her aracın kendi rengi vardı, ve bu bir kâbustu

Önerinin en çok dikkatimi çeken satırı, belirteçlerin W3C DTCG belirtimine uyması — yani taşınabilir olması. Aynı belirteç kümesini Figma’ya, statik bir sitenin tasarım sistemine, bir mobil uygulamaya bağlayıp her değişkeni elle eşleştirmeden görsel bütünlüğü koruyabilmen. Bu tanıdık geldi, çünkü ben bir zamanlar bunun tam tersini yaşadım.

1990’larda bir tasarımı Aldus FreeHand’de kurar, sonra baskıcının istediği çıktı için CorelDRAW’a ya da başka bir araca taşımak zorunda kalırdın. Her araç rengi kendi dilinde konuşurdu; birinde tertemiz duran bir kurumsal kırmızı, ötekinde bir tık kayardı, çünkü ortada paylaşılan tek bir renk sözleşmesi yoktu. Logoyu yeni araçta baştan çizdiğin, tramları elle yeniden ayarladığın çok oldu. Kaybettiğin şey zaman değildi sadece; tutarlılıktı. Aynı markanın üç farklı çıktısı üç ayrı elden çıkmış gibi dururdu.

İşte DTCG’nin çözmeye çalıştığı sorun tam olarak bu, otuz yıl sonrasının kılığında. Belirteci tek bir standart kaynakta tanımlarsın, ve Figma da, wp-admin de, mobil uygulaman da onu aynı okur. Ben o “her araçta baştan çiz” cehennemini yaşamış biri olarak, bu satırın neden mühim olduğunu kemiklerimde biliyorum. WordPress’in yıllardır ihtiyaç duyduğu ama nadiren hakkını verdiği bir olgunluk bu.

WordPress ve WooCommerce insanları için ne anlama geliyor

Özel yönetim sayfaları yazıyorsan — bir eklenti için ayarlar ekranı, bir müşteri için özel gösterge paneli, bir WooCommerce eklentisi paneli, bir yayın akışı için iç araç — bugün üç seçeneğin var. Stilleri satır içine gömüp dua edersin. Kararsız, özel --wp-components-* takma adlarına yaslanıp hiçbir şey kaymasın diye umarsın. Ya da @wordpress/components‘i içeri alır ve beraberinde gelen CSS-in-JS yükünü sırtlanırsın. Açık konuşayım, hiçbiri iyi yaşlanmıyor.

Kararlı bir belirteç katmanı bu hesabı değiştiriyor. wp-theme çekirdek kayıtlı bir tutamak olduğunda, onu bağımlılık olarak kuyruğa alıp var(--wp-...) belirteçlerini kendi stil dosyalarında doğrudan referans verebilirsin. Kullanıcının renk şemasını, köşe yuvarlaklığı tercihlerini ve gelecekteki karanlık mod işini yeniden yazmadan takip edeceğini bilerek yaparsın. React tabanlı yönetim yüzeyleri için ThemeProvider sana kapsamlı bir geçersiz kılma veriyor — eklentinin kendi bölümünü diğer sayfalara stil sızdırmadan temalayabilirsin.

Bu, özellikle WooCommerce için göründüğünden daha kritik. Woo son dönemde istikrarlı bir yönetim tarafı çalışması yayımlıyor — blok tabanlı e-posta düzenleyicisi, 10.9.2’de güncelleme sırası ölümcül hatalarına yol açan ayarlar SDK’sı, 10.9’da varsayılan hale gelen Sepet ve Ödeme blokları. Bu yüzeylerin tamamı kendi görsel geleneğini taşıyor. Paylaşılan bir belirteç katmanı, bu ekosistemin bir gün üç farklı ürünü birbirine yamamış gibi görünmemesinin tek yolu.

DTCG uyumu benim asıl ilgilendiğim sessiz parça — biraz önce neden olduğunu anlattım. Belirteçler standarda uygunsa taşınabilir olur, ve taşınabilirlik bir markayı yüzeyler arasında tutarlı tutmanın tek dürüst yolu.

Senin yerinde ne yaparım (ve ne yapmam)

Öneriyi bu hafta baştan sona oku. Adlar 15 Temmuz Beta 1’de donuyor — yani bugünden bir hafta sonra. wp-theme tutamak adı, belirteç adlandırması veya ThemeProvider API yüzeyi hakkında somut geri bildirimin varsa Make yazısının altına şimdi yaz, dondurmadan sonra değil.

Gutenberg 23.5’i bir hazırlık sitesine kur — üretim değil — ve baktığın her özel yönetim sayfasını tarayıcı denetleyicisiyle incele. Şu anda hangi CSS özel özelliklerini okuduğuna bak. Özel --wp-components-* değişkenlerini tüketiyorsan nereleri tükettiğini not et; onların ömrü sayılı. Her birini yeni kümedeki karşılık tasarım belirtecine eşle. Henüz göç etme. Sadece eşlemeyi çıkar.

Üretimdeki yönetim arayüzünü birleşmemiş çekirdek API’lere karşı yeniden yapılandırma. Öneri Beta 1’den önce hâlâ biçim değiştirebilir ve @wordpress/theme‘den içeri aktarma yolu ile küresel wp.theme arasındaki tam kararın kilitlendiği söylenemez. 7.1’in 19 Ağustos’ta yayınlanmasını bekle, göçü ondan sonra gerçek bir sürüme sok.

WooCommerce eklentileri için özellikle: hâlihazırda gelişmekte olan Woo Yetenekleri ve ayarlar SDK’sı işiyle koordine ol. Eklentin kendi yönetim arayüzünü sunuyorsa temalandırma göçünü yetenek açımı ve ayarlar SDK’sı benimsemesi ile aynı döngüde planla. Üçünü birlikte yapmak tek gözden geçirme turu. Ayrı ayrı yapmak üç.

Yapmayacağım bir şey: bunu “yeni WordPress tasarımı” pazarlama hikâyesine çevirmek. Değil. Bu, çekirdeğin nihayet birincilleri doğru yere koyup — yeni tasarım çalışması hâlâ görünür olmaktan yıllar uzakta olsa da — üstüne inebileceği kararlı bir zemin bırakması. Bu ayrım işin bütün özü.

Yirmi yıldır süren örüntü bu: WordPress’in çığ gibi büyüdüğü an gürültülü sürümlerle değil, geri kalan her şeyin üstüne oturacağı sessiz birincillerle geliyor.