WordPress 7.1 Simgeler API: v15’in Sessiz Kirici Degisikligi

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

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ız, yönetim ekranı yazıyorsanız, herhangi bir yerde SVG çizen bir eklenti yayımlıyorsanız, 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 verin — ama bunu eski yöntemle yaptığınız her yeri bulmanız 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; simgeniz 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).

WordPress ve WooCommerce insanları için neden önemli

@wordpress/icons paketine hiç doğrudan dokunmamış olsanız bile, büyük olasılıkla onu zaten yayımlıyorsunuz. 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ız, ya korumalı bir sınıf yöntemini kurcalıyor ya da kendi kayıt defterinizi yayımlıyordunuz. 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ız, WordPress çekirdeğini 7.1’e güncellemediğiniz 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ığmayın.

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 tarayın. Her isabet bir aday. color‘a çevirin, simgenin hâlâ doğru renk aldığını doğrulayın, yayımlayın.
• 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ı tarayın. filePath‘i file_path‘e çevirin. Korumalı yöntemi kurcalıyorduysanız, register_icon()‘a geçin — ve 7.0 sitelerin ölümcül hataya düşmemesi için bir sürüm koruması (if ( function_exists( 'register_icon' ) )) ekleyin.
• Özel simge kısa adlarını denetleyin. logo, brand ya da arrow-right‘ı çıplak bir adla kaydettiyseniz, 7.1 bunu reddedecek. Sahip olduğunuz bir ad alanıyla ön ekleyin — acme/logo, acme/brand. Ad değişikliği, kısa adı postmeta ya da seçenekte sakladıysanız aynı zamanda bir veri değişikliği; geçiş yolunu planlayın.
• Beta 1 ya da Beta 2 üzerinde gerileme testi yapın. Üretimde değil. Bir Playground blueprint ya da hazırlık kopyası üzerinde. Eklentinizdeki her yönetim ekranını, ekleyicideki her bloğu, her ayar sayfasını — hem açık hem koyu yönetim renk şeması etkinken — açın. İki şemadan birinde yanlış görünen simgeler düzeltmeniz 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’yi düzeltin.

/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ü bekleyin. 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.