WordPress 7.1 Site Duzenleyici Ekran Suzgecleri: Ilk Bakis

🇬🇧 English: Read this in English →

Son on yılda teslim ettiğim her kurumsal WordPress projesinin bir noktasında aynı konuşma yaşanıyor. Müşterinin içerik ekibi Sayfalar ekranına, Şablonlara veya Desenlere bakıyor ve aynı soruyu soruyor: “Bu sütunları gizleyebilir miyiz, gerçekten önemsediğimiz tarihe göre sıralayabilir miyiz ve sahibi olmayan taslakları göstermeyi bırakabilir miyiz?” Yıllardır cevap aynıydı: özel API’lere dayanan, bir sonraki sürümde sessizce ölen ve bakımı devralan kişi tarafından baştan yazılması gereken küçük bir JavaScript yığını.

WordPress 7.1 bu konuşmaya nihayet gerçek bir cevap veriyor. Dört yeni PHP süzgeci, Site Düzenleyici’nin DataViews ekranlarını — Sayfalar, Şablonlar, Şablon Parçaları, Desenler — sunucu tarafından yapılandırmanıza izin veriyor. Üstelik pre_get_posts ve manage_edit_columns‘un on beş yıldır hayatta kaldığı biçimde, güncellemelerden sağ çıkacak bir şekilde. Sarmalanacak React ağacı yok. Tahmin edilecek özel kanca yok. Ekran başına bir süzgeç, ortak bir yapılandırma nesnesi, onu değiştirmek için dört dar yöntem.

Bu, aşağı akışta büyük etkisi olan küçük bir geliştirici notu. WordPress üzerine yayın süreçleri kuran ajanslar için, yönetim panelinde her gün çalışan insanlar açısından 7.1’de yer alan en yararlı iki üç şeyden biri bu.

Aslında ne yeni

André Maneiro’nun 31 Temmuz 2026’da Make/Core’da yayımlanan ve @ntsekouras ile @priethor tarafından incelenen Filtering Site Editor Screens in WordPress 7.1 geliştirici notu, Site Düzenleyici’deki dört DataViews ekranını birebir yansıtan dört yeni PHP süzgeci getiriyor:

• get_entity_view_config_postType_page — Sayfalar ekranı
• get_entity_view_config_postType_wp_template — Şablonlar ekranı
• get_entity_view_config_postType_wp_template_part — Şablon Parçaları ekranı
• get_entity_view_config_postType_wp_block — Desenler ekranı

Her süzgeç bir Gutenberg_View_Config_Data nesnesi alıyor ve ilgili ekranın dört yönünü yapılandırmanıza izin veriyor. default_view DataViews yerleşimini denetliyor — hangi alanlar görünür, sıralama nasıl, varsayılan görünüm türü ne (tablo, ızgara, liste). default_layouts kullanıcının hangi yerleşimler arasında geçiş yapabileceğini belirliyor. view_list önceden yapılandırılmış kenar çubuğu (“Tümü”, “Yayımlanan”, “Taslaklar” gibi). form ise Hızlı Düzenleme formunu yapılandırıyor: hangi alanların hangi sırada, varsayılan olarak açık gelip gelmeyeceği. Dördü de bildirimsel dizilerden ibaret. React gerekmiyor.

Yapılandırma nesnesi, varsayılanlarla nasıl birleşeceğinizi belirleyen dört değiştirme yöntemi sunuyor. merge() yeni girdileri ekliyor, mevcutlara dokunmuyor. remove() belirli girdileri anahtarına göre siliyor. replace() indeksli bir diziyi bütünüyle değiştiriyor. set() ise balyoz — güncellenen el kitabına göre “o anahtarda ne varsa bırakıyor”. İsimlendirme disiplini önemli: küratörlük çalışmalarının çoğu için varsayılan tercih merge, set ise müşteriden önce yazılı onay istediğiniz yer.

