Medya Kütüphanesi Sonsuz Kaydırma 7.1’de Varsayılan

🇬🇧 English: Read this in English →

Beş yıl önce erişilebilirlik ekibi Medya Kütüphanesi’nden bir özelliği çekip aldı, çünkü klavye kullanıcıları kaydırılarak gelen görsellere ulaşamıyordu, ekran okuyucularının bu yeni içeriği duyuracak bir yolu yoktu ve her açılan sayfada tarayıcı geçmişi sessizce kırılıyordu. WordPress 5.8’di, Temmuz 2021. Çözüm sade: bir filtrenin varsayılanını true‘dan false‘a çevir, sonsuz kaydırmayı geri isteyen için tek satırlık kapıyı da açık bırak. Ve neredeyse hiç kimse o kapıyı aralamadı — ben de dahil.

Şimdi WordPress 7.1 durumu geri çeviriyor. Medya Kütüphanesi ızgarasında sonsuz kaydırma yeniden varsayılan hâline geliyor. Ama dikkat et, bu 5.8 kararının kızgın bir geri alınması değil — asıl güzel olan, kararın etrafına örülmüş yönetişim katmanı. Filtre hâlâ tepede duruyor. Filtrenin altında yeni bir kullanıcı bazlı tercih var. Vaktinde açık kalmayı seçmiş siteler açık kalıyor, yeni siteler doğrudan sonsuz kaydırmaya kavuşuyor ve kimsenin ekstra bir şey düşünmesine gerek kalmıyor.

Küçük ama son derece WordPress’e özgü bir hamle: beş yıllık bir döngü, üç seviyeli geçersiz kılma zinciri, kırılan tema yok, kırılan eklenti yok, ve sayfalamayı geri isteyen editör için profil sayfasında sessizce bekleyen bir onay kutusu. Açık konuşayım, işte bu sıkıcılık benim en sevdiğim türden. Pazartesinin on dakikasını hak ediyor.

Gerçekten yeni olan ne

“Media Library infinite scrolling is now enabled by default, with a per-user opt-out” başlıklı geliştirici notu Make/Core’da Marin Atanasov tarafından 23 Temmuz 2026’da yayımlandı; trac bileti #65564 işi takip ediyor. Değişiklik şu an beta aşamasında olan WordPress 7.1’de yer alıyor; GA ise sürüm partisi programına göre 19 Ağustos 2026.

Mekanik gayet net. WordPress 5.8’de sonsuz kaydırmayı varsayılan olarak devre dışı bırakmak için tanıtılan ama tekli bir kancayla geri açılabilir bırakılan media_library_infinite_scrolling filtresi, aynı adla ve aynı imzayla kalıyor. Değişen tek şey varsayılan dönüş değeri: false‘tan true‘ya dönüyor. Filtre sözleşmesinde başka hiçbir şey oynamıyor — ki eski entegrasyonların hayatta kalmasının sebebi tam olarak bu.

Filtrenin altına yeni bir kullanıcı bazlı tercih yerleşiyor. upload_files yetkisine sahip her kullanıcı, profil ekranında “Disable infinite scrolling in the Media Library grid view” etiketli bir onay kutusu görüyor (varsayılan olarak işaretsiz). Tercih, infinite_scrolling kullanıcı meta anahtarında dize olarak, 'true' veya 'false' değerleriyle saklanıyor. Çözünürlük sırası yukarıdan aşağıya: önce media_library_infinite_scrolling filtre geri çağrısı, sonra kullanıcının tercihi, en sonda da yeni varsayılan olan true. Filtreden açıkça false dönen bir site hâlâ sayfalama alıyor — yani site sahibinin çağrısı kullanıcınınkini, kullanıcınınki de çekirdek varsayılanını geride bırakıyor. Temiz bir hiyerarşi.

Geriye dönük uyumluluk aslında hikâyenin tamamı. Filtreye hiç dokunmamış siteler artık sonsuz kaydırmaya sahip. add_filter( 'media_library_infinite_scrolling', '__return_true' ); ile açık pozisyona geçmiş siteler hiçbir şey hissetmiyor. __return_false ekleyenler de öyle. Kullanıcı meta göçü çalışmıyor, yani veritabanında sessizce dolaşan bir betik yok. Değişiklikte adı geçen katkıcılar arasında youknowriad, khokansardar, wildworks, davidbaumwald, joedolson ve sabernhardt var — o listedeki erişilebilirlik ekibi isimleri başlı başına bir sinyal, çünkü beş yıl önce bu özelliği çekenlerin şimdi geri koyanlar olması, kararın ciddiye alındığını gösterir.

