WooCommerce 10.9 Sürümü: Salı GA, Çarşamba Yama

🇬🇧 English: Read this in English →

Yeterince Salı sabahı WooCommerce sürümü canlıya almışım — hangisinin sessiz, hangisinin sessiz olmadığını artık ilk birkaç saatte anlıyorum. Salı çıkan bir sürümün Çarşamba günü yama alması nadiren sessizdir. WooCommerce 10.9.0, 23 Haziran’da yayınlandı; 10.9.1 ise 24 saat dolmadan arkasından geldi. Özelliklere geçmeden önce bu tek başına bir paragraflık bağlam hak ediyor.

Başlık listesi — çekirdekte işlemsel e-posta günlüğü, daha hafif bir Store API ödemesi, yenilenmiş yönetim kabuğu, genişletilmiş MCP yetenekleri — gerçekten faydalı. Birkaçı, müşterilerimizin doğrudan istediği şeyler. Ama dot sürümün hızı, yirmi yıldır söylediğimiz bir şeyi hatırlatıyor: WordPress üzerinden gerçek gelir akıyorsa, .0 sürümünü canlıya ilk gün koymazsın. Olgunlaşmasını beklersin.

İşte bu ikilinin içinde ne var ve her parçayla ne yapardım.

10.9.0’da gerçekten yeni olan

WooCommerce 10.9.0, WooCommerce Developer Blog’da 23 Haziran 2026 tarihinde yayınlandı; sürüm yöneticisi Brian Coords. Notlar 65 katkıcıdan 464 pull request’i kayda alıyor. Geriye dönük uyumlu ve etkinleştirmede bir veritabanı güncellemesi gerektiriyor.

Öne çıkarmak istediğim dört şey:

• Çekirdekte işlemsel e-posta günlüğü. E-posta gönderim denemeleri artık WooCommerce > Durum > Günlükler ekranından — gönderimin başarılı olup olmadığı ve yerel hata ayrıntılarıyla — incelenebiliyor. Sipariş onayının gerçekten çıktığını doğrulamak için WordPress posta sisteminin önüne ayrı bir günlük eklentisi koymana gerek kalmıyor.
• Daha hafif bir Store API ödemesi. Store API, yeni oturumlar için ödeme akışının erken aşamasında artık taslak sipariş kalıcılaştırmıyor. Ön sürüm notlarının ifadesiyle, taslak oluşturma “place-order” anına daha yakın bir noktaya erteleniyor; bu da siparişi tamamlamayan alışverişçilerden kalan boşa düşmüş taslak satırlarını azaltıyor.
• Yönetim kabuğu tazelendi. Üst bar yenilendi ve WordPress tasarım sistemiyle daha sıkı hizalandı, küçük ekran gösterge paneli durumları için hedefli düzeltmeler geldi, modallar yönetimde tek tip hâle getirildi ve görev listesi hatırlatma çubuğu Woo yönetim sayfalarının çoğundan kaldırıldı. Kurulum rehberi göstergede ve etkinlik panelinde duruyor.
• Özelleştirmelerine saygı duyan e-posta editörü. Blok tabanlı e-posta editörü artık çekirdek şablon güncellemelerini algılayıp markanı silmeden uygulamana yardım ediyor. Değiştirilmemiş şablonlar için otomatik uygulama, e-posta listesinde ve editörde güncelleme göstergeleri, bir değişiklik özeti endpoint’i, seçmeli uygulama, geri alma ve özelleştirilmiş şablonlar için üç yönlü diff bir arada geliyor.

Ajan tarafında 10.9.0, ürün ve sipariş işlemleri için kanonik WooCommerce alan yeteneklerinin yeniden inşasını getiriyor; uzantılar abonelikler, ödeme hesabı ayrıntıları, kargo kuralları, ürün eklentileri, hediye kartları, otomasyon iş akışları ve pazarlama durumu için salt okunur erişim kazanıyor. Bu, Mayıs’taki kanonik WooCommerce yetenekleri yazısında özetlenen çalışmanın devamı.

Son haftalarda yazdığım varyasyon görsel galerileri, renk seçicileri ve alışveriş listeleri de bu sürümün içinde — özellik anahtarları arkasında. Blok tabanlı ürün düzenleyici beta artık resmen kullanım dışı; 11.0’da tamamen kaldırılacak ve tek tıkla geri dönüş yolu hazır.

Ve ertesi gün 10.9.1

GA sürümünden yaklaşık bir gün sonra ekip WooCommerce 10.9.1’i yayınladı. Bir güvenlik güncellemesi değil. Geriye dönük uyumluluk düzeltmesi.

10.9.0, ürün feed’i FeedInterface arayüzüne zorunlu bir get_entry_count() metodu ekledi. Bu metodu uygulamayan üçüncü taraf gerçekleştirmelerini kırdı — en görünür biçimde WooCommerce Stripe Payment Gateway uzantısının eski sürümlerini. 10.9.1 bu zorunluluğu paylaşılan arayüzden çıkarıyor ve metodu somut JsonFileFeed sınıfında bırakıyor; böylece henüz güncellenmemiş uzantılar için uyumluluk geri geliyor.

Tek bir arayüz metodu, üretimde bir gün, yüzlerce mağazada ödeme entegrasyonunda fatal hata. WordPress.org’un yirmi dört saatlik sürüm bekleme süresi tam olarak bunu absorbe etmek için tasarlandı — ve bizim hâlâ bize önemli gelen hiçbir ödeme akışına dokunmadan önce her Woo sürümünü kendi içimizde sahnelendirmemizin nedeni de bu.

