WordPress 7.1 40 Piksellik Bileşen Varsayılanını Kalıcı Yapıyor

🇬🇧 English: Read this in English →

WordPress’te henüz “components” paketi bile yokken @wordpress/components üstüne yönetim ekranları kuruyordum. Tasarım sistemi altımdan her kaydığında müşterilerden aynı soruyu alırım: eklentimi bu sefer kıracak olan bu mu? Yıllardır aynı soru, yıllardır aynı içgüdüsel gerginlik.

Bu hafta yine o haftalardan biri, ama cevap ilk defa sıkıcı. WordPress 6.4’ten beri ağır ağır yürüyen 40 piksellik kontrol yüksekliği, sonunda 7.1’de kalıcı varsayılan oluyor. Kodun yıllar önce tercih ettiyse hiçbir şey değişmiyor. Etmediyse fark edeceksin — ve API yüzeyi sabitlenmeden önce düzeltmek için elinde tek bir Beta döngüsü var.

Fiilen ne indi, sürüm ekibi işi neden böyle götürdü, ve bir müşteri kod tabanında bu hafta hangi denetimleri yapardım — hepsi aşağıda.

Asıl yeni olan ne

__next40pxDefaultSize tercihe bağlı özelliği, çekirdek bileşenlerin ilk dalgasında artık sert kullanımdan kaldırıldı. Ryan Welcher’ın WordPress Developer Blog’da yayımladığı Temmuz 2026 geliştirici derlemesi en açık özet ve Gutenberg 23.5’te değişikliği alan on bileşeni listeliyor — bu, WordPress 7.1’in içine geri taşınan eklenti sürümü: TextControl, BoxControl, BorderControl, FontSizePicker, RangeControl, ComboboxControl, ToggleGroupControl, UnitControl, FormTokenField ve CustomSelectControl.

Buradaki “sert kullanımdan kaldırma” ifadesi net. Özellik tip imzasından silinmedi — hâlâ derleniyor, mevcut çağrılar hata fırlatmıyor. Ama çalışma zamanı işleyicisi gitti. 40 piksellik boyut artık varsayılan stillere gömülü, özellik ise işlevsiz bir kabuk. TextControl değişikliği Gutenberg PR #79386, mirka tarafından 23 Haziran 2026’da birleştirildi — PR açıklaması özelliğin “artık işlevsel bir etkisi olmadığını” ve dış uyumluluk için kullanımdan kaldırılmış bir tip kabuğuyla değiştirildiğini açıkça söylüyor. BoxControl karşılığı PR #79419, ertesi gün birleşti; özelliği o bileşenin genel API’sinden kaldırıyor ama içerideki UnitControl ve RangeControl örneklerine, o ilkel bileşenler kendi kullanımdan kaldırma döngülerini bitirene kadar hâlâ iletiyor.

Uzun bir yürüyüştü. 40 piksellik varsayılan Ekim 2023’teki WordPress 6.4 bileşenler geliştirici notunda duyurulmuş, temaların ve eklentilerin kendi takvimlerinde geçebilmesi için geçici bir tercih özelliğiyle sarmalanmıştı. Asıl takip meselesi planı çizdi: özelliği tanıt, her şey göç etsin, sonra varsayılanı değiştir ve bayrağı emekli et. Hiç tercih etmeyen tüketiciler 36 piksellik varsayılanda kaldı ve 6.7’den sonra yumuşak kullanımdan kaldırma uyarıları aldı. 7.1 dalgası, özelliğin gerçekten anlamsız hale gelmesinden önceki son durak.

İki destekleyici mekanik önemli. Birincisi, @wordpress/eslint-plugin içindeki components-no-missing-40px-size-prop ESLint kuralı, tercih bayrağını geçmeyen her bileşen kullanımını zaten işaretliyordu. Yapın WordPress ön ayarı altında temizse, büyük ihtimalle işi çoktan bitirmişsindir. İkincisi, Gutenberg’in ana dalı 15 Temmuz 2026’da yayınlanan Beta 1’de wp/7.1 dalına sabitlendi — 7.1 sürüm partisi takvimine göre. 19 Ağustos için API yüzeyi, bugün Beta 1’de olanın aynısı. Bu bileşen kümesi için bu döngüde artık “yumuşaktan serte” sürprizler olmayacak.

Dört piksel neden bu kadar önemli

Şunu duyar gibiyim: dört piksel de ne ki? Açık konuşayım, tek başına bir kontrolde hiçbir şey. Mesele tek kontrol değil, birikim. Bir ayar ekranında alt alta on kontrol varsa, dört piksel çarpı on eder kırk piksel — birden ekranın altındaki Kaydet düğmesi katlanmanın altına iniyor, ya da yapışkan konumlandırdığın başlık son satırın üstüne biniyor. Dikey ritim böyle bozulur: tek bir yerde değil, toplamda.

Ve bu değişikliğin arkasındaki asıl argüman estetik değil, erişilebilirlik. 40 piksel, kullanıcının gözünü kısmasına ya da parmağını nişan almasına gerek kalmadan WCAG dokunma hedefi rehberine daha rahat uyan bir yükseklik. Yani bu, birinin bir sabah “36 çok mu ince acaba” diye verdiği keyfi bir karar değil — yıllara yayılmış, gerekçesi belgeli bir olgunlaşma. Ben olsam bu yüzden ona direnmezdim; akıntının yönü belli.

