🇬🇧 English: Read this in English →

Her WooCommerce ara sürümü sana iki şeyi birden anlatır: neyin bozulduğunu ve birilerinin sessizce artık tartışılmaz saydığı neyin devreye girdiğini. WooCommerce 10.9.2, 2 Temmuz’da yayımlandı ve kısacık değişiklik notunda tam olarak bu ikisini yapıyor. Değişiklik günlüğüne göz gezdirdiysen muhtemelen “anlık bildirim” ifadesini gördün ve geçtin. Bu bir hata olurdu.

Yirmi yıldır ajansların tam bu tarz sürümlerle nasıl ısırıldığını izliyorum. Başlığın zararsız göründüğü — ofiste kimsenin umursamadığı bir mobil uygulama özelliği — ama gerçek yükün bir veritabanı güncellemesi ve ayarlar SDK’sında ölümcül hata koruması olduğu sürümler. Her ikisi de filodaki her mağazayı etkiliyor.

Bunu bir sürüm notu okuru gibi değil, bir işletmeci gibi oku. İşte neyin değiştiği, neden önemli olduğu ve sabah toplantısından önce ne yapman gerektiği.

Gerçekten yeni olan ne

WooCommerce 10.9.2, iki değişiklik, güvenlik güncellemesi yok, bir veritabanı güncellemesi olan bir ara sürüm. Hepsi bu. Resmi sürüm notlarının tam metni tek ekrana sığacak kadar kısa ve her kelimesi ağır.

İlk değişiklik bir düzeltme. 10.8.x’ten 10.9.x’e yerinde yükseltmelerde bazı mağazalar ölümcül bir hataya çarpıyordu; çünkü eski WC_Settings_Page kod yolu, otomatik yükleyici henüz yetişmeden yeni ayarlar SDK sınıflarına çağrı yapıyordu. Belirti wp-admin’de beyaz ekrandı ve gerçek mağazalarda Class 'Automattic\WooCommerce\Admin\Settings\SettingsSectionRegistry' not found hatasıyla düşüyordu. Tam yeniden üretimi 25 Haziran’da 10.8.1 → 10.9.1 yükseltmesinden sonra yönetim panelini kaybeden bir satıcı tarafından açılan issue #66031‘de görebilirsin. Sürüm notlarının atıf verdiği düzeltme PR #65972: yeni ayarlar SDK sınıflarını savunmacı kontrollerle koru ve kullanımdan kaldırılan Automattic\WooCommerce\Admin\API\Settings sınıfını, 10.8’den kalma REST denetleyici kayıtları güvenle çalışabilsin diye no-op uyumluluk sapağı olarak geri getir.

İkinci değişiklik, madde işareti kılığına girmiş bir politika kararı. PR #66088 — “Özellik bayrağını kullanımdan kaldırarak anlık bildirimleri her zaman etkinleştir”, Hannah Tinkler tarafından yazılıp 1 Temmuz’da birleştirildi — özellik bayrağını FeaturesController’dan tamamen kaldırıyor. Özellik artık depolanan seçenek değerinden bağımsız olarak her zaman true döndürüyor. Yeni bir veritabanı taşıması, wc_update_10902_remove_deprecated_push_notifications_option, yükseltmede çalışıp bazı mağazaların 10.5.0 otomatik yükleme taşımasından beri tuttuğu eski seçenek satırını siliyor. Geriye kalan tek kaçış kapısı bir filtre: varsayılan olarak false döndüren, boolean’a zorlanan woocommerce_enhanced_push_notifications_disabled.

Burada bağlam önemli. Gelişmiş anlık bildirimler 10.9.0’da 23 Haziran’da varsayılan olarak geldi ama 10.9.2 notlarının açıkça yazdığı gibi, beta döneminde bayrağı kapatan mağazalar yükseltmeden sonra da kapalı kaldı. 10.9.2 bu boşluğu kapatıyor. woocommerce.com/document/woo-mobile-notifications adresinde belgelenen özellik, Woo mobil uygulaması 24.9+ sürümünün sipariş, stok ve yorum bildirimlerini Jetpack aracılığı olmadan doğrudan mağazadan almasına izin veriyor. Satıcılar ya hep ya hiç mantığı yerine eşik değerleri alıyor: yüksek değerli sipariş alt sınırı, düşük puanlı yorum tavanı.

Bir özellik bayrağının ölümü: bunu daha önce yaşadık

Şu “özellik bayrağını kaldırıp özelliği kalıcı yapmak” hamlesine bakınca içimden hep aynı şey geçiyor. Bir teknolojinin geçici, opsiyonel, “istersen kapat” hâlinden çıkıp platformun sabit bir parçası hâline gelmesi — ya da tersi, bir kaçış kapısının duvara dönüşmesi — sektörde defalarca gördüğüm bir kalıp. En net örneğini Flash’ın ölümünde yaşadım. Yıllarca ActionScript ile animasyon ve etkileşim ürettim; Flash bir gün “opsiyonel eklenti”ydi, sonra tarayıcılar tek tek bayrağın arkasına aldı, sonra bayrağı da kaldırdı, ve bir sabah kaçış kapısı diye bir şey kalmadı. O gün geldiğinde hazır olmayan herkes, üzerine yıllarını verdiği işi bir daha açamadan izledi.

Buradaki ders şu: bir platform bir özelliği bayrağın arkasından çıkarıp “her zaman açık” yaptığında, sana aslında bir tarih veriyor. Bugün elindeki tek kaçış kapısı bir filtre, ve filtreler kararlı arayüzler değildir; onlar da bir gün kullanımdan kaldırılabilir. Flash’ın sana öğrettiği şey neyse WooCommerce’in bu sürümde söylediği de o: geçici olana yaslanma, kalıcı olanı planla. Anlık bildirimler artık kalıcı; sen de politikanı buna göre kur.