5.8 kararının neden var olduğuna kısa bir mola değer. Trac biletleri #50105 ve #40330 gerekçeyi topluyor: sonsuz kaydırma, ilk sayfa yüklendikten sonra eklenen öğelere yalnızca klavye kullanan kişilerin ulaşmasını fiilen imkânsız kılıyordu, ekran okuyucularının bu yeni içeriği duyuracak bir düzeni yoktu, tarayıcının geri düğmesi kaydırma konumunu veya sorgu durumunu geri getirmiyordu ve büyük katalogda yüzlerce tam boy küçük resmi yüklemek belleği zorluyordu. Beş yıl sonra JavaScript katmanı bu listenin mekanik kısımlarını çözecek kadar yeniden yazıldı, ama erişilebilirlik ödünü hâlâ gerçek — o yüzden sessiz bir dönüş değil, onay kutusu.

Belleğe saygıyı zor yoldan öğrenenlerdenim

O listedeki son maddeye — “yüzlerce tam boy küçük resmi yüklemek belleği zorluyordu” — takılıp kaldım biraz. Çünkü ben bu sektöre 4 megabayt RAM’in lüks sayıldığı bir Mac Plus’la girdim. O makinede bir görseli açmadan önce iki kere düşünürdün; belleği doldurdun mu makine seni bomba gibi bir sistem hatasıyla karşılardı, kaydetmediğin ne varsa uçardı. Belleğin sonlu bir kaynak olduğunu, ekranın bir yerlerinde durmadan biriken görünmez bir maliyet olduğunu iliklerime kadar o günlerde öğrendim.

Bugün 32 gigabayt RAM’li dizüstülerde çalışıyoruz ve “sonsuz kaydırma” tam da o eski refleksi köreltiyor: aşağı indikçe tarayıcı sessizce yüz, iki yüz, beş yüz küçük resmi hafızada tutmaya devam ediyor ve kimse fark etmiyor — ta ki dört yaşındaki bir dizüstü sekmesi takılana kadar. Sonsuz kaydırmayı severim, ama onun bedava olmadığını bilerek severim. İşte kullanıcı bazlı vazgeçmenin varlık sebebi tam da bu: makinesi güçlü olan akmaya devam etsin, belleğiyle baş başa kalan da sayfalamaya sığınsın. Otuz yıl sonra aynı ders yine karşımda, sadece adı değişmiş.

WordPress ve WooCommerce’te çalışıyorsan bunun anlamı

Günde on iki görsel yükleyen bir yayın ekibiysen, değişim senin için görünmez. Büyük bir kütüphanede gezinen çoğu editörün zaten beklediği davranıştı bu. Beş yıllık sayfalama, çoğu insanın filtreleri daraltıp aradığını bulana kadar “daha fazla yükle” düğmesine bastığı bir hata gibi hissettiriyordu. 7.1 sonrası ızgara akmaya devam ediyor, sen de fark etmiyorsun bile.

Ama beş haneli bir görsel kütüphanen varsa — ürün fotoğrafları, varyasyon örnekleri, yaşam tarzı çekimleri, Medya’da unutulmuş vergi faturası PDF’leri — hikâye karışıyor. O ölçekte sonsuz kaydırma, tarayıcı eski yüklemelere doğru ilerledikçe ciddi bir bellek ayak izi biriktirebilir; özellikle RAM’i düşünülerek seçilmemiş mağaza yöneticisi dizüstülerinde. Kullanıcı bazlı vazgeçme tam da bunun için tahliye vanası. Ağırlıklı masaüstünden çalışan bir mağaza sahibi muhtemelen açık ister. Gün boyu ızgarada yaşayan, dört yaşındaki MacBook’lu bir mağaza yöneticisi istemeyebilir. İkisi de tercih ettiği davranışa bir profil-sayfası onay kutusu uzaklıkta — ve mesele tam da bu esneklik.