WordPress ve WooCommerce dünyasında bu neden önemli

Ajans eklentilerinin çoğu en az bir ayar ekranı çiziyor ve bu ekranların çoğu aynı bir avuç kontrolün üstünde kurulu. TextControl kaçınamayacağın olan. RangeControl ve UnitControl neredeyse her “boşluk”, “font boyutu” ya da “kesme noktası” panelinde çıkıyor. SelectControl varyantları ve ComboboxControl, REST API ile konuşan her açılır menünün sahibi. 2022 veya 2023’te bir eklenti kurup arayüze o günden beri hiç dokunmadıysan, test ettiğin düzen 36 piksel yüksekliğindeydi. 7.1 altında 40. Dört piksel çok gibi durmuyor — ta ki sıkı dikey ritmi olan iki sütunlu bir ızgaraya ve Y koordinatı CSS ile sabitlenmiş bir Kaydet düğmesine çarpana kadar.

WooCommerce aynı saatte. WC_Settings_Page, yeni Ayarlar Arayüzü çerçevesi ya da Ödemeler/Kargo yöntemi ekranlarında çizim yapan uzantı ekiplerinin hepsi aynı bileşenleri tüketiyor. Woo 11.0 ön sürüm notları zaten kullanımdan kalkan dependency-group kuralının yerine geçen import/order ile ilgili ayrı bir ESLint kuralı değişikliğini işaret etti — hâlâ eski yapılandırmaya sabitli ekiplerin sürekli tümleştirme boru hattını kırıyor. İki lint kuralı göçü artı canlı bir bileşen varsayılan değişikliği, kimse önden uyarmadıysa Pazartesi sabahını yiyecek türden küçük bir yığın.

Daha geniş sinyal şu: Gutenberg’in tasarım sistemi katmanı sonunda gerçek bir tasarım sistemi gibi davranıyor. 8 Temmuz’da işlediğimiz tasarım sistemi temalandırma birleştirme önerisi token borusunu indiriyor. Bu 40 piksellik varsayılan da boyut tarafındaki son tercih bayrağını çeviriyor. İkisi birlikte, eklenti yazarlarının 6.4’ten beri istediği şey: öngörülebilir varsayılanlar, tek bir temalandırma katmanı, üstüne inşa edilecek tek bir kararlı bileşen API’si.

Ben ne yapardım (ya da yapmazdım)

Yönetim arayüzü çizen her eklenti ya da temada, şu sırayla dört tur at — WordPress 7.1 Beta 1 ve Gutenberg 23.5 yan yana kurulu bir hazırlık ortamında.

1. Özelliği tara. Kod tabanında __next40pxDefaultSize ara. Her sonucu bugün yerinde bırakmak güvenli — özellik hâlâ tipli ve hâlâ geçerli — ama her biri geleceğin ölü kodu. En düşük WordPress sürümünü 7.1’e çıkaran aynı PR’de temizlemeyi planla.
2. ESLint kuralını kod tabanında çalıştır. @wordpress/eslint-plugin henüz devDependencies içinde değilse ekle ve önerilen ön ayarı aç. Etkilenen listedeki bir kontrolü çizen ve 40 piksellik varsayılandan haberdar olmayan her bileşen işaretlenecek. Özellik varsa kaldırıp yoksa düzeni tekrar kontrol ederek onar.
3. Her ayar ekranında görsel tur. Kimsenin yapmak istemediği ama her hatayı yakalayan tur bu. Eklentideki her yönetim sayfasını 1x ve 2x’te aç, eklenen kontrol başına dört pikselin ızgaranı bozup bozmadığına bak. Sık başarısızlıklar: kırpılan yan panel şeritleri, son satırla örtüşen yapışkan Kaydet düğmeleri, karışık kontrol yüksekliği olan tablolar ve etiketlerin girdilerle hizasının kaçtığı iki sütunlu düzenler.
4. Kullanımdan kaldırma uyarısı denetimi. SCRIPT_DEBUG‘ı aç, sahip olduğun her düzenleyici ve yönetim ekranında tarayıcı konsolunu aç ve Gutenberg kullanımdan kaldırma çalışma zamanının kaydettiği her şeyi kopyala. Yığın izi bileşeni ve çağıran dosyayı adlandırır. Onar ya da bildir, görmezden gelme.

İki şeyi yapmazdım. Birincisi, 36 piksellik boyutu CSS geçersiz kılmalarıyla zorla geri getirmeye çalışma. 7.1’de çalışır, 7.2’de seninle kavga eder ve 40 piksellik varsayılanı bitirişte sürükleyen erişilebilirlik argümanını — kullanıcının gözlerini kısmasına gerek kalmadan WCAG rehberine uyan dokunma hedeflerini — çürütür. İkincisi, bu denetimi ilk kez 19 Ağustos’ta canlıda yapma. Beta 1’in API yüzeyini sabitlemesinin bütün amacı, yayına çıkacak kodun aynısıyla hazırlık ortamında test edilecek dört haftanın olması. Kullan.

Yavaş yayılmış bir kullanımdan kaldırmanın güzel yanı, indiği vakit haber olmaktan çıkmasıdır. Erken tercih edenler işi bitirmiş oluyor. Etmeyenler için tek bir Beta döngüsü ve üstünde çalışılacak net bir PR listesi var. Yönetişimin böyle görünmesi gerekiyor — sessiz, öngörülebilir ve senin hafta sonunu kurtaran türden.