WordPress Unicode E-posta Adresleri 7.1 Trunk’a Geldi

🇬🇧 English: Read this in English →

Yıllardır kullanıcı kaydı, parola sıfırlama, WooCommerce sipariş bildirimleri ve “bu adres neden geri dönüyor” araştırmalarını yazıyor, ayıklıyor, izliyorum. WordPress’te e-posta doğrulaması, sen canını yakana kadar fark etmediğin şeylerden biridir. Kural hep sessizce şuydu: yalnızca ASCII; aksi takdirde is_email() sana hayır der ve geri kalan yığın da aynı şeyi söyler.

Bu kural nihayet kımıldıyor. Pazarlama yazısında değil, yol haritası slaydında değil; çekirdek trunk dalında, gerçek bir değişiklik kaydı, gerçek bir yeni sınıf ve gerçek bir test çağrısıyla. Çok dilli bir mağaza, A–Z aralığına sığmayan isimlere sahip kullanıcılar için bir üyelik sitesi ya da kullanıcı verisine dokunan herhangi bir eklenti işletiyorsan, bu WordPress 7.1 yayınlanmadan önce dikkatle okumak isteyeceğin türden bir altyapı değişikliği.

Çerçeve de önemli. WordPress bu yıl yirmi üç yaşında ve sıkıcı, yavaş yanan yükseltmeler — kalıcı bağlantılar, yönlendirmeler, revizyonlar, yönetişim ve şimdi e-posta alanında Unicode — açık webi hâlâ ayakta tutan şey. Bu yükseltme de tam olarak o sınıftan.

Asıl yeni olan ne

10 Haziran 2026’da Dennis Snell, Make WordPress Core üzerinde duyurdu: Unicode e-posta adresi desteğinin ilk aşaması, uzun süredir açık olan #31992 numaralı kayda karşılık, [62482] numaralı değişiklikle trunk dalına alındı. Yazının başlığı “Call for Testing: Unicode email addresses” ve yazı tam olarak bunu istiyor: WordPress 7.1’den önce yeni davranışı zorla.

Birlikte gelen üç somut değişiklik var:

• is_email() ve sanitize_email() artık grå@grå.org gibi ASCII dışı adresleri kabul ediyor; davranışları WHATWG e-posta şartnamesine hizalandı.
• Yeni bir sınıf, WP_Email_Address, bir e-posta adresine yapısal bir bakış sağlıyor — yerel kısım, alan adı kısmı, Punycode çözümü — böylece eklenti kodun düzenli ifadelerle tahmin yürütmeyi bırakabilir. WP_Email_Address::from_string() üretici metodu, get_ascii_address() ve get_unicode_address() yardımcılarına sahip bir nesne döndürüyor.
• İki yeni süzgeç, wp_is_unicode_email ve wp_sanitize_unicode_email, eski ASCII-yalnızca davranışını koruması gereken bir sitenin yeni mantığı kısa devre yaptırmasına izin veriyor.

Tek katı ön koşul: Unicode e-posta desteği, site veritabanı karakter setinin utf8mb4 olmasını gerektiriyor. Bu yıllardır WordPress varsayılanı, ancak 2010’ların başından devralınan kurulumlar hâlâ utf8 veya daha kötüsünde olabilir. Veritabanın utf8mb4 değilse, yeni kod yoldan çekiliyor.

Bu birden bire gelmiyor. Mayıs ayında agulbra, özgün öneriyi Make Core’da yayımladı; RFC 6530’u standartlaşma şemsiyesi olarak gösterdi ve büyük sağlayıcıların UTF-8 adreslerini yıllardır fiilî bir norm olarak ele aldığını belirtti. Haziran birleştirmesi, o önerinin daha dar, ihtiyatlı bir dilimi: kullanıcı hesapları için e-posta adresleri; kullanıcı adları değil, kalıcı bağlantı parçaları değil, antispambot() değil. Onlar sonraya kaldı. Haziran 2026 geliştirici bülteni de daha geniş öneriyi “geri bildirim aşamasında” olarak işaretledi — dolayısıyla planını fiilen birleştirilen şey üzerine kur, dilek listesinin tamamı üzerine değil.

Karakter kümesiyle bir dinozorun eski hesabı

Bu ASCII kısıtının kalkması bana çok eski bir yarayı hatırlatıyor. 1990’ların sonunda çok dilli CD-ROM projeleri yaptım — aynı içerik altı, yedi dilde, tek diskte. O günlerde Unicode henüz her yerde yaygın değildi; her dil kendi karakter kümesiyle, kendi kod sayfasıyla gelirdi. Türkçe için ISO-8859-9, başka bir dil için başka bir tablo. Yanlış kod sayfasıyla açılan bir metin, ekranda anlamsız kutucuklara ve soru işaretlerine dönerdi — bizim tabirimizle “mojibake”. Bir “ğ” harfinin başka bir sistemde nasıl bambaşka bir sembole dönüştüğünü canlı canlı izledim.

O yıllarda öğrendiğim ders şuydu: bir karakteri sisteme kabul etmek ayrı bir iş, onu boru hattının her durağında doğru taşımak bambaşka bir iş. Diske yazabilirdin ama başka bir makinede yanlış tabloyla okununca çöpe dönerdi. Unicode e-posta hikâyesi bunun otuz yıl sonraki hali: is_email()‘in grå@grå.org‘u kabul etmesi kolay kısım. Zor kısım, o adresin veritabanından SMTP’ye, faturaya, CRM’e ve destek gelen kutusuna kadar her durakta aynı kalması. Ben bu filmi kod sayfalarıyla bir kere izledim; sonu, boru hattını uçtan uca test etmeyenler için hep aynı bitiyor.

