WordPress 7.1 İçin Bağlayıcı Alan Kaydı Önerildi

Yirmi yıllık WordPress mutfağında öğrendiğim tek bir şey varsa o da şudur: bir özellik tek bir alanla piyasaya çıktığı gün, ekibimden biri mutlaka o alanın yanına ikinci alanı taşıyacak sahte bir ayar sayfası yazmaya başlar. Bileşenlerde oldu, özelleştiricide oldu, blok düzenleyicide oldu. Ve WordPress 7.0 ile gelen pırıl pırıl Bağlayıcılar (Connectors) ekranında da olmaya başladı — çünkü bu ekran şimdilik tek bir şeyi çizmeyi biliyor: API anahtarı.

Her entegre ettiğiniz yapay zekâ sağlayıcısı OpenAI, Anthropic veya Google ise ve hepsi tek anahtarla açılıyorsa sorun yok. Ama müşterinin sizden kendi sunucusunda çalışan bir Ollama örneğine (URL gerekir), bir OpenAI kurum kimliğine, varsayılan model açılır kutusuna ya da bir Bedrock bölgesine bağlanmanızı istediği gün bu tablo dağılır. Bugün bunların hepsi ya özel bir yönetim sayfası ya da deneysel bir React geçersiz kılması gerektiriyor; sonuçta eklentinizi kullanan kişi ayarları wp-admin’in üç ayrı köşesinde arıyor.

Bu hafta Gutenberg bu boşluğu kapatan öneriyi masaya aldı. Henüz birleştirilmedi; ama 7.1 yol haritasının yazılı olarak verdiği bir sözün somut karşılığı, kod olarak orada duruyor. API’nin şekli hâlâ herkese açık şekilde tartışılırken bakmakta fayda var.

Gerçekten yeni olan ne

Andrei Lupu, 20 Haziran 2026’da Gutenberg PR #79373‘ü açtı ve bağlayıcılar için bir PHP alan kaydı önerdi. Bu, WordPress 7.0’da yayımlanan Connectors API ile birlikte gelen Bağlayıcılar ekranının eksik yarısı. PR, Lupu’nun 25 Mayıs’ta açtığı #78647 numaralı meseleyi çözüyor — o mesele iki topluluk bağlayıcısının (Ollama ve Osaurus) yalnızca bir sunucu URL’si tutabilmek için birbirinden bağımsız ayar sayfaları yazması üzerine açılmıştı.

API, register_setting()‘i model alıyor. Yeni bir genel işlev — register_connector_field() — bir bağlayıcı kimliği, bir alan adı ve WordPress geliştiricisinin gözünün ısırdığı bir args dizisi alıyor: type, control, label, description, default, sanitize_callback, auth_callback, show_in_rest, choices, setting_name, env_var_name, constant_name. Şu an desteklenen denetim türleri: metin, URL, e-posta, sayı, parola, çok satırlı metin, seçim kutusu, onay kutusu. Bağlayıcılar yönetim ekranı bunları otomatik çiziyor, bir bağlayıcıdaki tüm alanları tek bir Kaydet düğmesinde topluyor.

Kaputun altında PR, lib/compat/wordpress-7.1/ klasörüne bir WP_Connector_Field_Registry sınıfı ekliyor. Yanına da yardımcı fonksiyonlar geliyor: unregister_connector_field(), wp_get_connector_field(), wp_get_connector_fields(), wp_get_connector_field_value(). JavaScript tarafında DefaultConnectorSettings bileşeni tipli denetimleri çiziyor ve tek bir toplu güncellemeyi REST’e gönderiyor. Geriye dönük uyumluluk temiz halledilmiş: yalnızca bir API anahtarı kayıt eden mevcut bağlayıcılar için otomatik olarak örtük bir api_key alanı sentezleniyor. Kimse ekmeğinden olmuyor.

Test kapsamı vitrin süsü değil: Tests_Connector_Field_Registry altında 39 PHP testi, packages/connectors içinde 14 JavaScript testi. phpcs, eslint ve tsc temiz geçiyor. İnceleme için spacedmonkey işaretlenmiş. PR hâlâ açık ve inceleyicilere dört net soru soruyor: register_connector_field() genel bir işlev mi olsun (yani register_setting() gibi) yoksa kayıt yöneticisi üzerinde bir yöntem mi (yani mevcut Connectors API gibi); alan kaydı, sahibi eklenti etkin değilse bloklansın mı; PHP ve JS tek incelemede mi gitsin yoksa iki ayrı PR’a bölünsün mü; select, çalışma zamanı seçenekleri için bir choices_callback kabul etmeli mi?

Stratejik bağlam gizli değil. 7.1 yol haritası aynen şu sözü verdi: “daha genel, bildirimsel biçimde tanımlanabilen bağlantı formlarını (URL’ler, varsayılan model açılırı ve fazlası) PHP’de keşfetmek.” İşte PR #79373 tam olarak o keşfin, gözden geçirmeye hazır kod hali.

