WordPress Çekirdek Yetenekleri 7.1 için Genişliyor

Her altı ayda bir birileri yeni nesil yapay zekâ araçlarının içerik yönetim sistemini nihayet gereksiz kılacağını ilan ediyor. Bu satışı yirmi yıldır dinliyorum ve hep aynı nedenden ötürü çuvallıyor: kuralların yaşadığı yer içerik yönetim sistemi. Kim neyi düzenleyebilir. Hangi içerik türleri var. 2019’daki kalıcı bağlantı neydi. Ödeme sayfası gecenin üçünde bir bot tarafından güncellenebilir mi. Bu yönetişim katmanını söküp attığınızda akıllı bir ajan elde etmiyorsunuz, çok hızlı bir davetsiz misafir elde ediyorsunuz.

Abilities API tam olarak WordPress’in bu yönetişim katmanını sessiz sedasız makinelerin okuyabileceği bir sözleşmeye dönüştürmesi. 6.9’da geldi, 7.0’da istemci tarafına genişledi, bu hafta da 7.1 için gelen bir birleştirme önerisiyle somut bir adım daha attı. Müşterilere iş üretiyorsanız, döngünün daha sonuçları olan önerilerinden biri bu — ve bir keynote heyecanıyla değil, sıradan bir biletin sakinliğiyle geliyor.

Öneri yeni bir yetenek değil. Ortak bir temel. Bu ayrım hikâyenin tamamı.

Gerçekte yeni olan ne

2 Temmuz 2026’da Jorge Costa, Make/Core üzerinde Merge Proposal: Expanding WordPress Core Abilities başlıklı yazıyı yayımladı. Öneri WordPress 7.1’i hedefliyor ve core/ ad alanı altında üç adet salt okunur yetenek ekliyor: core/read-settings, core/read-content ve core/read-users. Üçü de 6.9’da inen Abilities API ile 7.0’da inen istemci tarafı yetenekler üzerinde oturuyor.

Mekanik kısmı bilinçli olarak sıkıcı. core/read-settings, ayarları düz bir isim-değer eşleşmesi olarak döndürüyor; grup veya belirli alan adlarıyla süzülebiliyor, manage_options yetkisiyle korunuyor. core/read-content, içerik türlerini tek öğe veya koleksiyon kipinde sorguluyor. core/read-users, kullanıcıları tek tek veya rol ve duruma göre filtrelenmiş bir koleksiyon olarak arıyor. Her yetenek, tıpkı Abilities API’nin geçen yıl kurduğu sözleşme gibi, tanımlı girişleri, çıkışları, izinleri ve yürütme mantığı olan kendi başına bir birim.

Asıl ilginç kısım açık dahil olma bayrağı. Hiçbir şey otomatik açılmıyor. Ayarların ve içerik türlerinin görünür olabilmesi için yeni show_in_abilities bayrağını el kaldırıp açması gerekiyor. WordPress’in show_in_rest için kullandığı desenle aynı, ve bu 7.1 yayına girdiği gün ekosistemin iç organlarını kazara yayımlamayacağı anlamına geliyor. core/read-settings‘in ilk gerçeklemesi wordpress-develop PR #12141 olarak açık; Jorge Costa 9 Haziran’da açtı, 2 Temmuz’a kadar üzerinde yineledi. Davranış yeni bir WP_Settings_Abilities sınıfında yaşıyor, açıkça aynı kodun ileride bir yazma yeteneğini de besleyebilmesi için tasarlanmış.

İzinler var olan WordPress yetkilerini yeniden kullanıyor: ayarlar için manage_options, kullanıcı okumaları için list_users, içerik için normal içerik türü haritası. Yeni bir izin katmanı yok. Gelişmiş sorgulama — meta_query, tax_query, taksonomiler arası birleştirmeler — kapsam dışı ve açıkça 7.2’ye ertelendi. Öneri ayrıca yönetim yeteneklerinin (core/manage-settings, core/manage-content, core/manage-users) sıradaki hedef olduğunu, arkalarında yorumların, taksonomilerin, ortam dosyalarının, temaların ve eklentilerin sıraya girdiğini not düşüyor.

7.1 yol haritasına göre isimler 15 Temmuz’daki Beta 1’de kilitleniyor, dolayısıyla inceleme penceresi dar. İlgili biletler Trac #64605, #64606, #64657 altında takip ediliyor; ek olarak WordPress/ai deposunda (#691, #806, #739, #774) ve wordpress-develop’ta (#12141, #12195, #10775) çekme istekleri açık.

WordPress ve WooCommerce insanları için neden önemli

Bir müşteri sitesine hiç LLM entegre ettiyseniz süreci bilirsiniz. Bir REST uç noktası kurarsınız, kimlik doğrulama bağlarsınız, bir izin geri çağrımı yazarsınız, şemayı belgelersiniz, sonra bir sonraki projede aynı işi biraz farklı isimlerle tekrar edersiniz. Her ajansın aynı üç rotanın kendi sürümü vardır, her eklentinin de üstüne kendi sürümü vardır. İşe yarar ama ortak bir söz dağarcığı değildir.

