WooCommerce 10.9.3 Ödemedeki E-posta Ölümcül Hatasını Düzeltiyor

🇬🇧 English: Read this in English →

Aynı gün iki tane nokta sürümü çıkması ipucudur. Bir WooCommerce sürümü önce bir yama gönderip birkaç saat sonra bir tane daha gönderiyorsa, ekipten biri o gece uyumuyor demektir. 3 Temmuz 2026’da 10.9.2 ve ardından 10.9.3 ile olan tam olarak buydu ve nedenini net anlatmak gerekiyor.

Yeterince Woo minör döngüsü gördüm, örüntüyü tanıyorum. Özellik dondurulmuş bir dal yayınlanır. Gerçek satıcılar üzerinden gerçek trafik akar. Yalnızca üretim yükü altında ortaya çıkan bir şey — yanlış biçimde değer döndüren bir süzgeç, sıcak opcache üzerinde otomatik yüklenmeyen bir sınıf, sessizce ayrışmış bir tablo — destek kuyruklarında görünmeye başlar. Ekip geri taşır, keser, yayınlar. Ve sen, ajans olarak, otomatik güncelleme düğmesine güvenip güvenmeyeceğine ya da önce farkı okumaya karar verirsin. Ben olsam bu sefer okumadan da tıklardım, ama nedenini birazdan anlatacağım.

10.9.3 için cevap net: hemen uygula. Hata yüzeyi doğrudan ödeme ekranın. Ama tıklamadan önce neyin değiştiğini ve woocommerce_mail_callback süzgecine bağlanan herkes için düzeltmenin biçiminin neden önemli olduğunu bil.

Gerçekte yeni olan ne

WooCommerce 10.9.3, 3 Temmuz 2026’da Brian Coords tarafından WooCommerce Geliştirici Blogu üzerinden duyuruldu ve aynı gün çıkan 10.9.2‘nin ardından gelen bir izleme sürümü. Bir güvenlik sürümü değil. Veritabanı güncellemesi gerektiriyor. Sürüm notu tek cümle: süzgeçlenmiş bir posta geri çağrısı boole olmayan bir değer döndürdüğünde WC_Email::send_notification() içinde oluşan ölümcül hatayı düzeltir.

Altta yatan hata, 29 Haziran 2026’da bashfoo tarafından açılan konu #66100. Yeniden üretim adımları: HPOS’u aç, HPOS ve eski tabloları senkron dışına sok, herhangi bir siparişi aç, durumu Tamamlandı olarak değiştirip kaydet. WordPress sana kritik hata ekranını verir. Yığın izi class-wc-email.php:1178‘e düşer. Kök neden sıkı bir dönüş türü. WC_Email::send_notification() metodu : bool olarak tanımlanmış. Alttaki send() metodu ise süzgeçlenebilir woocommerce_mail_callback çağrısından dönen ham değeri hiçbir tür dönüşümü yapmadan geri veriyordu. Sıkı türlerin etkin olduğu PHP 8’de bu bir TypeError. Yanlış bir günde ise bu, tamamlanmayan bir ödeme demek.

Düzeltme PR #66219 olarak yayınlandı — trunk üzerindeki asıl düzeltme #66186‘nın release/10.9 dalına geri taşınması. İkisi de 2 Temmuz 2026’da birleştirildi. Değişiklik küçük ve doğru: posta geri çağrısının dönüş değerini send()‘den çıkmadan önce bool‘a dönüştür, woocommerce_email_sent eylemi tetiklenmeden önce bir kez daha dönüştür ki eyleme geçen yük her koşulda aynı biçimde olsun. Trunk PR’ını Anuj-Rathore24 yazdı, geri taşıma özellik dondurma istisnası olarak, boş değer dönüşü için testlerle birlikte kabul edildi.

