WooCommerce 11.1 Blok Kaydını Cron ve REST’te Atlıyor

🇬🇧 English: Read this in English →

Sıkıcı sürüm notlarına zaafım var. “Yeni bir gösterge tablosu çıkardık” cinsinden değil — “yıllardır yaptığımız ama yapmamamız gereken bir şeyi bırakıyoruz” cinsinden. Bugün yayımlanan WooCommerce 11.1 tam olarak bunlardan birini içeriyor, ve aslında dikkat etmen gereken de bu.

Yıllar boyunca her WooCommerce isteği — her cron tetiği, her REST çağrısı, her dahili AJAX turu — Woo’nun tüm blok tiplerini ve desenlerini sessizce kaydediyordu. O istek bir blok render edecek diye değil; eklenti, eklentilerin başlama biçimiyle başlıyordu ve blok kaydı bu başlamaya bağlıydı. Maliyet çağrı başına küçük, yoğun bir mağazanın günü boyunca ise büyüktü.

11.1 bu bağı çözüyor. Sana tam olarak neyin değiştiğini, küçük uyumluluk riskine değecek olan takasın neden mantıklı olduğunu ve eklenti kodunun bilmesi gereken tek filtreyi anlatayım.

Asıl yeni olan ne

Duyuru 31 Ağustos 2026’da Raluca imzasıyla WooCommerce developer blogunda yayımlandı: WooCommerce 11.1 skips block registration on non-rendering requests. 18 Ağustos’taki ön sürüm notu da aynı değişikliği doğruluyor ve 11.1 final tarihini 1 Eylül 2026 olarak koyuyor.

Mekanizma BlockRegistrationContext adında yeni bir bekçi sınıfı. Her istekte, bu belirli çalışma yolunun blok render edip düzenlemeyeceğine karar veriyor. Cevap hayır ise — cron, AJAX, REST API, Store API — Woo blok ve desen kaydını tamamen atlıyor. Ön yüz sayfa yüklemeleri, wp-admin ve blok düzenleyici eski davranışı koruyor. Gerçekten bloklara ihtiyaç duyan istekler için hiçbir şey değişmiyor.

Raluca’nın ölçtüğü kazanç Store API ve WooCommerce REST isteklerinde 13–18 ms — takımın örneklerinde bu uç noktalarda kabaca %30–42 daha hızlı. Tek bir çağrı için manşetlik bir rakam değil. Ama bunu her ürün okumasıyla, her sepet güncellemesiyle, her ödeme ön kontrolüyle, her zamanlanmış işle, headless bir Next.js önyüzünden gelen her okumayla çarpınca manşetlik bir rakam oluyor. Orta yoğunluktaki bir mağaza günde bunlardan on binlercesini yapıyor.

Tek bir istisna var, o da özenle ele alınması gerekendi: ürün ve varyasyon açıklamaları içlerinde WooCommerce blokları barındırabiliyor. Bu durumda Woo blok tiplerini talep üzerine mevcut woocommerce_short_description filtresi üzerinden kaydediyor; yani açıklamalar ürün REST API’sinden, Store API’den, varyasyon AJAX ucundan ve ürün webhook’larından doğru şekilde render olmaya devam ediyor. Ana isteğin “non-rendering” olması yüzünden açıklama içeriği sessizce bozulmuyor.

Geri kalan her şey için yeni bir filtre var: woocommerce_should_register_blocks. Eklentin gerçekten atlanan bu yollardan birinde blok kaydına ihtiyaç duyuyorsa geri seçebiliyorsun. Filtre plugins_loaded sırasında çalışıyor, dolayısıyla kararın o kadar erken elde edilebilecek verilere dayanmak zorunda — henüz yüklenmemiş seçenekleri sorgulayamazsın, mevcut yazıya bakamazsın.

add_filter(
    'woocommerce_should_register_blocks',
    function ( $should_register ) {
        return my_context_renders_blocks() ? true : $should_register;
    }
);

Değişiklik WooCommerce monorepo’sunda #65922, #65781 ve #66672 pull request’lerinde izleniyor. Takımın konuya ilk bakışı da değil bu — Mart 2025’te özel blok kayıt performansı üzerine bir mühendislik yazısı yayımlamışlardı. 11.1 o yazının karşılığı.

WordPress ve WooCommerce insanlarına ne diyor

Bunu üç grup hemen hissediyor.

