WooCommerce 11.3 İndirimli Ürün API Filtresi Nasıl Test Edilir?

Kısa yanıt

WooCommerce 11.3 beta sürümünde ürün API'sine birlikte verilen on_sale ve include ya da exclude filtreleri, önceki sürüme göre farklı sonuç döndürebilir. Bir vitrinde seçili indirimli ürünleri veya dışlanmış ürünleri gösteren özel entegrasyonunuz varsa, sürüm yükseltmeden önce aynı istekleri test mağazasında çalıştırın. Beklenen ürün kimliklerini, dönen kimlikleri ve müşterinin gördüğü listeyi karşılaştırın. Bu değişiklik tek başına kullanılan filtreleri değil, filtre birleşimlerini ilgilendirir. 4 Kasım 2026 itibarıyla 11.3 beta aşamasındadır; canlı mağaza için kesin sürüm davranışını yayımlanan kararlı sürümde yeniden doğrulayın. WooCommerce geliştirici duyurusu kapsamı ve örnekleri açıklar.

Hangi mağazalar etkilenebilir?

Standart ürün arşivini hiç özelleştirmeyen bir mağazanın bu değişiklik için ayrı bir çalışma yapması gerekmeyebilir. Asıl kontrol, ürünleri API ile alan özel vitrin, mobil istemci, pazaryeri eşlemesi veya kampanya modülündedir. Entegrasyonda on_sale=true ile belirli ürün ID'leri seçiliyorsa sonuç artık yalnızca bu kümenin gerçekten indirimde olan bölümünü içermelidir. exclude ile dışlama yapılıyorsa da dışlanan ID'lerin sonuçta bulunmaması beklenir. WooCommerce duyurusu ürün, varyasyon ve Store API uç noktalarını sayıyor; hangi uç noktanın kullanıldığını istek günlüklerinden belirleyin.

Bu test bir SEO kontrolünden önce ürün doğruluğu kontrolüdür. Yanlış liste, müşterinin kampanya mesajı ile ürün sayfasındaki fiyatı tutarsız görmesine neden olabilir. Özel vitrinin arama motoruna açık bir sayfası varsa, görünür ürünlerin doğru olması içerik kalitesini de etkiler. Yine de bu güncellemenin doğrudan sıralama etkisi olduğunu iddia etmek için dayanak yoktur. Amaç kullanıcıya doğru ürünleri göstermek ve entegrasyonun beklenen kuralla çalışmasını sağlamaktır.

Değişikliği örnek veriyle anlamak

Test mağazasında dört ürün tanımlayın: ikisi indirimde, ikisi normal fiyatta olsun. İndirimde olanlardan birini include listesine, diğerini liste dışına koyun. on_sale=true ve include birlikte kullanıldığında yalnızca her iki koşulu sağlayan ürünün gelmesini bekleyin. Ardından on_sale=false ile aynı ID kümesini sınayın. Bu kez indirimde olmayan ve listede bulunan ürün dönmelidir. exclude için de hem indirimli hem normal fiyatlı birer ID çıkararak iki yönde test yapın.

Bu örnek, API cevabını gözle incelemekten daha güçlüdür: her testin beklenen ID kümesini önceden yazarsınız. WooCommerce'in ürün API belgeleri include, exclude ve on_sale parametrelerini ayrı ayrı gösterir. Birleşim davranışının 11.3 beta farkını ise geliştirici duyurusundaki tabloya göre değerlendirin. Duyurunun kendi örneğinde on_sale=true&include=10,13 isteğinin yeni sonuç kümesi yalnızca 13 olur; bu rakamları mağazanızın gerçek ürünleri gibi sunmayın.

Kabul testi nasıl hazırlanır?

Önce entegrasyonun ürün çektiği bütün yerleri envanterleyin. Kod içindeki sorgu oluşturucuya, zamanlanmış göreve, uygulama ara sunucusuna ve önbellek katmanına bakın. İstek URL'sini, WooCommerce sürümünü, ürün ve varyasyon sayısını, yetki bağlamını kayda alın. Gizli API anahtarlarını test raporuna yazmayın. Sonra üretim verisinin güvenli bir kopyasında veya gerçekçi test ürünleriyle kurulmuş staging ortamında aynı sorguları çalıştırın. Beta paketini canlı müşterilere açık mağazada denemeyin.