Çok sayıda müşteri sitesi yönetiyorsan risk yüzeyi küçük ve net. Sayfalamayı varsayan bir eklenti — özel bir Medya Kütüphanesi filtre paneli, sabit sayfa boyutu bekleyen bir toplu işlem arayüzü, sayfalanmış ızgarayı kazıyan eski bir DAM entegrasyonu — gözden geçirilmeli. Filtre hâlâ dinlemede, yani gerektiğinde tek satırlık düzeltme cebinde. Ama uyumsuzluğu, 7.1 GA’dan üç hafta sonra bir müşterinin varlık onay akışının sessizce şekil değiştirdiğini görerek keşfetmek — ideal yol bu değil, inan bana.

Daha geniş sinyal ise o yönetişim katmanı. WordPress’in neredeyse her sürümünde tekrar eden desen bu: bir varsayılanı değiştir, filtreyi bozma, altına kullanıcı bazlı bir tercih koy, önceki tercihlere saygı göster. Hiçbir şey kırılmıyor, hiçbir göç betiğine gerek kalmıyor. Davranış yarın farklı, kod yolu aynı. Gösterişli değil — ama 20 yıllık sitelerin temiz güncellenmesinin sebebi tam da bu gösterişsizlik.

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

Bu hafta staging’de, Gutenberg trunk ya da bir WordPress 7.1 beta yapısında yapmaya değer üç şey var. Birincisi: yönettiğin her sitenin eklenti ve temalarında media_library_infinite_scrolling dizesini ara. Bulduğun her şey ya 7.1 öncesinden gelen açık pozisyon (yeni varsayılana düşmek istiyorsan 19 Ağustos’tan sonra silmen güvenli) ya da gerçek bir sebeple kapatılmış (dokunma). Filtreye dokunmadan sayfalama varsayan her şey, sen bakana kadar görünmez kalır.

İkincisi: gerçek bir Medya Kütüphanesi’ne sahip bir müşteri sitesini al — üç binden fazla öğe — ve ızgarayı 7.1 beta’da aç. En dibe kadar kaydır. Tarayıcının görev yöneticisinden bellek kullanımını izle. Yükleme deseninin, bir mağaza yöneticisinin normal bir dizüstünde yaşamasını istediğin şey olduğunu doğrula. Yanıt hayırsa, müdahalenin site geneli mi (bir mu-plugin’de false döndüren filtre) yoksa kullanıcı bazlı mı (o rol için belgelenmiş profil-sayfası onay kutusu) olacağına karar ver. Reflekse göre değil düşünerek karar ver — bir fotoğraf portföyü ile bir depo kataloğu için doğru yanıt aynı değil.

Üçüncüsü: ızgarayı manipüle eden herhangi bir yönetim tarafı eklentin varsa — filtre açılırları, özel sütunlar, toplu işlemler, “sayfadaki hepsini seç” arayüzü — yeni varsayılan etkinken 7.1 beta üzerinde regresyon testinden geçir. Sayfa sınırını varsayan toplu işlemler yeniden kapsanmalı, ya da arayüz “hepsini seç”in ızgara hiç bitmediğinde ne demek olduğunu açıkça anlatmalı.

Yapmayacağım iki şey de var. Medya Kütüphanesi’nin “değiştiği” konusunda müşteriye duyuru hazırlamam — değişiklik neredeyse her editör için görünmez ve istisnalar, iş akışının sayfalamaya bağlı olduğunu zaten bildiğin yerler. Site geneli ayar için arayüz düğmesi ekleyen bir eklenti de kurmam; filtre tek satır, ve sonraki beş yıl eklenti güncelleme kuyruğunda değil, sitenin kendi mu-plugin klasöründe yaşamalı. Bir de bunu bugünkü WooCommerce 11.0 güncelleme penceresiyle üst üste yığma — WooCommerce 11.0 ayrı bir değişiklik penceresi, WordPress 7.1 ise 19 Ağustos’ta iniyor. Üç hafta arayla, sırayla çalıştır.

Her sürüm döngüsünün bunun gibi bir tanesi olur — bir filtreye, bir kullanıcı tercihine ve korunan geçersiz kılma zincirine sarılı küçük bir varsayılan değişikliği. Anlatmaya değecek pek bir dram yok, ve 2015’te kurduğun bir WordPress sitesinin 7.1’e sorunsuz güncellenmesinin nedeni tam olarak bu.