WordPress Dashicons Yerine SVG İkonlara Geçiyor

🇬🇧 English: Read this in English →

Yönetim panelinde site başlığının yanındaki o küçük ev ikonu 2013’ten beri aynı simge. Açtığın her wp-admin ekranı onu aynı ikon yazı tipinden çekiyor: Dashicons. Platformun fark etmediğin parçalarından biri; ta ki birisi “değiştirelim” diyene kadar. O anda geliştirdiğin her eklentinin menü ikonunun da sessizce aynı yazı tipine bağlı olduğunu hatırlıyorsun.

O teklif şimdi masada, ve iyi bir teklif. Kariyerim boyunca yeterince ikon-font değişimi gördüm — web-font furyası, yaklaşık sekiz yıl önce kendi ajans yığınımızda yaptığımız satır içi SVG geçişi — göründüğünden çok daha büyük bir değişikliği tanıyacak kadar. Yüzeyde: yazı tipini SVG işaretlemeyle değiştir, herkesin yönetim çubuğu bir tık daha keskin görünsün. Altında: WordPress nihayet ekran okuyuculardan Unicode özel-kullanım bölgesindeki bir kod noktasının ne anlama geldiğini tahmin etmesini istemekten vazgeçiyor. Bu kozmetik değil. Bu, platformun uzun süre kaçındığı bir köşede olgunlaşması.

Bu hafta gerçekten ne değişti

4 Eylül 2026’da WordPress tasarım lideri Joen Asmussen, Make/Core üzerinde Replacing Dashicons in the admin bar and menu başlıklı yazıyı yayınladı. Yazı, Haziran’dan beri arka planda ilerleyen bir çalışmayı resmileştiriyor: Dashicons ikon yazı tipini wp-admin’in en görünür iki parçasından — üst yönetim çubuğu ve sol kenar menüsü — emekliye ayırıp, o alandaki her ikonu yeni Icon API üzerinden satır içi SVG olarak çizmek.

Mekanizma, WordPress 7.1 ile gelen ve Code Reference’ta belgelenen wp_get_icon() fonksiyonu ve kayıt yardımcıları. İkonlar ad alanlı koleksiyonlarda yaşıyor — core/plus, my-plugin/star — ve sunucu tarafında sanitize edilmiş SVG işaretleme olarak render ediliyor. Yönetim yüzeyindeki uygulama Trac bileti #65089 üzerinden takip ediliyor ve Fushar’ın açtığı çekirdek PR #12270 içinde iniyor — şu an trunk’a karşı inceleme aşamasında.

Asmussen’in yazısındaki gerekçe asıl ilgi çekici kısım. Üç somut ikon-font hatası sayılmış, hiçbiri teorik değil:

• İkon yazı tipleri glifleri Unicode özel-kullanım bölgesi kod noktalarına eşliyor. O kod noktalarının anlamsal bir karşılığı yok, yani ekran okuyucular onları tutarsız okuyor — bazen çöp, bazen sessizlik.
• İkon yazı tipleri Windows Yüksek Karşıtlık kipinde ve CSS forced-colors altında kırılıyor. currentColor kullanan SVG’ler kullanıcının zorunlu paletine saygı gösteriyor, kaybolmak yerine.
• Font dosyası yüklenemediğinde kullanıcı kafa karıştırıcı Unicode kutuları görüyor. SVG yüklenemediğinde hiçbir şey görmüyor — ki doğru başarısızlık modu bu.

PR üst çubuğun tamamını (WordPress logosu, menü toggle’ı, çok siteli seçici, dashboard, appearance, edit, yorumlar, güncellemeler, arama, kullanıcı) ve kenar menüsünü (Yazılar, Medya, Bağlantılar, Sayfalar, Eklentiler, Araçlar, Ayarlar ve daralt/toggle) kapsıyor. WordPress markası tarihi 22px yerine 24px viewBox kullanıyor, çünkü @wordpress/icons kütüphanesi o ızgara üzerine çizildi.

Masada duran bir mimari soru var: bir site ya da eklenti, yönetim çubuğunun bağlı olduğu bir çekirdek ikonu deregister ederse ne olacak? Tartışılan seçenekler menu_icon için dosya yolu geri dönüşü, ham SVG string desteği, ya da çekirdek yazı türleri gibi davranan ve deregister edilemeyen bir “yerleşik” ikon koleksiyonu. Küçük gibi görünen bir karar ama üç yıl sonra başarısızlık modunun ne kadar zarif olacağına bu karar karar veriyor.

WordPress ve WooCommerce insanları için ne anlama geliyor