Her senaryoda yalnızca HTTP 200 almak yeterli değildir. Dönen ID kümesi, sıralama, sayfalama, varyasyon üst ürünü ve önbellek sonucunu karşılaştırın. Bir ürün ilk sayfadan çıkınca ikinci sayfadaki ürün öne gelebilir; bu nedenle yalnızca ilk kartı kontrol etmek eksik sonuç verir. İndirim başlangıç ve bitiş zamanı olan ürünlerde test anındaki gerçek indirim durumunu ayrıca doğrulayın. Kampanya hesabınızın fiyat ve ürün seçimi kuralları mağazaya özelse, beklenen sonuçları işletme sahibiyle birlikte onaylayın.

Vitrin ve entegrasyon hatalarını ayırın

API doğru ID'leri döndürse bile önbellek eski listeyi gösterebilir. Önce ham isteği ve ham yanıtı kaydedin; sonra uygulamanın veri dönüştürme katmanını ve ön yüz listesini ayrı karşılaştırın. Ham yanıtta ürün yoksa filtre birleşimini ve WooCommerce sürümünü inceleyin. Ham yanıtta ürün var fakat vitrinde yoksa önbellek, filtreleme ve görünürlük koduna bakın. Fiyatı farklı görünen ürünlerde indirim sorgusu ile fiyat veri kaynağının aynı katalog durumunu okuduğunu kontrol edin.

Varyasyonları ayrı ürün gibi sunan arayüzler için üst ürün ve varyasyon ID'lerinin karışması sık karşılaşılan bir tasarım riskidir; bunun projede gerçekleştiğini varsaymayın. Test matrisinde basit ürün, varyasyon, arşiv kartı ve ürün detayını ayrı satırlara alın. Kampanya listesi harici kanala aktarılıyorsa, gönderilen ürün kümesi ile kanalda görünen kümenin uzlaşmasını da kontrol edin. Böylece yanlışlığı API'den mi yoksa entegrasyonun sonraki adımından mı kaynaklandığını bulabilirsiniz.

Ne zaman kodu değiştirmek gerekir?

Önce mevcut kodun niyetini yazılı hale getirin. Amaç “belirlediğim ID'ler arasındaki indirimli ürünler” ise 11.3 davranışı bu niyete yakındır; özel filtreleme kodu gereksiz kalabilir. Amaç “belirlediğim ID'ler her durumda görünsün, indirimli olanlar öne çıksın” ise tek sorguda iki koşul kullanmak doğru tasarım olmayabilir. Ürün seçimini ve sıralamayı ayrı adımlarda uygulamayı değerlendirin. Kodu değiştirmeden önce müşteri ekranı, kampanya etiketi ve raporlamanın aynı niyeti paylaştığından emin olun.

İndirim filtresini kaldırmak hızlı bir yama gibi görünebilir fakat normal fiyatlı ürünleri kampanya bloğuna sokabilir. Bütün sonuçları ön yüzde filtrelemek de sayfalama ve performans sorunları yaratabilir. Çözümü küçük veri kümesiyle doğrulayıp daha büyük katalogda sınayın. Eşit olmayan sonuçlar çıkarsa sürüm, uç nokta, parametre dizisi ve örnek ürün durumunu içeren tekrar üretilebilir bir hata kaydı tutun. Önceki WooCommerce iade API yazımız aynı beta sürümünde farklı bir işlem alanını inceler; ürün listeleme testini onunla karıştırmayın.

Yayına geçiş ve geri dönüş

Sürüm yükseltme kararı için önce test sonuçlarını kabul kriterleriyle eşleyin. Kritik vitrinde beklenen ürün kümesi bozuluyorsa güncellemeyi durdurun ve düzeltmeyi staging ortamında yineleyin. Sürüm yükseltmesinden sonra kısa aralıklarla ham API sonuçlarını ve müşteri ekranını örnekleyin. İşletmenin promosyon takviminde yeni kampanya başladığında aynı testleri yeniden çalıştırın; statik test ürünleri her gerçek veri durumunu temsil etmez.

Geri dönüş planı eklenti dosyasından ibaret olmamalı. Veritabanı ve diğer eklentilerin sürüm uyumluluğunu da değerlendirin; yedek ve geri yükleme prosedürünü önceden deneyin. Beta duyurusundaki davranışın son sürümde değişebileceğini kabul ederek sürüm notlarını tekrar okuyun. Kendi entegrasyonunuzda bu sorgular yoksa gereksiz değişiklik yapmayın. Hangi sorguların kullanıldığından emin değilseniz, Webinle web yazılım hizmeti kapsamında mevcut ürün veri akışını ve kabul testini birlikte kapsamlandırabilirsiniz.