Sürecin tamamı, André Maneiro’nun (oandregal) 16 Mart 2026’da açtığı #76544 “Register view/form config in the server” takip başlığında yaşıyor. Bu başlık bu yüzeyi sevk eden dört birleşmiş PR’ye bağlanıyor: Sayfalar için #76573, Şablonlar için #76622, Desenler için #76734, Hızlı Düzenleme form yapılandırması için #76953 ve üzerine süzgeçlenebilir PHP API’sini ekleyen #78977. Tamamı, sürüm partisi takvimine göre 19 Ağustos 2026’da yayımlanacak WordPress 7.1 GA ile geliyor.

Bu sürümde gelmeyen şey: tıklayarak bu süzgeçleri kaydeden bir denetleyici arayüzü yok. Bu sürümün amacı sunucu tarafı ekleme noktası. Eninde sonunda bir ayarlar ekranı sarmalayıcısı gelirse, bu API’nin üstüne gelecek. Onu beklemeyin; sözleşme süzgeçtir.

Bu WordPress ve WooCommerce insanları için neden önemli

Son beş yılda WordPress üzerine kurduğum her ciddi yayın sürecinde aynı duvara toslandı: Site Düzenleyici ekranları belirli bir görüşle geliyor, müşteri farklı bir görüş istiyor. Mağazanın içerik yöneticisi Sayfalar’ı “oluşturulma tarihine” değil “son değişiklik tarihine” göre sıralı istiyor. WooCommerce merchandiser’ı Desenler’in yalnızca ürün kartı varyantlarını göstermesini istiyor. Hukuk ekibi Şablonlar’a özel alandan çekilen bir “Sahip” sütununun eklenmesini istiyor. 7.1’e kadar, bunların her biri özel bir yuvaya kanca atan, mağaza şeklinin değişmemesi için dua eden ve her Gutenberg sürümünde bir kere daha kırılan bir JavaScript dosyasında yaşıyordu.

Bunu sunucu tarafı PHP süzgeçlerine taşımak, WordPress’in bir özelleştirme yüzeyinin on yıl hayatta kalmasını istediğinde yaptığı aynı yönetişim hamlesi. register_post_type, pre_get_posts, manage_edit_{$post_type}_columns, rest_prepare_{$post_type} — hepsi sıkıcı, hepsi dayanıklı, hepsi de sevk edildikleri günkü şekilde hâlâ çalışıyor. Site Düzenleyici ekran süzgeçleri de aynı biçime oturuyor. Müşterinin mu-plugin klasöründeki on satır PHP, artık WordPress 8.5’te de düzenli kalacak bir Sayfalar ekranı satın alıyor.

WooCommerce ajansları için özellikle ilgi çekici ekran Desenler. Blok temalara yaslanan mağazalar onlarca desen biriktiriyor — kahraman varyantları, ürün kartları, referans yerleşimleri, kampanya afişleri. Varsayılan Desenler ekranı bunların tümünü tek bir ızgaraya döküyor. get_entity_view_config_postType_wp_block ile iş bağlamına göre kenar çubuğu görünümleri kaydedebilir (“Ürün kartları”, “Ana sayfa bölümleri”, “Hukuki alt bilgiler”), alfabetik yerine “en son kullanılan”a göre sıralayabilir ve merchandiser’ın ihtiyaç duymadığı alanları gizleyebilirsiniz. Bir Gutenberg ekranını geliştirici aracından yayın aracına çeviren küratörlüğün şekli budur.

Daha geniş sinyal şu: WordPress 7.1, Site Düzenleyici çevresindeki dikişleri sessizce sertleştirmeye devam ediyor. Bu geliştirici notu, Design System Theming ile aynı gün, Abilities API çalıştırma yaşam döngüsü süzgeçlerinden iki gün sonra düştü. Üç ayrı yüzey, üç ayrı ekip, tek bir ortak örüntü: yönetim paneline gerçek bir uzatma dikişi ver, eklentiler de özel-API hack’lerini emekliye ayırsın. Bunun karşılığını aldığımız yıl bu.

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