WordPress ve WooCommerce ekipleri için neden önemli

Farklı sebeplerle iki kitle önemsemeli.

Bir filoyu işleten ajanslar 10.9.2’yi zorunlu bir yükseltme olarak görmeli, “olsa iyi olur” olarak değil. Ölümcül hata koruması, tam olarak sıradan bir salı gecesi güncellemesini iki saatlik bir olaya çeviren düzeltme sınıfı; çünkü çökme wp-admin’de, yani bir şeylerin ters gittiğini fark ettiğin yüzeyde oluyor. Yükseltme yordamın hâlâ üretim ortamında “Güncelle”ye tıklayıp umut etmekten ibaretse bu sürüm o yordamı değiştirmek için iyi bir bahane. Aşamalı dağıtımlara geç, 10.9.0 ya da 10.9.1’de kalan mağazaları kısa tut ve çekirdek eklenti güncellemesinden sonra opcache’i temizle.

Eklenti yazarları ve dahili Automattic\WooCommerce\Admin\API\Settings sınıfına dayanmış olan herkes bu ifadeyi kaçırmamalı. WooCommerce sana, sürüm notundaki tek satırla, eski bir REST denetleyicisini kaldırdıklarını ve uyumluluk sapağını yalnızca silince yükseltme sırasında ölümcül hataya yol açtığı için tuttuklarını söylüyor. O sapak kararlı bir arayüz değil. Yaşam desteği. Eklentin bu sınıfı üretiyorsa, 28 Temmuz’daki 11.0 sapağı seninle birlikte götürmeden önce hemen yeniden yaz. Aynı disiplin SDK öncesi ayar yollarına dokunan her şey için geçerli — WooCommerce açıkça göç ortasında ve göç ortası, üçüncü taraf kodun mahsur kaldığı yerdir.

Mobil öncelikli işletme ekibi olan mağaza sahipleri de dikkat etmeli. Mağazan 10.9.0’da anlık bildirimler bilinçli olarak kapalıyken çalışıyorduysa, o “kapalı” ayarı yükseltmede etkisiz hale gelmek üzere. Taşıma seçeneği siliyor; FeaturesController artık onu okumuyor. 10.9.2’den sonra özelliği kapalı tutmanın desteklenen tek yolu woocommerce_enhanced_push_notifications_disabled filtresine bir kayıt eklemek. Bu adımı atlarsan Woo mobil uygulamasından sonraki satıcı girişinde mağaza onay vermediğin bildirimleri neşeyle fırlatmaya başlayacak. Felaket değil ama sessizlik isteyen bir müşteriye açıklaması utandırıcı.

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

Üç somut adım.

Birincisi, yükseltmeyi gerçek üretim veritabanı üzerinden hazırlık ortamında koştur. Veritabanı taşıması küçük ve idempotent, ama 10.9.1’deki ölümcül hata sınıfı bize 10.8.x yükseltme yollarının yalnızca gerçek sınıf otomatik yükleyici durumu altında ortaya çıkan sürprizler taşıdığını öğretti. 10.9.2’nin temiz kurulumu bir test değildir; üretimin bir kopyası testtir. wp-admin’in yüklendiğini, ayar sekmelerinin çizildiğini doğrula, sonra üretime geç.

İkincisi, anlık bildirim politikasını mağaza bazında, arayüzde değil kodda kararlaştır. Bunu taşımadan sonra seçenek değerinin ne olduğuna bırakma. Özelliği isteyen mağazalar için: hiçbir şey yapma, 10.9.2’yi yayınla, yola devam et. Müşterinin sessizlik istediği mağazalar için: woocommerce_enhanced_push_notifications_disabled filtresinden true döndüren tek satırlık bir mu-plugin bırak. Sürüm kontrollü, gözden geçirilebilir, gelecekteki yükseltmelerden sağ çıkar. Bu iş için arayüz düğmesine yaslanma — WooCommerce az önce düğmeyi ayağının altından çekebileceğini kanıtladı.

Üçüncüsü, kod tabanını SDK öncesi ayar isim alanlarına yapılmış her türlü kalıntı referans için tara. Sen ya da baktığın bir eklenti Automattic\WooCommerce\Admin\API\Settings‘i doğrudan üretiyorsa ya da belgelenmiş API’nin parçası olmayan dahili ayar sınıflarını genişletiyorsa, yeniden yazımı 11.0 penceresine değil şu anki 10.9 penceresine planla. 10.9.2’deki sapak bir pist ve pist kısa. WooCommerce 11.0, 28 Temmuz’da, blok tabanlı ürün düzenleyici betasının kaldırılması ve ürün nesne önbelleğinin varsayılan olarak etkinleşmesiyle birlikte geliyor. Ayrıca yükseltmeden sonraki gün bir ayarlar sınıfı gerilemesini keşfetmek istediğin bir sürüm değil.

10.9.2’deki her şey sessiz. Zaten mesele bu. Bu tarz ara sürümler olgunluk katmanını çalıştırmanın bedelidir — yönlendirmeler, taşımalar, uyumluluk sapakları, filtre biçimindeki kaçış kapıları. Kimse ana konuşmada bunlardan bahsetmiyor ve tam olarak ilk on bin alışverişçin geldiği gün WooCommerce’in çalışmaya devam etmesini sağlayan şey bunlar.

Filoyu güncelle, gereken yere filtreyi bırak ve 11.0 planlamasına geç.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Close Search Window