Hayatımda gördüğüm en pahalı görsel yüklemesi en büyük dosya değildi. Londra’da bir ofisin üçüncü katında, basın ambargosunun kalkmasına üç dakika kala başarısız olan 12 MB’lık bir JPEG dosyasıydı. Yazar yayımla düğmesine bastı, yükleme zaman aşımına uğradı, tarayıcı genel bir hata fırlattı ve sekiz hafta hazırlığını yaptığımız lansmanın baş yazısının öne çıkan görselini kaybettik. Yirmi yıl sonra da kalıp aslında değişmedi: kararsız bir kablosuz ağ hücresi, havada kalan bir taslak, yeniden deneme yok, iz yok.

Bu hafta yayımlanan Gutenberg 23.4 sessiz sedasız bu meseleye eğiliyor. Pazarlama başlığıyla değil, yeni bir yapay zekâ düğmesiyle değil — editörün, kullanıcıların çoğunun bozulmadan fark etmediği kısmıyla. Yükleme kuyruğu artık ağ koptuğunda durup geri geldiğinde kaldığı yerden devam ediyor, üstel geri çekilme ile yeniden deneme yapıyor ve istemci tarafı işleme hattını kilitleyecek kadar büyük görselleri o hattan geçirmiyor. Bu, daha önce yanmış editörlerin güvenini yavaş yavaş kazanan türden bir düzeltme.

Bunu ajans koltuğundan yazıyorum, çekirdek katkıcı koltuğundan değil. O yüzden takıldığım soru pratik: bu değişikliklerin hangilerine bu hafta üretimde güvenebilirim, hangilerine gözümü açık tutmam gerekiyor ve editör deneyimi gerçekten yönettiğimiz haber odaları ve mağazalar için nerede iyileşiyor.

Gerçekten ne yeni

Gutenberg 23.4, 17 Haziran 2026’da yayımlandı; özetini ramonopoly Make/Core üzerinde Gutenberg 23.4’te yenilikler başlığıyla yayımladı. Sürüm, halen 33 görevin 23’ü tamamlanmış olan WordPress 7.1 için istemci tarafı medya yinelemesi izleme konusunun tam ortasında oturuyor; başlıklar açık: dayanıklı yükleme, HEIC desteği, Ultra HDR korunumu ve eşzamanlı yükleme başarımı.

Medyadaki manşet değişiklik, değişiklik kaydında “Upload Media: Add retry with exponential backoff and network resilience” olarak geçen #76765 numaralı çekme isteği. Yalın haliyle: yükleme kuyruğu artık sunucu kaynaklı bir hata ile ağ katmanındaki bir kopuşu birbirinden ayırıyor, cihaz çevrimdışı olduğunda kuyruğu tutuyor ve bağlantı geri geldiğinde yazardan dosyayı yeniden seçmesini istemeden kaldığı yerden devam ediyor. Başarısız aktarımlar artan aralıklarla yeniden deneniyor, yani aynı 8 MB’lık JPEG ile titrek bir hücreyi her iki saniyede bir dövmüyorsunuz.

Onunla birlikte gelen değişiklik şu: “Çok büyük görselleri istemci tarafı işlemeden dışarıda tut.” WordPress 7.0, istemci tarafı görsel sıkıştırmayı WebAssembly ve wasm-vips ile çekirdeğe taşıdığından beri editör, görseli sunucuya göndermeden önce tarayıcıda yeniden boyutlandırıyor. Bu güzel; ta ki bir telefon size 60 megapikselli bir HEIC verene ve sekme donana kadar. Gutenberg 23.4 WASM hattının çiğnemeye çalışacağı boyuta bir tavan koyuyor ve bu tavanın üzerini sunucu tarafı işlemeye düşürüyor. Yükleme ilerleme bildirimleri de artık parti sayılarını gösteriyor; on iki fotoğrafı sürükleyip bırakan bir yazar kaç tanesinin bittiğini ve kaçının takılı bir dosyanın arkasında beklediğini görebiliyor.