Ortak salt okunur yetenekler bu hesabı değiştiriyor. 7.1 yayına girdiği an, Abilities dilini konuşan her istemci — bir Gutenberg AI Client, bir tarayıcı eklentisi, bir WebMCP ajanı, bir WooCommerce asistanı — bir WordPress sitesinden ayarlarını, gönderilerini ve kullanıcılarını, site sahibi özel bir yapıştırıcı kod yazmadan istemeyi biliyor. Değer bu. Yeni güç değil, ortak bir iletişim protokolü.

Açık dahil olma kapısı da tam burada anlam kazanıyor. Bir Woo mağazasında ürün ayarlarını, vergi ayarlarını ve kargo bölgelerini muhtemelen dahili bir ajana açmak istersiniz; SMTP parolasını neredeyse kesinlikle hiçbir şeye açmazsınız. show_in_abilities bu denetimi ayarın kaydedildiği yerde veriyor, üç eklenti derinliğine gömülü bir süzgeçte değil. WooCommerce Abilities çalışmasını yürüten ajanslar için bu, uzantı yeteneklerinin üzerine kurulduğu zemin.

Sürüm notlarında yeterince vurgulanmayan bir yönetişim boyutu var. Salt okunur önce geliyor, çünkü bir sebep var. Bir ajan ayarları okuduğunda en kötü senaryo ifşadır. Bir ajan ayarları yazdığında en kötü senaryo hizmet kesintisidir. Okumaları 7.1’de, yönetimi 7.2’de yayına almak bir gecikme değil, bir tasarım kararı. Yazma yetenekleri ortaya çıkmadan önce ekosistem altı ay boyunca nelerin kırıldığını görüyor, ifşa deliklerini kapatıyor ve düzgün denetim izleri ekliyor. Olgun bir platform yapay zekâ komşusu güce tam olarak böyle geçer.

Ben ne yaparım, neyi yapmam

Üç somut şey, sırayla.

Birincisi, 15 Temmuz Beta 1’den önce kod tabanınızdaki her register_setting() çağrısını gözden geçirin. Hassas verinin durduğu her yerde — API anahtarları, webhook sırları, entegrasyon jetonları, kişisel veri anahtarları — show_in_abilities‘ı açıkça kapalı bırakmak için net bir planınız olsun. Varsayılan zaten kapalı, dolayısıyla bu çoğunlukla bir inceleme egzersizi, ama olgun ve çok eklentili bir sitede sürprizler bulursunuz. Dahili notlar, ambargo altındaki taslaklar ya da müşteriye özel uyum içeriği barındıran özel içerik türleri için de aynı tatbikat. Gelecekteki yazma yeteneklerinin sizi kurtaracağını varsaymayın; okuma tarafı zaten yapıyı ifşa ediyor.

İkincisi, ortak bir salt okunur yeteneğin kapsayacağı hiçbir şey için artık el yapımı yapay zekâ uç noktaları çıkarmayı bırakın. Şu an bir müşteri projesinde özel bir /wp-json/myco/v1/products?agent=1 rotası varsa, core/read-content‘e içerik türüne göre süzülmüş bir göç planlayın. Yüzeyi korursunuz, özel izin geri çağrımından kurtulursunuz ve ekosistemin standartlaştığı şemayı miras alırsınız. Sonsuza kadar bakmak zorunda olacağınız kodda gerçek bir azalma.

Üçüncüsü, yönetim yeteneklerine karşı henüz kod yazmayın. 7.1’e önerilmiyorlar. Bir sohbet arayüzü üzerinden ayarları değiştiren dahili bir aracınız varsa, core/manage-* yeteneği 7.2’de denetim ve doğrulama anlamlarıyla düzgün yayına girene kadar onu kendi korunaklı uç noktanızda tutun. Birleştirilmemiş tasarımın üstüne inşa etmek, iki sürüm sonra kendinizi bedavaya yeniden yazarken bulduğunuz yerdir. Bu dosyada kahramanlık yapılmaz.

WooCommerce özelinde bir not. Woo ekibi 10.8 ve 10.9 boyunca ürünler, siparişler ve salt okunur uzantı yetenekleri için kendi Abilities katmanı üzerinde iteratif ilerliyor. 7.1 yayına girince bunlar çekirdek ilkellerin üzerinde oturacak, dolayısıyla bir Woo sitesinde şimdi yaptığınız her özel iş, paralel bir şema değil, ortak şeklin üzerinde ince bir adaptör olmalı. Aynı ürün için iki şema, sonsuza kadar bakmak zorunda olacağınız iki şema demek.

Buradaki desen, kariyerimin yirmi yılını WordPress’te geçirmeye değer kılan aynı desen: güçlü sözleşmeli sıkıcı ilkeller, zayıf sözleşmeli akıllı özellikleri her seferinde yener. 7.1’deki salt okunur yetenekler bilerek sıkıcı. İyi haber bu.