WordPress 7.1 Abilities API Süzgeçleri: Dört Yeni Kanca

Son iki yılda WordPress’ten geçen her yapay zekâ dalgası aynı sorunla geldi. Eklentiler, bir model ile site arasına girmek istedi — bir cevabı önbelleğe almak, hatalı bir isteği yutmak, orijinal geliştiricinin hiç düşünmediği bir yetki eklemek için — ve elimizde tek yüzey vardı: başkasının eklentisinin etrafına sarmalayıcı yazmak. İşe yaradı. Aynı zamanda, devraldığınızda sessizce baştan yazdığınız türden on yıllık bir kod birikimi de üretti.

Dün, tek bir geliştirici notu bu boşluğu sessizce kapattı. WordPress 7.1, Abilities API’ye — yani 7.0’da yapay zekâ ve ajan iş akışları için “tipli eylem kayıt sistemi” olarak gelen aynı API’ye — dört yeni süzgeç ekliyor. Süzgeçler eklemeli, her deneyimli WordPress geliştiricisinin zaten bildiği şekli takip ediyor (kısa devre, dönüştür, yetkilendir, kurtar) ve salt-okunur bir gözlem yüzeyini, çekirdek eklentileri yamamadan gerçekten üzerine inşa edebileceğiniz bir şeye dönüştürüyor.

Sosyal medyada trend olmayan cinsten bir sürüm bu. Aynı zamanda WordPress’in “bir yapay zekâ özelliğini üç yıl boyunca üretimde çalıştırma” yarışını neden sessizce kazanmaya devam ettiğinin tam olarak nedeni.

Aslında ne yeni

Milana Cap’in Make/Core’da 29 Temmuz 2026’da yayımladığı “New execution lifecycle filters for the Abilities API in WordPress 7.1” notu, ability yürütme hattına dört yeni süzgeç ekliyor. Şimdiye kadar geliştiricilerin elinde yalnızca wp_before_execute_ability ve wp_after_execute_ability vardı; günlük veya metrik için yararlıydılar ama bir ability’nin ne yaptığını değiştiremezlerdi. Yeni süzgeçler değiştirebilir.

• wp_pre_execute_ability — kısa devre. Bir değer döndürür ve tüm hat (doğrulama, yetki kontrolü, geri çağırma, çıktı doğrulaması) atlanır. Cap; önbellekleme, hız sınırlama, bakım modu, onay iş akışları ve test taklidini önerilen kullanım senaryoları olarak sıralıyor. Öntanımlı sentinel, “null döndür” ile “hiç süzgeç eklenmemiş” durumunu karıştırmamak için bir WP_Filter_Sentinel nesnesi.
• wp_ability_normalize_input — WP_Ability::normalize_input() içinde, JSON Şema öntanımları uygulandıktan sonra çalışır. Şemanın ifade edemediği sunucu tarafı öntanımları ekleyebilir, bir istemi bağlamsal üstveri ile zenginleştirebilir ya da doğrulama başlamadan yürütmeyi durdurmak için WP_Error döndürebilirsiniz.
• wp_ability_permission_result — ability’nin kendi permission_callback‘inin üzerinde oturur. true, false ya da WP_Error döner. Bu güçlü ve aynı nefeste tehlikeli olan süzgeç: orijinal geliştiricinin reddettiği erişimi verebilir ve hem REST hem WP-CLI çağrılarına uygulanır.
• wp_ability_execute_result — geri çağırmadan sonra, çıktı doğrulamasından önce çalışır. Yanıtı yeniden biçimlendirin, üstveriyi sıyırın, hassas alanları filtreleyin veya bir ham hatayı zarif bir yedeğe çevirin.

Tam yürütme yaşam döngüsü artık şöyle okunuyor: girdi normalleştirme → doğrulama → yetkiler → önceki eylem → geri çağırma → sonuç süzgeci → çıktı doğrulaması → sonraki eylem. Değişiklik Trac bileti #64989 altında, [62397] changeset ile geliyor. Notun eş değerlendirmecileri Benjamin Zekavica ve Audras JB. Her şey eklemeli — var olan ability’ler değişiklik olmadan çalışmaya devam ediyor, eski wp_before_execute_ability/wp_after_execute_ability eylem kancaları yerinde duruyor.

Bağlam: Abilities API, WordPress’in dış ajanlara, yapay zekâ istemcilerine ve dahili otomasyonlara, tipli girdi, tipli çıktı ve bir yetki kapısı ile tanımlı bir eylemi çağırma imkânı verdiği yüzey. Jorge Costa’nın 2 Temmuz’da yayımlanan birleştirme önerisi, 7.1’e eklenen salt-okunur çekirdek ability’lerini (core/read-settings, core/read-content, core/read-users) tarif ediyordu. Aynı sürümde gelen süzgeçler, bunların altına oturan genişletilebilirlik katmanı. WordPress 7.1 GA hâlâ sürüm partisi takvimine göre 19 Ağustos 2026’ya planlı.