WordPress ve WooCommerce insanları için neden önemli

Yalnızca İngilizce konuşan müşterilere İngilizce tanıtım siteleri kuruyorsan, bunu bir yıl boyunca aklından çıkarabilirsin. Geri kalan herkes için — ki ciddi WordPress ve WooCommerce işlerinin büyük çoğunluğu burada — e-posta alanı kullanıcı kaydının, sipariş kaydının, aboneliğin, faturanın, parola sıfırlamanın ve her işlem bildiriminin omurgasıdır. Kod tabanın bir kapıda is_email() çağırıyorsa, o kapı az sonra daha fazla trafiği içeri almaya başlayacak.

En sert düştüğü yerler şunlar:

• Özel kayıt akışları. Kendi kaydolma formunu yazdıysan ve doğrulama için is_email()‘ı yeniden kullandıysan, daha önce reddettiğin adresleri kabul etmeye başlayacaksın. Tasarım niyeti budur. Sonraki tüketicilerinin — CRM’inin, e-posta gönderim sağlayıcının, faturalama servisinin — gerçekten kabul ettiğinden emin ol. Çoğu kabul etmiyor.
• WooCommerce ödeme akışı ve müşteri kayıtları. Fatura e-postası Woo’da müşteri kimliğidir. Çekirdek bir kez müşteri@şirket.tr adresini kabul ettiğinde, asıl soru Stripe, PayPal, vergi motorun ve fatura PDF kütüphanenin bundan sağ çıkıp çıkmayacağıdır. Sadece form gönderimini değil, boru hattının tamamını test et.
• Günlükler ve arama. Bir yerde “e-posta”yı düz metin olarak bir dosyaya veya üçüncü taraf hizmete yazıyorsan, az sonra o hedefe ASCII dışı yazmaya başlayacaksın. Günlük taşıyıcının, hata izleyicinin ve destek gelen kutusu araçlarının Unicode’u doğru gösterdiğini doğrula. Bu, kişisel olarak daha önce yandığım bir nokta.
• Eklenti yazarları. E-postaları düzenli ifadeyle ayrıştırmayı bırak. WP_Email_Address::from_string() artık güvenli temel araçtır. get_ascii_address() yardımcısı, SMTP zarfında Unicode’u gerçekten kaldıramayan eski sistemler için kaçış kapındır.

Barındırma ve DevOps ekipleri için bir not: Unicode e-postanın asıl ilginçleştiği katman SMTP’nin kendisi. Unicode yerel kısma sahip bir adrese e-posta göndermek, uçtan uca SMTPUTF8 desteği gerektirir. Birçok işlem sağlayıcısı bu desteğe sahip, birkaçı değil, bazıları ise alan adı başına açıkça etkinleştirilmesini istiyor. Bir adresi veritabanına kabul etmek bir karardır. Buna bir parola sıfırlama postasını başarıyla teslim etmek bambaşka bir karardır.

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

Bu ay, bu sırayla şunları yapardım:

• Trunk’ı bir Playground’a veya hazırlık ortamına çek ve yığınının açtığı her kayıt, ödeme, parola sıfırlama ve yönetici kullanıcı oluşturma yolundan bir Unicode adresi (duyurudaki kanonik test örneği grå@grå.org) geçir. Nerede çalıştığını, nerede kırıldığını ve nerede sessizce bozduğunu not al.
• Gönderdiğin her eklentide ham e-posta düzenli ifade doğrulaması yapan kodu tara. WordPress 7.1 ve sonrasında çalışacak kod yollarında bunu WP_Email_Address ile değiştir ve eski sürümler için bir geri dönüş bırak. Eski kodu henüz söküp atma.
• E-posta sağlayıcınla ve ödeme sağlayıcınla konuş. Bir Unicode adrese teslim edemeyeceksin; kabul etmek yalnızca yavaş yanan bir destek talebidir. Yazılı bir yanıt al.
• Gerçekten yalnızca ASCII kalmak zorunda olan bir site işletiyorsan — düzenlemeye tabi bir B2B portalı, eski bir ERP entegrasyonu, özel bir uyumluluk gerekliliği — wp_is_unicode_email ve wp_sanitize_unicode_email süzgeçlerini kullanarak devre dışı bırakmayı şimdi yaz. Bir kullanıcı hata bildirmeden önce, 7.1 inmeden önce yap.
• Bir test raporu gönder. Kamuya açık bir test çağrısının bütün anlamı, sürüm dalı kapanmadan önce çekirdeğin gerçek sinyal almasıdır. Öneri açıkça bunun 7.1 için iyileştirildiğini söylüyor.

Yapmayacağım şey: bugün üretimde herhangi bir şeyi, bunun değişmeden ineceği varsayımıyla yeniden yazmak. Bu trunk’ta, yayın değil. Trunk değişir. Denetimi kur, hazırlık ortamı testlerini yaz, ihtiyacın varsa devre dışı bırakmayı yaz ve gerçek kodu itmek için 7.1 sürüm adayını bekle.

WordPress’in e-posta alanında Unicode’a, kayıt açıldıktan on bir yıl sonra kavuşması gösterişli bir hikâye değil — ve bütün mesele de bu. Sessiz ve dikkatli yükseltmeler, platformu diller ve on yıllar boyunca güvenilir kılan şey. Önümüzdeki haftalarda bunu müşteri projelerinde test edeceğiz; 7.1 senin yerine karar vermeden önce senin de aynısını yapmanı öneririm.