Headless ve hibrit mağazalar. Store API üzerinden bir önyüz sürüyorsan — bir Next.js mağaza, bir mobil uygulama, bir POS entegrasyonu — her okumada blok kayıt maliyetini ödüyordun. Bunu kaldırmak, buna en çok ihtiyacı olan kurulum için bedava bir performans kazancı. APM ekranında Store API gecikmesine bakıyorsan, 11.1 senin kodunda tek bir satır dokunmadan grafiği aşağı çekecek.

Action Scheduler yükü ağır siteler. Abonelik yenilemeleri, vergi yeniden hesaplamaları, stok senkronları, envanter aktarımları — wp-cron veya Action Scheduler üzerinden çalışan her şey tanımı gereği “non-rendering” istek. Her biri tam blok kayıt tablosunu başlatıyordu. Artık başlatmıyor. Arka plan işlerinde işçi kutun sürekli kırmızıya yaklaşıyorsa nefesinin genişlediğini görmelisin.

Eklenti geliştiricileri. Çoğunuzun bir şey yapmasına gerek yok. Bir cron işi sırasında WooCommerce bloğu render eden, render edilmiş HTML döndüren özel bir REST ucu barındıran veya blok çıktısı bekleyen bir webhook barındıran bir eklenti geliştiriyorsan uyumluluk riski orada. Filtre ile geri seçmen gerekecek. Ekosistemin geri kalanı bedava kazanç alıyor.

Buradaki geniş desen dikkate değer. Woo son iki sürümdür sessiz bir temizlik yayında — blok tabanlı ürün düzenleyici beta’nın emekliye ayrılması, kararlı feature flag’lerin config hattından çıkarılması, sipariş kalemi silinmesinin daha sıkı ele alınması. Hiçbiri gösterişli değil. Hepsi olgun bir platformu sallanan bir platformdan ayıran türden şeyler. WordPress’in yönetişim katmanının kirasını ödediği yer burası: birileri döngülerin nereye gittiğine bakıp geri alıyor.

Ben olsam ne yapardım (ya da yapmazdım)

Önce staging’de 11.1’e geç — söylemeye gerek yok ama yine de söyleyeceğim çünkü birden çok ajansın “küçük” bir sürümde staging’i atlayıp müşteriye ödemenin kırk dakika neden garip göründüğünü açıkladığını gördüm.

Sonra üç şey yap.

Birincisi, özel kodunu ve must-use eklentilerini grep’le: bir cron geri çağrısında, bir REST controller’da veya bir zamanlanmış aksiyon işleyicisinde Woo blok sınıflarının mevcut olduğunu varsaydığın bir yer var mı? Varsa o bağlam için woocommerce_should_register_blocks filtresini ekle ve true döndür. Dar yap — global olarak geri seçme, yoksa herkes için kazancı çöpe atarsın.

İkincisi, headless veya Store API sürüşlü bir önyüzün varsa ölç. Deploy’dan önce ve sonra Store API okumalarının p50 ve p95 örneğini al. Bu yıl gerçekten ertesi sabah grafikte görebileceğin WordPress performans iyileştirmelerinden biri, ve farkı yakalamaya değer — hem kendi öz güvenin, hem de müşteriye göndereceğin sürüm notu için.

Üçüncüsü, bu yüzden mimarını yeniden yazmaya kalkma. Değişiklik gerçek, ama sırf Store API artık biraz daha hızlı diye sunucu tarafı render’da kalan son parçayı Store API’ye taşımak için bir lisans değil. Bir projenin doğru şekli hâlâ o projenin ihtiyaç duyduğu şekil. Yanlış mimaride %30 daha hızlı bir okuma hâlâ yanlış mimari.

Eklentilerin arka planda blok render ediyorsa geri sayım bugün başlıyor — sert bir kaldırma değil, ama “bloklar her istekte kayıtlıdır” varsayımının artık güvenli olmadığı beklentisi. Bunu şimdi, filtre yardım için orada duruyorken çözmek, altı ay sonra bir destek biletinde keşfetmekten iyi.

Olgunlaşan bir platformda görmeyi sevdiğim türden bir değişiklik: daha az gösterişli kod, daha düşünülmüş bir çıkarma. WooCommerce 11.1 zaten yapılmaması gereken bir işi kaldırıyor ve tüm ekosistem bir tık daha hızlanıyor.