WordPress 7.1 icin Tasarim Sistemi Temalandirma Onerisi

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. Bu son kısım koddan da ö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ınızda 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. Herkesin kendi tekerleğini yeniden icat etmesi bitsin diye.

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

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ğinizde 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ü.

WordPress ve WooCommerce insanları için ne anlama geliyor

Özel yönetim sayfaları yazıyorsanız — 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ğiniz var. Stilleri satır içine gömüp dua edersiniz. Kararsız, özel --wp-components-* takma adlarına yaslanıp hiçbir şey kaymasın diye umarsınız. Ya da @wordpress/components‘i içeri alır ve beraberinde gelen CSS-in-JS yükünü sırtlanırsınız. 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ınızda doğrudan referans verebilirsiniz. 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ız. React tabanlı yönetim yüzeyleri için ThemeProvider size kapsamlı bir geçersiz kılma veriyor — eklentinizin kendi bölümünü diğer sayfalara stil sızdırmadan temalayabilirsiniz.

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. Belirteçler standarda uygunsa taşınabilir olur — aynı belirteç kümesini Figma’ya, bir statik sitenin tasarım sistemine, bir mobil uygulamaya bağlayıp her değişkeni elle eşleştirmeden görsel bütünlüğü koruyabilirsiniz. WordPress’in yıllardır ihtiyaç duyduğu ama nadiren hakkını verdiği bir olgunluk bu.

Yerinizde ne yaparım (ve ne yapmam)

Öneriyi bu hafta baştan sona okuyun. 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 bildiriminiz varsa Make yazısının altına şimdi yazın, dondurmadan sonra değil.

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

Üretimdeki yönetim arayüzünüzü birleşmemiş çekirdek API’lere karşı yeniden yapılandırmayın. Ö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ı bekleyin, göçü ondan sonra gerçek bir sürüme sokun.

WooCommerce eklentileri için özellikle: hâlihazırda gelişmekte olan Woo Yetenekleri ve ayarlar SDK’sı işiyle koordine olun. Eklentiniz kendi yönetim arayüzünü sunuyorsa temalandırma göçünü yetenek açımı ve ayarlar SDK’sı benimsemesi ile aynı döngüde planlayın. Üçü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.