Ana içeriğe geç

Rentiva v5.2.2 / Pro v5.2.2 — WooCommerce'e ne söylediğimiz, ve yanlış söylediğimiz bir şey

· 3 dakikalık okuma
MaxHandMade
Maintainer

İçinde rahatsız edici bir itiraf olan bir yama sürümü. WordPress.org başvurusuna hazırlanırken WooCommerce kontrol listemizi ilk kez tüm kod tabanına uyguladık — ve WooCommerce'in uyumluluk sorularını hiç cevaplamamış olduğumuzu gördük.

Söylemediğimiz şey​

WooCommerce, siparişlere dokunan her eklentiden hangi yeni özellikleriyle çalıştığını beyan etmesini ister. Hiçbir şey söylemeyen eklenti belirsiz diye kaydedilir ve site sahibi Yüksek Başarımlı Sipariş Depolama'yı açmaya çalıştığında adıyla uyarılır — ki bu depolama WooCommerce 8.2'den beri yeni mağazalarda varsayılan.

Biz hiçbir şey beyan etmemişiz. "Uyumsuz" bile değil — hiçbir şey.

HPOS: uyumlu, ve söylemeden önce ölçüldü​

Uyumluluk beyanı bir sözdür ve yanlış olanı sessizlikten kötüdür: insanlar o söze güvenip HPOS'u açar ve veriyi sessizce kaybeder. Bu yüzden varsaymak yerine ölçtük. Bu eklentinin dokunduğu her sipariş wc_get_order() ile okunuyor; sipariş kimliğine bağlı hiçbir post-meta erişimi yok; hiçbir yer siparişler için wp_posts ya da shop_order sorgulamıyor; hiçbir sipariş wp_insert_post() ile oluşturulmuyor.

Bu artık hem ücretsiz eklentide hem ücretli eklentide beyan ediliyor.

Blok sepet ve ödeme sayfası: uyumlu değiliz ve bunu söylüyoruz​

Mağaza işletiyorsanız okunmaya değer kısım burası.

Sessiz kalabilirdik. Bunun yerine blok tabanlı ödeme sayfasında gerçekte ne olduğunu ölçtük ve uyumsuz beyan ettik, çünkü gerçek bu:

  • Ödeme tipi seçici, özel vergi satırı ve sepete dön bağlantısı hiç görünmüyor — hepsi blok ödeme sayfasının koşturmadığı klasik kancalardan basılıyor.
  • Müsaitlik kontrolü çalışmıyor. Aracın istenen tarihlerde hâlâ boş olduğunu woocommerce_checkout_process içinde doğruluyoruz. Blok ödeme sayfasında o kanca hiç ateşlenmiyor; bu da iki müşterinin aynı aracı aynı tarihlere rezerve edebileceği bir pencere bırakıyor.

Mağazanız blok ödeme sayfasını kullanıyorsa, bu eklentiyi kullanırken klasik ödeme sayfasına geçin. Blok ödeme sayfasını gerçekten desteklemek, o yüzeyleri Additional Checkout Fields API ve bir Store API entegrasyonu üzerine yeniden kurmak demek — bir bayrak değil, bir özellik; ve iddia etmektense düzgün yapmayı tercih ederiz.

Bir değer, HPOS'un okuyamayacağı yere yazılıyordu​

Ödeme sırasında seçilen ödeme tipi update_post_meta( $order_id, … ) ile yazılıyordu. HPOS'ta sipariş bir post değildir; yani bu, sipariş olmayan bir şeye bağlı bir satır yazar.

Artık WooCommerce'in kendi sipariş nesnesi üzerinden gidiyor. HPOS'a geçmemiş bir mağazada o nesne zaten post meta'ya yazar — yani değer tam olarak hep bulunduğu yerde kalır. Hiçbir şey taşınmaz, göç gerekmez.

İtiraf​

Her release derlemesinden önce koşturduğumuz bağımsız denetim, tam da bu değişikliğin içinde bir aramanın çürüttüğü bir iddia yakaladı. Ücretli eklentinin açıklamasının ilk taslağında "checkout kancası kaydetmez ve sepete/checkout'a hiçbir şey basmaz" yazıyordu. İkisini de yapıyor — iki dosyada dört kanca.

Denetim ayrıca bizim atladığımız işi yaptı: WooCommerce'in kendi kaynağını okuyup Store API'nin o kancaların ikisini koşturduğunu, yani o yüzeyin büyük kısmının blok ödeme sayfasında ayakta kaldığını, yalnız sepet kalem adının klasik sayfaya özgü ve kozmetik olduğunu ortaya koydu. Bu karışım ne "uyumlu" ne "uyumsuz"; bu yüzden ücretli eklenti hiçbirini beyan etmiyor ve nedenini yazıyor.

Bunu yazıyoruz çünkü asıl faydalı kısım düzeltmenin kendisi. Yalnız neyin doğru gittiğini sıralayan bir sürüm notu kimseye bir şey öğretmez — en az da bize.

Güncelleme​

Yapmanız gereken bir şey yok. Ücretli eklentiyi kullanıyorsanız ikisini birlikte güncelleyin.