WordPress / WooCommerce ekiplerine ne anlama geliyor

Çalışan bir ajans için pratik getiri şu: yıllardır ad-hoc eklenti sarmalayıcıları olarak yazdığınız “ara katman” kodunun artık resmi bir dikişi var. Bir müşteri WooCommerce mağazasının üstüne bir yapay zekâ asistanı takıyorsa — diyelim ki core/read-content üzerinden müşteri siparişlerini okuyan bir ajan ya da özel bir store/quote-price ability’si — hız sınırı veya onay adımı eklemek için ability’yi kaydeden eklentiyi çatallamanız gerekmiyor. Bir süzgeç kaydediyorsunuz. Bu süzgeç küçük bir mu-plugin içinde yaşıyor. Ability’yi ilk baştan kaydeden neyse, gelecekteki her güncellemesinden sağ çıkıyor.

Üzerinde dikkatle düşünülmesi gereken süzgeç wp_ability_permission_result. Orijinal permission_callback‘in reddini geçersiz kılabildiği için gerçek bir denetim günlüğü kalemi. Doğru zihinsel model, her kıdemli WordPress geliştiricisinin zaten user_has_cap‘e uyguladığı model: buna dokunan her kod parçasının yorum satırında yazılı bir gerekçesi ve o gerekçe kaybolduğunda başarısız olan bir testi olmalı. Kolaylık olarak değerlendirmeyin.

wp_pre_execute_ability kısa devresi ise sessizce dördünün üretim için en yararlısı. “Bana son 20 siparişi ver” diyen bir ajan çağrısı için, ability yetki kontrolüne bile girmeden dönen bir önbellek sonucu, sıcak bir yolda 200ms’den 10ms’ye iniş demektir. Aynı şekil pre_get_posts ile paylaşıyor, aynı içgüdü — önce önbellek, sonra çalıştır.

Ne yapardım (ya da yapmazdım)

Abilities API üzerine henüz bir şey inşa etmediyseniz, sırf süzgeçler var diye bugün başlamayın. API çekirdekte ilk yılını doldurdu, 7.1’deki salt-okunur çekirdek ability’ler pratik başlangıç noktası ve müşteriye özel bir ability kaydetmeden önce bir sürüm döngüsü daha beklemenin utancı yok. Birleştirme önerisini okuyun, Cap’in notunu okuyun ve küçük bir dahili otomasyon seçin — bir “haftalık özet yayımla” ability’si ya da bir “WooCommerce sepet terk kuyruğunu temizle” ability’si — 7.1 Beta 4 ile hazırlık ortamında prototipleyin.

Zaten üretimde Abilities API kodunuz varsa, bu hafta üç şey. Birincisi, aslında yürütmeyi kısa devre yapmaya çalışan her mevcut wp_before_execute_ability kancasını wp_pre_execute_ability‘ye yeniden yazın; kod kısalır, niyet okunur. İkincisi, ability’lerin etrafına yazdığınız özel yetki kapılarını denetleyin ve ability’nin kendi permission_callback‘ine mi yoksa bir wp_ability_permission_result süzgecine mi ait olduklarına karar verin — cevap, kural kesişimsel değilse (hız sınırları, IP izin listesi, bakım bayrağı) neredeyse her zaman “geri çağırmanın içinde”dir. Üçüncüsü, bu test döngüsünü 4 Ağustos’taki WooCommerce 11.0 yükseltme penceresinin üzerine yığmayın; tek bir sıralama kuyruğunda iki hareketli hedef, bir hafta sonunu hangi ikisinin kırıldığını daraltmakla geçirmenin klasik yoludur.

Lütfen, tüm satış argümanı “Abilities API süzgeçlerini yapılandırmak için arayüz ekler” olan üçüncü taraf bir eklenti yayımlamayın. Yukarıdaki dört süzgeç adı bir mu-plugin içinde birer satır. Onları bir ayarlar ekranına sarmak, çekirdekte zaten kurallı bir şekli olan bir şey için size teknik borç ve destek yüzeyi kazandırır.

Bunların altındaki sinyal, yirmi yıldır WordPress üzerine inşa etmeye devam etmemin nedeniyle aynı: yeni bir API geldiğinde, ikinci sürüm genişletilebilirlik katmanını gönderiyor ve o katman WordPress’teki her şeye benziyor. Süzgeçler, sentineller, eklemeli değişiklikler, kırılma yok. Sıkıcı. Güvenilir. Bir müşterinin üç yıl sonra hâlâ çalıştıracağı bir yapay zekâ özelliğinin altında istediğim tam olarak bu yüzey.