PR’ın kapattığı dört konu (#66100, #66143, WOOPLUG-6935, WOOPLUG-6948) tek bir tetikleyici sınıfına dönüyor: woocommerce_mail_callback‘e bağlanıp true ya da false yerine null döndüren bir eklenti veya süzgeç. Hata raporu Gravity SMTP’yi ismen belirtiyor; pratikte wp_mail()‘i temiz bir boole değeri döndürmeden kısa devre yapan her işlemsel posta eklentisi ya da özel süzgeç aynı çukura düşebilir.

Sabitlemekte yarar var: 10.9.2 aynı gün (3 Temmuz) birkaç saat önce, yeni ayarlar SDK otomatik yükleyicisinin güncelleme sırasında yol açtığı ölümcül hataları önlemek ve geliştirilmiş anlık bildirimleri her mağazada varsayılan açık tutmak için çıktı. 10.9.3 ise onun üstüne binen ayrı bir kalem. İkisini birden al.

WordPress ve WooCommerce dünyası için neden önemli

Hikâyenin tamamı hata biçiminde. Bu sessizce yeniden denenen bir arka plan işi değil. Bir günlük dosyasında biriken uyarı da değil. send_notification() sipariş durumu geçişinin ortasında bir istisna fırlattığında, o geçişi tetikleyen her şey — Siparişi Ver’e tıklayan bir müşteri, bir ödeme geçidi web kancası, bir toplu yönetici işlemi — tamamlanmış bir sipariş yerine kritik hata sayfası alır. Hacimli bir mağazada bu, aynı saatin içine sığdırılmış iadeler, ters ibrazlar ve destek talepleri demek. Kısacası: en görünür yerde, en kötü anda patlıyor.

Kurduğumuz yapı için iki yapısal çıkarım var.

Birinci: çekirdek metotlardaki sıkı dönüş türleri, tüm eklenti ekosistemiyle yapılmış bir sözleşmedir. Woo, 10.9.0’da send_notification()‘a : bool eklediği anda her SMTP eklentisi, her özel posta yönlendiricisi, her mu-plugin süzgeci yeni bir yükümlülük almış oldu. Çoğu düzgün bir boole döndürüyor. Bir kısmı döndürmüyor. Olgun tepki tam olarak 10.9.3’ün yaptığı şey — yukarı akıştaki disipline güvenmek yerine sınırda dönüşüm yap. Sıkıcı, savunmacı PHP. Ve doğrusu bu. Ben başkasının koduna güvenmenin bedelini yıllar içinde yeterince ödedim; sınırda bir (bool) dökümü kadar ucuz sigorta az bulunur.

İkinci: HPOS ile eski tabloların senkron dışına düşmesi artık birinci sınıf bir üretim koşulu. Senkron aracını atlayan mağazalar için köşe durum değil. Bir eklenti yanlış tabloya yazdığında, bir taşıma yarım kaldığında, bir hazırlık ortamı yedeği canlıya döndüğünde olan tam olarak bu. HPOS belgeleri zaten senkron denetleyicisini çalıştırmanı söylüyor. 10.9.3’ün dersi, çekirdeğin artık sen çalıştırmasan da bu duruma karşı sertleşiyor olması.

Postan gerçekten gidiyor mu: kısa bir kontrol listesi

Bu hata, çoğu mağazanın hiç bakmadığı bir katmanı — işlemsel e-posta yolunu — bir anda görünür kıldı. Yükseltmeyi yaparken beş dakikanı bu listeye ayır; ödeme akışını sessizce koruyan en ucuz iş bu.

• Bir test siparişi ver ve durumunu Tamamlandı’ya çek. Kritik hata ekranı yerine gerçek bir onay ve gerçek bir e-posta görmelisin.
• Sunucu hata günlüğünde class-wc-email.php ve TypeError ara. Yükseltme öncesi bir iz varsa, bu mağaza tam da bu çukurun kenarındaymış demektir.
• Aktif her işlemsel posta eklentisinin sürümünü yaz. Hepsini güncel sürüme çek. Eskiyen bir SMTP eklentisi bu sözleşmenin en zayıf halkası.
• woocommerce_mail_callback‘e bağlanan tema/functions veya mu-plugin kodunu grep’le. Her dalın açık bir true/false döndürdüğünü gözünle doğrula.
• HPOS senkron denetleyicisini çalıştır. “Senkronize” raporunu görmeden bu maddeyi kapatma.

Ben ne yaparım (ve ne yapmam)

10.9.0, 10.9.1 veya 10.9.2 üzerinde çalışan her mağazaya 10.9.3’ü uygula. 10.9.2’yi zihinsel haritandan sil — 10.9.3 onun yerine geçiyor. İki taşıma da yükseltme sırasında sırasıyla çalışıyor; veritabanı güncellemesi saniyeler alıyor. Bu rutin bir yama ve ödeme ekranında posta süzgeci olan bir mağazanın 10.9.0’da geçirdiği her saat kaçınılabilir bir risk.

woocommerce_mail_callback‘e bağlanan tüm özel kodu denetle. Sahada en sık gördüğüm biçim, günlüğe yazan ve sonra wp_mail()‘e düşen bir süzgeç — ve o düşme yolu hiçbir şey döndürmüyor. Bu null demek. 10.9.3 öncesinde bu zararsızdı çünkü Woo değeri dokunmadan geçiriyordu. 10.9.3 sonrasında çekirdekteki dönüşüm seni kurtarıyor ama süzgecin yine de açık bir boole döndürmesini istersin. Açık olmak ucuz. Örtük olmak sabahın üçünde bir ayıklama seansı.

Herhangi bir işlemsel posta eklentisi çalıştırıyorsan — bildiğin WordPress SMTP isimleri, Gravity SMTP dahil — sürümünü kontrol et. Güncel olana çık. Hata raporu Gravity SMTP’yi özellikle işaret etti; bozuk olduğu için değil, wp_mail()‘i sarmalama biçimi dönüşüm boşluğunu en erken görünür kıldığı için. Bu ekosistem genelinde, her posta eklentisinin woocommerce_mail_callback işleyicisi gerçek bir boole döndüren bir sürüm yayınlayana kadar devam edecek.

HPOS senkron çalışmasını başka bir yama beklerken erteleme. Bu çeyrek yapmadıysan senkron aracını bu hafta çalıştır. Woo, HPOS kod yolunu ayrışmaya karşı sertleştirmeye devam edecek ama senkron aracının amacı ayrışmayı hayatta kalmak değil, ortadan kaldırmak. Ve 28 Temmuz 2026’da yeni mağazalar için ürün nesne önbelleği varsayılan açık olarak gelen WooCommerce 11.0 ile Action Scheduler 4.0.0’ın aynı anda gelmesiyle birlikte, bir sonraki hata seti buna hiç benzemeyecek — ama aynı yerde, üretimde, gerçek yük altında yüzeye çıkacak.

Aynı gün iki nokta sürümü, sağlıklı bir projenin sıkıcı tarafıdır. Sorun pazartesi göründü, düzeltme çarşamba trunk’a girdi, kararlı kullanıcılar cuma aldı. Bu, WooCommerce ekibinin ciddi bir platformun tam olarak yapması gerekeni yapması — ve bu, üzerine inşa etmek için sürekli tekrarladığım savunmanın kendisi.