Eklenti ya da tema geliştiriyorsan, yıllar içinde dashicons-* sınıf kuralı üzerinden bağladığın yönetim çubuğu ve menü ikonlarının sayısı hatırladığından fazla. Tek başına WooCommerce yönetim çubuğuna bir alışveriş çantası, sol raya da bir küme ikon koyuyor. add_menu_page() ile alt menü ekleyen her eklenti, o dördüncü argümana bir Dashicon adı geçiyor. Bugün hiçbiri kırılmıyor — Dashicons bir font olarak deprecated edilmiyor, CSS sınıfı hâlâ çekirdekle beraber geliyor. Ama WordPress’in kendi çizdiği yüzey SVG’ye geçiyor ve senin Dashicon tabanlı menü ikonlarınla çekirdek ikonlar arasındaki görsel uyumsuzluk, sen fark etmeden önce müşterin fark edecek.

Diğer taraf erişilebilirlik ve burada vaaz veriyor gibi olmak istemiyorum. Windows Yüksek Karşıtlık kipini ekranı okuyabilmek için gerçekten ihtiyacı olan insanlar kullanır, Chrome DevTools’ta gezinen meraklı geliştiriciler değil. Yönetim çubuğun bir ikon fontuyla kurulduğu için forced-color kipinde kayboluyorsa, bu marjinal bir hata değil — bu, müşterinin asistanından e-postada gelen WooCommerce siparişini açmasını istemesi ve asistanın menü öğesini bulamaması demek. Kurumsal bir B2B mağazada tam olarak bu senaryoyu yaşadım; müşterinin IT ekibi, erişilebilirlik ihtiyacı olan kullanıcıları için tüm yönetim deneyimini sessizce silip attı. WordPress bu yükü 2013’ten beri taşıyor. Çekirdekte düzeltmek geç kalmış bir borç.

Küçük bir performans kazanımı da var. Dashicons her wp-admin sayfasında yüklenen ~55 KB’lık bir font dosyası olarak geliyor. wp_get_icon() üzerinden servis edilen satır içi SVG’ler yalnızca fiilen kullanılan ikonlar, wp_kses ile sanitize edilmiş. Kimse bunun üzerine vaka çalışması yazmayacak ama yönetimin kaybettiği her gram, pazarlama ekibi otel wifi’sine bağlı bir laptopta otuz sekme açtığında birikiyor.

Yerinde olsam ne yapardım (ve yapmazdım)

Üç adım, sırayla.

Birincisi, kendi dashicons-* kullanımını çıkar. Eklenti ve tema repolarında dashicons- ve add_menu_page‘e geçirilen 'dashicons-' için grep at. Her isabet, eninde sonunda wp_get_icon()‘a yönlendireceğin bir yer. Bugün yapmana gerek yok — PR daha inmedi, Dashicons gitmiyor — ama envanteri bir metin dosyasında bulundur; müşteri sana “WordPress logosu neden birden daha keskin göründü, eklentininki ise donuk kaldı” demeden önce.

İkincisi, WordPress 7.1 ve sonrasına yeni bir şey yazıyorsan, ikonlarını ilk günden Icon API üzerinden kaydet. Developer Blog’daki hands-on Icon Registration API rehberi deseni veriyor: eklenti slug’ın altında bir koleksiyon kaydet, her ikonu currentColor kullanan satır içi SVG ile o koleksiyona kaydet, wp_get_icon( 'my-plugin/thing' ) ile render et. Ekosistem yüzlerce ikon kaydetmeye başladığı gün seninkilerin başkalarınınkiyle çakışmasını engelleyen şey ad alanı.

Üçüncüsü, yönetilen WordPress filoları işletiyorsan, bu PR’ı birleşene kadar takip et. İndiğinde, WordPress logosunun biraz farklı göründüğünü fark eden müşterilerden bir tur ticket gelecek. Bunu iki cümlelik iç notla önden karşıla. Bu, “yönetim paneli bozuldu” başlıklı ticketla başlayan sohbetten daha ucuz.

Yapmayacağım şey: bu hafta sonu her eklenti ikonunu yeniden yazmak. Bu göç ekleyici, kırıcı değil. Dashicons yazı tipi çekirdekten çekilmiyor, üçüncü parti dashicons-* sınıf kullanımı çalışmaya devam ediyor; mantıklı hareket fırsatçı göç etmek — başka bir sebeple bir dosyaya girdiğinde o çağrıyı değiştir. Filo çapında bir süpürge sana hiçbir şey kazandırmaz, gelecek bir ay çözmeye çalışacağın gerileme yüzeyini katlar.

Yirmi yıl sonra en sevdiğim WordPress değişikliği türü, kimseden bir şeyi yeniden öğrenmesini istemeden temel bir keskin köşeyi sessizce düzelten türden. Bu onlardan biri. Yönetim aynı görünüyor, ihtiyacı olan insanlar için daha iyi çalışıyor, ve eklenti geliştiricilere önümüzdeki on yıl boyunca üzerine bina edecekleri ciddi bir ikon API’si veriyor.