WordPress 7.1 Simgeler API: v15’in Sessiz Kirici Degisikligi

🇬🇧 English: Read this in English →

Simgeler, bu işte üçüncü yıldan sonra artık fark etmediğin şeylerden biridir. Düzenleme için bir kalem, silme için bir çöp kutusu, ayarlar için bir dişli — bir kez kaydedersin, üzerine küçük bir CSS ile rengini belirlersin ve gerçekten önemli işlere geçersin. Sonra bir gün bir paket sürümü yükselir, o renk uygulaması artık işlemez ve bir pazartesi sabahını geçen yıl yayımladığın eklentinin bütün simgelerinin neden birden bire simsiyah olduğunu düşünerek geçirirsin.

WordPress 7.1’in içinde tam da bu tür bir sürüm sıçraması var. Parlak bir özellik değil, önümüzdeki ay WordCamp US’te başlık olacak bir şey de değil — sadece @wordpress/icons paketinde sessiz bir değişiklik ve sunucu tarafındaki Simgeler API’sinde küçük ama anlamlı bir genişleme. Blok yazıyorsan, yönetim ekranı yazıyorsan, herhangi bir yerde SVG çizen bir eklenti yayımlıyorsan, bu 19 Ağustos’tan önce hazırlık ortamında geçirilecek yarım saate değer.

Bu örüntüyü daha önce izledim. WordPress 5.9, blok stillerinin renk devralma biçimini sessizce değiştirmişti. Müşteri kod tabanlarımızın yarısı bunu iyi karşıladı. Diğer yarısında 2019’da artık aramızda olmayan biri tarafından yazılmış tek bir CSS satırı vardı; ve o satır, çalışmayı bıraktığı güne kadar bozuk bir şeyi doğru görünür tuttu. 7.1 simge işi de aynı türden borçları gün yüzüne çıkaracak.

Aslında ne yeni

İki hareketli parça var. Birincisi, JavaScript paketi. @wordpress/icons v15’teki 330 simgenin tamamı artık SVG içinde fill="currentColor" ile geliyor. Bu, simgelere CSS’in fill özelliği üzerinden renk veren her tüketici için kırıcı bir değişiklik. Çözüm tek satır — simgeye fill yerine color ile renk ver — ama bunu eski yöntemle yaptığın her yeri bulman gerekiyor. Değişiklik, developer.wordpress.org üzerindeki Temmuz 2026 geliştirici özeti içinde açıkça belirtiliyor.

İkincisi, WordPress 7.0’da yayımlanan sunucu tarafı Simgeler API’si nihayet düzgün bir kamuya açık yüzey kazanıyor. Aki Hamano’nun açtığı Gutenberg #75715 numaralı izleme kaydı planı ortaya koyuyor: kamuya açık işlevler olarak register_icon() ve unregister_icon(), eşlik eden wp_register_icon_collection() / wp_unregister_icon_collection() ikilisi, yeni bir WP_Icon_Collections_Registry sınıfı ve editörün adları koda gömmeden mevcut olanları listeleyebilmesi için /wp/v2/icon-collections uç noktası.

Kayıt defteri giriş tarafında sıkılaşıyor. Özel simgeler artık {ad-alanı/simge-adı} biçiminde kaydedilmek zorunda — çekirdek adlarla çarpışan çıplak kısa adlara yer yok. WP_Icons_Registry içindeki arama da yalnızca ada bakmaktan çıkıp etiket ve anahtar kelime alanlarına genişliyor; simgen marka-logosu-tek-renk olarak kayıtlıyken editördeki arama kutusuna “logo” yazıldığında simge seçicinin aslında işe yaramasını sağlayan da bu.

Aynı hat üzerinde iki küçük temizlik daha. Kayıt defterindeki dizi anahtarı filePath, WordPress’in olması gerektiği gibi file_path‘e — snake_case biçimine — dönüyor. Yerleşik Simge bloğu ise çevirme ve döndürme kontrolleri kazanıyor ve block.json‘daki varsayılan simgeleri onurlandırıyor. JS paketindeki fill="currentColor" geçişi tesadüf değil — kayıtlı simgelerin ve Simge bloğu örneklerinin bir yönetim panelinde, blok araç çubuğunda ya da yayımlanmış bir yazıda tutarlı davranmasını sağlayan örüntü de bu.

Bunların hiçbiri varsayım değil. Beta 1, wordpress.org/news üzerinden 15 Temmuz’da yayımlandı ve 19 Ağustos’taki genel sürüm için API yüzeyi bugün Beta 1’de olanla aynı. 7.1 yayın sayfası takvimi doğruluyor (Beta 2 — 22 Temmuz, Beta 3 — 29 Temmuz, RC 1 — 5 Ağustos).

currentColor aslında ne yapıyor, neden doğru karar

Bir dakika kaputun altına bakalım, çünkü bu değişikliğe kızmadan önce neden yapıldığını anlaman işini kolaylaştırır. currentColor, CSS’in en eski ve en zarif numaralarından biri: bir SVG’nin dolgusunu fill="currentColor" yaptığında, o simge artık kendi rengini taşımaz — bulunduğu kabın metin rengini, yani color özelliğini miras alır. Yani simgeyi bir düğmenin içine koyduğunda düğme yazısıyla aynı renkte olur, bir uyarı kutusuna koyduğunda uyarı metniyle, koyu temaya geçtiğinde metinle birlikte o da döner. Tek bir color değeri hem yazıyı hem simgeyi yönetir.