Önümüzdeki üç hafta için, WordPress 7.1 Beta 4 hazırlama kopyasında veya bir Playground blueprint’inde sıra ile dört adım. Hiçbirini GA’dan önce üretimde çalıştırmayın.

Birincisi: baktığınız her mu-plugin, alt tema ve yönetim scripti’nde DataViews’ın özel API’lerine erişimi denetleyin. @wordpress/dataviews içine uzanan her şey, varlık deposuna karşı useSelect ile alan süzgeçleyen her şey, düzenleyici yüklenirken JavaScript’ten sıralama zorlayan her şey — listeleyin. Bu, göç envanterinizdir. Bulacaklarınızın çoğu 7.1 GA’dan sonra beş satırlık bir PHP süzgecine daralacak; eklenti derleme adımı da onunla birlikte gidecek.

İkincisi: hazırlama ortamında bir ekranı bir süzgece karşı prototipleyin. Müşteri portföyünüzdeki en düz vakayı seçin — büyük ihtimalle bir yayın sitesindeki Sayfalar ekranı — ve mevcut özelleştirmeyi alan eklemek için merge(), kenar çubuğu görünüm listesini takas etmek için replace() kullanan bir get_entity_view_config_postType_page işleyicisi olarak yeniden yazın. Diğer ekranlara dokunmadan önce, mevcut üretim davranışına göre farkın sıfır olduğunu kanıtlayın.

Üçüncüsü: Site Düzenleyici ekranlarını saran bir yönetim arayüzü olan dağıtılmış bir eklenti (Desen tarayıcısı olan WooCommerce eklentileri, kısıtlı sayfa görünümleri olan üyelik eklentileri, özel Şablonlar süzgeçleri olan DAM entegrasyonları) sürdürüyorsanız, 7.1 GA ile hizalanmış ve mevcut JS’nin yanına PHP süzgeç yolu ekleyen bir sürüm planlayın. JS’yi silmeyin. PHP’yi tercih edilen yol olarak katman, function_exists( 'gutenberg_get_view_config' ) veya 7.1 sürüm kontrolü ile özellik bayrağı koyun, JS de yıl sonuna kadar 7.0 kullanıcıları için yedek olarak düşsün.

Dördüncüsü — olumsuz liste. Tek satış noktası “Site Düzenleyici ekran süzgeçlerini yapılandırmak için arayüz ekler” olan hiçbir eklentiyi kurmayın. Süzgeç ekran başına tek işlev. Bunu wp_options tablosunda yapılandırma depolayan bir ayarlar sayfasına sarmak, bu API’nin ortadan kaldırmak için tasarlandığı teknik borcu tam olarak yaratır. Müşterinin arayüze ihtiyacı varsa, kendi mu-plugin’inizde, müşterinin markasına göre, siteyle sürümlenmiş ve müşteri ayrıldığı gün silinecek şekilde kurun.

Bu test döngüsünü WooCommerce 11.0 yükseltme penceresinin üstüne de yığmayın. WC 11.0 geçen haftaki RC1 ertelemesinin ardından 4 Ağustos’ta yayımlanıyor, WP 7.1 ise 19 Ağustos’ta. Sıralı değişiklik pencereleri hafta sonlarınızı kurtarıyor; DataViews’a bitişik iki hareketli yüzeyi aynı ayıklama kuyruğuna koymak, bir Cumartesi’nizi hangisinin bozulduğunu daraltmakla geçirmenin yolu.

Beş yıl sonra biri 2026’da kurduğunuz bir WordPress sitesini devraldığında ve içerik ekibinin içerik yönetim sistemine ilişkin günlük görüşünün tamamını şekillendiren dört süzgeçli düzenli bir mu-plugin bulduğunda, sıkıcı ve sessiz yönetişim katmanının işlediğinde nasıl göründüğünün resmini görecek. İşte bu, o parçalardan biri.