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

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 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 siz, ajans olarak, otomatik güncelleme düğmesine güvenip güvenmeyeceğinize ya da önce farkı okumaya karar verirsiniz.

10.9.3 için cevap net: hemen uygulayın. Hata yüzeyi doğrudan ödeme ekranınız. 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 bilin.

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çın, HPOS ve eski tabloları senkron dışına sokun, herhangi bir siparişi açın, durumu Tamamlandı olarak değiştirip kaydedin. WordPress size 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ın.

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.

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.

İ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ızı söylüyor. 10.9.3’ün dersi, çekirdeğin artık siz çalıştırmasanız da bu duruma karşı sertleşiyor olması.

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’ü uygulayın. 10.9.2’yi zihinsel haritanızdan silin — 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 denetleyin. 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 sizi kurtarıyor ama süzgecin yine de açık bir boole döndürmesini istersiniz. Açık olmak ucuz. Örtük olmak sabahın üçünde bir ayıklama seansı.

Herhangi bir işlemsel posta eklentisi çalıştırıyorsanız — bildiğiniz WordPress SMTP isimleri, Gravity SMTP dahil — sürümünü kontrol edin. Güncel olana çıkın. 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 ertelemeyin. Bu çeyrek yapmadıysanız senkron aracını bu hafta çalıştırın. 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.