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

🇬🇧 English: Read this in English →

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ğin yapay zekâ sağlayıcısı OpenAI, Anthropic veya Google ise ve hepsi tek anahtarla açılıyorsa sorun yok. Ama müşterin senden 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ı 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 eklentini 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.

Neden “kayıt” kalıbı, elle ayar sayfasından iyidir

Burada asıl mesele bir alan daha ekleyebilmek değil, işi yapış biçiminin değişmesi. Bespoke ayar sayfası yazdığında sen üç işi birden üstlenirsin: alanı çizmek, gelen veriyi temizlemek ve kaydetmek. Üçü de senin kodunda yaşar, üçü de senin bakımında ölür. Kayıt kalıbında ise sen sadece “bu alan şu tipte, şöyle temizlenir, şu izinle görünür” diye tarif edersin; çizmeyi, toplamayı, REST’e taşımayı platform üstlenir. Buna bildirimsel (declarative) yaklaşım diyoruz: ne istediğini söylersin, nasıl yapılacağını değil.

Açık konuşayım, bence bu WordPress’in en sağlam kaslarından biri ve yıllardır neden ayakta kaldığının da yarısı. register_post_type(), register_block_type(), register_setting() — hepsi aynı sözleşme: sen tarif et, çekirdek çizsin. Bu sözleşmeye yaslanan kod, platform güzelleştikçe bedavaya güzelleşir; elle çizdiğin sayfa ise platform ilerledikçe geride kalır. Ben olsam bir özelliği “kendi ayar sayfamı yazayım” ile “kayıt API’sine tarif edeyim” arasında seçerken, ikincisi mevcutsa gözüm kapalı onu seçerdim — bugün iki satır fazla yazsam bile.

WordPress ve WooCommerce insanları için ne anlama geliyor

Dışarıdaki bir servisle konuşan bir eklenti yazıyor ya da bakıyorsan — yapay zekâ sağlayıcısı, kargo hesaplayıcı, çeviri motoru, CRM bağlayıcısı, ERP köprüsü fark etmez — hayatında birden fazla ayar sayfası yazmışsındı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 fikrin varsa PR #79373 tam da o konuşmanın yapıldığı oda. Beta 1, 15 Temmuz’da geliyor.

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

Bugün bir bağlayıcı eklentisi yayınlıyorsan: henüz hiçbir şeyi taşıma. 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 oku ve dört açık soruya Beta 1’den önce görüş bırak. Şeklin ucuza etkilenebileceği pencere burası.

Müşteriler için özel bağlayıcı yazıyorsan: mevcut bespoke ayar sayfalarını bırak; ama sonradan sökmesi kolay olacak şekilde yaz. Alan tanımlarını tek bir PHP dosyasında bir diziye koy, temizlemeyi adlandırılmış geri çağırma işlevlerinde tut, saklama anahtarlarını setting_name‘in üreteceğiyle tutarlı seç. 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 silersin.

Bir barındırma ya da ajans operasyon ekibiysen: şu an hazırlanacağın kısım env_var_name ve constant_name desteği. Filon genelinde yapay zekâ kimlikleri için ortam değişkeni adlandırmasını standartlaştır. Kayıt yöneticisi yayına girdiği gün, o adlandırma altyapınla 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 bekle. PR #79373, 15 Temmuz’da Beta 1’e yetişmezse özel sayfanı vicdanın rahat şekilde yazarsın. Yetişirse kendine bir yeniden yazma zahmetinden kurtarmış olursun.

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.