WordPress ve WooCommerce’çiler için neden önemli

Üretim mağazası işletenler için üç sonuç var.

Birincisi, e-posta günlüğü değişikliği, bir müşterinin “sipariş onayını hiç almadım” dediği ilk anda kendini amorti eden türden bir özellik. WP Mail Logging kurup, bir ödemeyi yeniden üretip, hosting’in SMTP ekibiyle ekran paylaşarak bir öğleden sonra geçirdiysen ne demek istediğimi bilirsin. Artık bu işlem Durum > Günlükler‘de tek tık — yani geliştirici aracını hiç açmamış bir destek temsilcisi için de tek tık.

İkincisi, Store API’deki ertelenmiş taslak sipariş davranışı, yoğun mağazalar için gerçek bir veritabanı kazanımı. Ödemeye başlayıp vazgeçen her tarayıcı arkasında bir taslak satır bırakırdı. Günde on binlerce ödemenin döndüğü mağazalarda bu, wp_posts üzerinde ve sonradan onu tarayacak temizlik işinde anlamlı bir baskıdır. 11.0 ile gelecek Action Scheduler 4.0 temizlik çalışmasıyla birlikte, yaz boyunca veritabanı hijyeni üzerindeki birikimli etki gerçek.

Üçüncüsü, 10.9.1’deki arayüz düzeltmesi, WooCommerce güncellemelerini neden sahnelendirilmiş bir takvimde tuttuğumuzun, otomatik güncellemede tutmadığımızın iyi bir örneği. Arayüz değişikliği yalıtılmış olarak gayet makul bir refactor. Aynı zamanda aktif izlemediğin bir müşteri sitesinde çalışan bir uzantıyı tam olarak bu şekilde kıran türden bir değişiklik. WordPress.org bekleme süresi Salı öğleden sonra birçok mağazayı fatal’dan kurtardı. Bir sonrakini her zaman kurtarmayacak.

Sürüm numarasını okumayı öğren

Bir sürüm numarası aslında bir olgunluk göstergesidir, sadece bir etiket değil. Ben olsam bir Woo sürümüne bakarken şu basit refleksi işletirim: x.y.0 “ekip bunu yeni bitirdi ve dünyayla ilk kez temas ediyor” demektir; x.y.1 ise “dünya bir gün onunla temas etti, ilk keskin kenar zaten törpülendi” demektir. Bu yüzden gelir akan bir mağazada .0 sürümü benim için bir davet değil, bir uyarıdır. Beklemek korkaklık değil, disiplindir.

10.9.0 → 10.9.1 hikâyesi bu refleksin neden işe yaradığının ders kitabı örneği. .0’ı ilk gün canlıya alan mağazalar Stripe entegrasyonunda fatal hatayla tanıştı; bir gün bekleyenler ise sadece .1’i gördü ve olayı haberlerden okudu. Aynı özellikler, aynı fayda, sadece yirmi dört saat sabır farkı. Bu satırı yıllardır tekrar ediyorum çünkü her sürüm döngüsünde birileri bunu yeniden öğrenmek zorunda kalıyor.

Ne yapardım (ya da yapmazdım)

Kendi sunucunda tek bir Woo mağazası yönetiyorsan, bu hafta staging ortamına 10.9.0’ı değil 10.9.1’i kur, tam ödeme matrisini çalıştır ve mutlu olduğunda canlıya al. Üretimde gerçekten istediğin sürüm 10.9.1.

Bir mağaza filosu yönetiyorsan üç şey yap. Bir: otomatik güncellemelerini x.y.0 sürümlerini atlayacak ve sadece x.y.1 veya sonrasını uygulayacak şekilde sınırlandır. İki: son çeyrekte güncellenmemiş bir ödeme ağ geçidi uzantısı çalıştıran her mağazayı denetle — elbette Stripe, ama aynı zamanda devraldığın veya kendi yazdığın özel ya da eski herhangi bir ağ geçidi. Üç: en yüksek hacimli mağazanda yeni e-posta günlüğünü aç ve kullan. Bir ters ibrazın bir onay e-postasının gerçekten gönderilip gönderilmediğine bağlı olduğu ilk an, o günlüğün olduğuna sevineceksin.

Hâlâ blok tabanlı ürün düzenleyici beta’sındaysan, geri dönüşü planlamanın anı şimdi. 10.9 deprecation penceresi. 28 Temmuz’daki 11.0, paketin, route’un, menü girişinin ve anahtarın hepsinin çıktığı sürüm. Bu süreyi sprint’ine ekle.

Ve FeedInterface‘i bir noktada uygulamış herhangi bir uzantı bakıyorsan: kamuya açık yüzey bildiğin hâline döndü, ama bir sonraki güncellemeni göndermeden önce 10.9.1 notlarını ve bağlı pull request’i okuyup yeni sınırla hizalan.

Bunların hiçbiri dramatik değil. Asıl mesele de bu. WooCommerce uzun oyunu kazanmaya devam etmek için dramatik olmak zorunda değil — sadece öngörülebilir bir tempoda kullanışlı ve geri alınabilir değişiklikleri sürmeye devam etmesi ve içlerinden biri ıskaladığında bunu dürüstçe söylemesi yeterli. Bu hafta her ikisi de yerine geldi.