Bunların altında bir de eş zamanlı düzenleme ipliği var ve bunun WordPress 7.1 döngüsündeki ağırlığını gözden kaçırmak kolay. Eş zamanlı düzenleme 7.0’dan çıkarıldıktan sonra Gutenberg 23.4 ayrı bir belge kalıcılık uç noktası (PR #78891), blok ağacı değiştiğinde işbirlikçi yer paylaşımının yeniden çizilmesi (PR #78636), bağlantıyı boğan yavaş yoklama süzgeçlerinin önlenmesi (PR #78811), CRDT yazım yarış durumu düzeltmesi ve Yjs geri al yöneticisi düzeltmesini getiriyor. Sunuculuk takımının gerçek müşterilerle eş zamanlı düzenlemeyi sınama çağrısı 15 Temmuz’daki WordPress 7.1 Beta 1’ine kadar sürüyor; bu yamaların canlı bir barındırmada göz gezdirilmesine ihtiyacı var.

Eklenti yazarları için yüzeye çıkacak bir şey daha: React 19, bu sürümde yeniden deneysel bir bayrağın arkasında. Gutenberg’in Haziran başında React 19 yükseltmesini geçici olarak geri almasının ardından 23.4 size /wp-admin/admin.php?page=experiments-wp-admin üzerinden açma imkânı veriyor; böylece 7.1’de varsayılan olarak gelmeden önce blok kodunuzu yeni çalışma zamanına karşı doğrulayabilirsiniz.

WordPress ve WooCommerce ekipleri için neden önemli

İçerik ağırlıklı bir site işletiyorsanız — haber odası, dergi, kurs platformu — yükleme kuyruğu, farkında olsanız da olmasanız da editöryel iş akışınızın bir parçası. Yazarlar dosyaları parti parti bırakır. Etkinliklerde paylaşımlı kablosuz ağda, trende, otel ağında çalışırlar. Her yeniden deneme, her “bu sayfadan ayrılmak istediğinizden emin misiniz” uyarısı, sessizce kaydolmamış her öne çıkan görsel, içerik yönetim sisteminizi sevmesi gereken editörlerin güvenini biraz daha aşındırır. Ağa dayanıklı yüklemeler, editör deneyiminin görkemsiz bileşik faizidir.

WooCommerce mağaza sahipleri için aynı değişiklik farklı bir biçim alıyor. Ürün fotoğrafı yüklemeleri çoğu zaman bir telefondan, deponun içinde dolaşarak onlarca dosyalık partiler halinde çalışır. Kataloğun arkasındaki yazar nadiren bir yazılımcıdır. Bir 4G aktarımının düşmesine dayanan ve on beş görselden hangisinin hâlâ beklemede olduğunu söyleyen bir kuyruk, bir cuma öğleden sonrasının kullanılabilir geçmesi ile her şeyi yeniden yapmak arasındaki farktır. Büyük görsel kapısı burada da önemli: telefonlar artık rutin biçimde 50 megapiksel üstü dosya üretiyor ve hepsini istemci tarafında yeniden boyutlandırmaya çalışmak, katalog işinde sekmeleri gerçekten yanıt vermez hâle getiren bir nedendi.

Çoklu site veya barındırılmış altyapılar yöneten ajanslar için planlanması gereken karar bu kapıyla ilgili. Çok büyük bir görsel sunucu tarafı işlemeye düştüğünde yük PHP ve Imagick’in (veya gittikçe daha çok, önerilen libvips görsel düzenleyici arka ucunun) üstüne biner. Barındırma katmanınızın boş alanı varsa bu sorun değil. Sıkı bir memory_limit ile yalın bir paylaşımlı barındırmada koşuyorsanız, büyük DSLR yüklemelerinde bu yedek yolun sessizce başarısız olmayacağından emin olmak için tam sırası.

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

Gutenberg eklentisini bu hafta bir hazırlık ortamına kurar, ekibinizdeki en çok yükleme yapan iki üç editörün önüne koyardım. Bir telefondan çektikleri fotoğraflarla dolu bir klasörü sürükleyip bırakıp ardından dizüstünün kapağını kapattıklarında ne olduğunu izleyin. Önemli olan sınama bu. Bulduğunuz hata aslında bir hata olmayacak — şimdiye kadar sizin ve editörün açıkça konuşmadığı bir iş akışı beklentisi olacak.

React 19 deneysel bayrağını üretim sitesinde açmazdım. Bayrağın bütün amacı, üçüncü taraf blok yazarlarının 7.1’de varsayılan olmadan önce doğrulama yapmasını istemesi. Bir blok kütüphanesi koruyorsanız bu doğrulamayı şimdi yapın ve sorunları açın — bu ay bir eklenti yazarının yapabileceği en faydalı şey bu. Üretim siteleri beklesin.

Gerçek bir editöryel ekibiniz varsa sunuculuk takımının eş zamanlı düzenleme sınama çağrısına da ciddi biçimde bakardım. 23.4’teki yamalar, 15 Temmuz’daki Beta 1’den önce gerçek dünya koşullarına maruz kalması gereken türden ağ katmanı düzeltmeleri. Erişim çalışmasına katılmanın maliyeti çok düşük, üstelik ekibinizin er ya da geç sorulacağı özellik hakkında size erkenden görünürlük kazandırıyor.

Yapmayacağım tek şey ise bir Gutenberg ara sürümünün gücüne yaslanarak müşterilere fazla söz vermek. 23.4 bir özellik fırlatması değil, güven inşa eden bir sürüm. Bunu bir dönüşüm olarak değil, “editör artık titrek ağlarla daha iyi başa çıkıyor” diye anlatın. Dönüşüm, WordPress 7.1’in birikimli yönü ve tam olarak olması gereken yerde — çoğu kullanıcının yalnızca bozulduğunda fark ettiği parçalarda — görünüyor.

Yirmi yıl sonra da sıkıcı düzeltmeler güven yarışını kazanmaya devam ediyor. Dayanıklı medya yüklemeleri tam da ihtiyacımız olan o sıkıcı düzeltme.

Bir yanıt yazın

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

Close Search Window