Eski yöntemde her simgeye ayrı ayrı fill verirdin; bu da renk mantığını iki yere böler — metin bir kuralda, simge başka bir kuralda. Açık konuşayım, bence bu baştan yanlış bir kalıptı ve WordPress’in nihayet currentColor‘a hizalanması geç kalmış doğru bir hamle. Kısa vadedeki acı gerçek olsa da — evet, birkaç simgen siyaha dönecek — kazandığın şey kalıcı: bir daha “koyu temada simgeler görünmüyor” hatasını kovalamazsın, çünkü simge artık metnin nereye giderse oraya gider. Miras alma pahalıya patlamaz; miras almayı reddetmek patlar.

WordPress ve WooCommerce insanları için neden önemli

@wordpress/icons paketine hiç doğrudan dokunmamış olsan bile, büyük olasılıkla onu zaten yayımlıyorsun. Son üç yılda @wordpress/create-block ile başlatılmış her blok eklentisi paketi bağımlılık olarak çekiyor ve blok editörü için yazılmış her SidebarPanel ya da Toolbar neredeyse kesin olarak paketten bir iki simge içe aktarıyor. Yani pakette yapılan kırıcı bir değişiklik, sürüm notunun ima ettiğinden çok daha fazla kod tabanına dokunuyor.

Hata biçimi dramatik değil. Hiçbir şey istisna atmıyor. Eklenti yükleniyor. Simgeler çiziliyor. Sadece yanlış renkte çiziliyorlar — genellikle açık arka planda düz siyah, ya da koyu arka planda görünmez beyaz — çünkü daha önce fill‘e giden CSS kuralı artık hiçbir yere gitmiyor. Koyu araç çubuklu bir WooCommerce yönetim ekranında bu, 20 Ağustos’ta satıcının bildireceği bir hata olarak okunuyor.

Kamuya açık kayıt işlevleri farklı bir nedenle önemli. 7.1’e kadar özel bir marka simgesi kaydetmek ve bunun Simge bloğu seçicisi ile Gezinti bloğu tarafından keşfedilebilmesini istiyorsan, ya korumalı bir sınıf yöntemini kurcalıyor ya da kendi kayıt defterini yayımlıyordun. 7.1 genel sürümünden itibaren tek kanonik yol var ve /wp/v2/icon-collections uç noktası, React’te yazılmış bir editörün ya da gelecekteki bir yapay zekâ ajanının sitede nelerin var olduğunu koda gömülü bir liste olmadan sayabilmesi anlamına geliyor.

WooCommerce çerçevesi: WooCommerce 11.0, 28 Temmuz’da geliyor. 7.0.2 kararlı sürümündeki Woo mağazan, WordPress çekirdeğini 7.1’e güncellemediğin sürece simgelerdeki hiçbir değişikliği görmeyecek — ve bu güncelleme, 11.0 denetim listemize göre Woo yükseltmesinden ayrı bir değişiklik penceresi olmalı. İkisini üst üste yığma.

Ne yapardım (ve ne yapmazdım)

Bu hafta sırayla dört tarama.

• Filodaki her eklenti ve temada svg { fill: ... }, .bir-simge { fill: ... } ya da simge bileşenlerinde fill ayarlayan herhangi bir styled-components kuralına dokunan CSS seçicilerini tara. Her isabet bir aday. color‘a çevir, simgenin hâlâ doğru renk aldığını doğrula, yayımla.
• Doğrudan WP_Icons_Registry::register() çağrılarını, özel simge kayıt yamalarını ve simgeyle ilgili kodda geçen filePath adındaki dizi anahtarlarını tara. filePath‘i file_path‘e çevir. Korumalı yöntemi kurcalıyorduysan, register_icon()‘a geç — ve 7.0 sitelerin ölümcül hataya düşmemesi için bir sürüm koruması (if ( function_exists( 'register_icon' ) )) ekle.
• Özel simge kısa adlarını denetle. logo, brand ya da arrow-right‘ı çıplak bir adla kaydettiysen, 7.1 bunu reddedecek. Sahip olduğun bir ad alanıyla ön ekle — acme/logo, acme/brand. Ad değişikliği, kısa adı postmeta ya da seçenekte sakladıysan aynı zamanda bir veri değişikliği; geçiş yolunu planla.
• Beta 1 ya da Beta 2 üzerinde gerileme testi yap. Üretimde değil. Bir Playground blueprint ya da hazırlık kopyası üzerinde. Eklentindeki her yönetim ekranını, ekleyicideki her bloğu, her ayar sayfasını — hem açık hem koyu yönetim renk şeması etkinken — aç. İki şemadan birinde yanlış görünen simgeler düzeltmen gerekenler.

Ne yapmazdım: simgeleri bir filtreyle açık fill özniteliklerine geri yamalamak. İki hafta rahatlık, ardından bir sonraki Gutenberg döngüsü örüntüyü daha da inceltdiğinde yükseltme yolu olmayan teknik borç. Çerçeveyi değil, CSS’i düzelt.

/wp/v2/icon-collections‘ı da henüz üstüne araç yazılabilecek düzeyde üretime hazır saymazdım. Bir yayın döngüsü bekle. Uç nokta biçimi, 7.1 genel sürümünde iç editör kullanımı için yeterince kararlı; ama dış tüketicilerin, üzerine gösterge paneli yazmadan önce yüzeyin oturmasına izin vermesi gerekir.

Simgeler bilinçli olarak sıkıcıdır. Bu bir iltifat. Altta yatan API biraz daha az akıllı, biraz daha tutarlı hâle geldiğinde, WordPress’in önümüzdeki beş yılını atlatacak eklentiler onun etrafında dolambaç yazanlar değil, şimdiden ona yaslananlar olacak.