WordPress ve WooCommerce insanları için ne anlama geliyor

Dışarıdaki bir servisle konuşan bir eklenti yazıyor ya da bakıyorsanız — yapay zekâ sağlayıcısı, kargo hesaplayıcı, çeviri motoru, CRM bağlayıcısı, ERP köprüsü fark etmez — hayatınızda birden fazla ayar sayfası yazmışsınızdır. Her birinin kendi yerleşimi, kendi alan adları, kendi temizleme mantığı, kendi REST uç noktası vardır. Bağlayıcılar ekranı yapay zekâ sağlayıcıları için tüm bunları tek yerde toplamak için tasarlandı. Şu an yalnızca tek bir alanı topluyor. Bu PR yayına girerse geri kalanını da toplamış olacak.

Kurumsal WordPress ve WooCommerce işi çeviren ajanslar için pratik kazanım en iyi anlamıyla sıkıcı: tek ekran, tek kaydet düğmesi, tek REST yüzeyi, müşterinin model seçicisini aradığı tek yer. Kimlik zarfı da yönetişimli bir şekilde büyüyor — env_var_name ve constant_name args dizisinde birinci sınıf vatandaş. Yani devops ekibi API anahtarını veritabanına özel bir arayüz üzerinden koymak zorunda kalmıyor; veritabanı şifresini yıllardır nasıl ortama ya da wp-config’e koyuyorsa aynı yolla koyabiliyor.

WooCommerce özelinde bu desen daha büyük bir şeyin tohumu. WordPress “bu entegrasyona URL, bir belirteç, bir bölge ve varsayılan bir model lazım” cümlesini destekli bir bildirim biçiminde ifade edebildiği gün, WooCommerce’in Abilities çalışması ve ödeme/kargo kayıt yöneticileri aynı şekli yeniden kullanabilir. PR bunu dayatmıyor ama gidiş yönü belli.

Şimdi ilgilenmenin ikinci sebebi: bu tür API’lerde kelime dağarcığını ilk on kullanıcı belirler. select gerçekten çalışma zamanı seçeneklerine mi ihtiyaç duyar, auth_callback role göre görünürlük için doğru kanca mı, bu sorulara dair bir fikriniz varsa PR #79373 tam da o konuşmanın yapıldığı oda. Beta 1, 15 Temmuz’da geliyor.

Yerinizde olsam ne yapardım (ve yapmazdım)

Bugün bir bağlayıcı eklentisi yayınlıyorsanız: henüz hiçbir şeyi taşımayın. PR birleştirilmedi, API adı hâlâ genel işlev ile kayıt yöneticisi yöntemi arasında gidip geliyor, JavaScript çizim tarafı ayrı bir incelemeye bölünebilir. Yine de PR’ı şimdi okuyun ve dört açık soruya Beta 1’den önce görüş bırakın. Şeklin ucuza etkilenebileceği pencere burası.

Müşteriler için özel bağlayıcı yazıyorsanız: mevcut bespoke ayar sayfalarınızı bırakın; ama sonradan sökmesi kolay olacak şekilde yazın. Alan tanımlarını tek bir PHP dosyasında bir diziye koyun, temizlemeyi adlandırılmış geri çağırma işlevlerinde tutun, saklama anahtarlarını setting_name‘in üreteceğiyle tutarlı seçin. Kayıt yöneticisi yayına girdiğinde elli satırlık yönetim menüsü telini on satır register_connector_field() çağrısına indirir, gerisini silersiniz.

Bir barındırma ya da ajans operasyon ekibiyseniz: şu an hazırlanacağınız kısım env_var_name ve constant_name desteği. Filonuz genelinde yapay zekâ kimlikleri için ortam değişkeni adlandırmasını standartlaştırın. Kayıt yöneticisi yayına girdiği gün, o adlandırma altyapınızla müşterinin yükleyeceği her bağlayıcı eklentisi arasındaki birlikte çalışabilirlik katmanı olacak.

Yapmayacağım tek şey: gelecek hafta yeni bir yapay zekâ sağlayıcı entegrasyonu için bir tane daha bespoke yönetim sayfası açmak. Üç hafta bekleyin. PR #79373, 15 Temmuz’da Beta 1’e yetişmezse özel sayfanızı vicdanınız rahat şekilde yazarsınız. Yetişirse kendinize bir yeniden yazma zahmetinden kurtarmış olursunuz.

WordPress bu tür kavgaları sıkıcı olanı sıkıcı bırakarak kazanır. Bağlayıcılar için bir alan kaydı tam da öyle bir sessiz, yüksek kaldıraçlı tesisat — kimsenin sahnede demo yapmadığı ama herkesin altı ay sonra üzerine bina kurduğu türden bir değişiklik.