WooCommerce Ayarlar Arayuzu Uzanti Testine Aciliyor

🇬🇧 English: Read this in English →

Her WooCommerce ajansının kafasında aynı çekmece vardır: hangi eklentinin ayarlarını nereye koyduğunun zihinsel haritası. Stripe, Ödemeler sekmesi altında. Kargo eklentisi kendi üst düzey sekmesinde. Abonelik uzantısı klasik ayar tablosunda üç tıklama derinliğinde. Yirmi yıl sonra bu düzen tanıdık — ama satıcı için sessiz sedasız yorucu.

Bu yüzden Woo, “uzantı ayarlarının görünüş ve davranışını birleştiriyoruz, işte katılımın yolu” diyen bir test çağrısı yayımladığında baştan sona okuyorum. Bir arayüz yenilemesi tek başına heyecan verici olduğu için değil; bu adım, 10.9.2’de tökezleyen ayarlar SDK’sı, WordPress 7.1’e inen yetenekler ve Andrew Duthie’nin geçen hafta Make/Core’da önerdiği tasarım simgeleri arasındaki halkayı kapattığı için. Hepsi tek bir iplik.

Şunu baştan netleştireyim: bu bir “React geliyor, PHP kodlarını yiyecek” anı değil. Bu bir “mevcut PHP ayar dizin, sen koda dokunmadan React kabuğunun içinde çalışabilir” anı. Bu ayrım önemli ve önümüzdeki üç ayda uzantı işlerini nasıl önceliklendireceğimizi değiştiriyor.

Gerçekte yeni olan ne

8 Temmuz 2026‘da Brian Coords, WooCommerce Geliştirici Blogu’nda bir test çağrısı yayımladı: WooCommerce uzantıları için Ayarlar Arayüzü desteği. Mekanizma, WooCommerce 10.9 ve sonrasında settings-ui özellik bayrağının arkasında ve sayfa bazında tamamen isteğe bağlı.

Yanında duran tasarım yazısı, aynı gün Elizabeth Pizzuti’nin kaleme aldığı “WooCommerce’te uzantı ayarlarını birleştirmek”, nedeni ortaya koyuyor: uzantı ayar ekranları yıllar içinde birbirinden savrulmuş; her biri kendi yerleşimini, kendi kaydet düğmesi konumunu, kendi durum işaretlerini kullanıyor. Yeni çerçeve WordPress Tasarım Sistemi bileşenlerine, 720 piksellik içerik sütununa, kart tabanlı gruplamaya ve anlamsal --wpds-* simgelerine yakınsıyor. Yeni bir şey icat edilmiyor — her şey hizalanıyor.

Geliştiriciler için önemli olan iki parça Ayarlar Arayüzü belgelerinde tarif ediliyor:

• LegacySettingsPageAdapter — mevcut bir WC_Settings_Page alt sınıfını ve onun PHP ayar dizisini alır, yeni React kabuğunda değişikliksiz görüntüler. Yerel alan tipleri (text, password, email, url, number, textarea, checkbox, select, radio, multiselect, ülke seçicileri, sayfa seçici, info) kutudan çıkar çıkmaz çalışır.
• SettingsUIPageInterface — doğrudan denetim isteyen sayfalar için yerel sözleşme. Bir şema döndürürsün, betik tutamaçlarını bildirirsin ve bir kaydetme uyarlayıcısı seçersin (form_post, WooCommerce’in klasik POST akışını korur; none, yalnızca gösterim amaçlı alanlar içindir).

Katılım tek bir süzgeç ile oluyor. Test çağrısından birebir:

add_filter(
    'woocommerce_admin_features',
    static function ( array $features ): array {
        $features[] = 'settings-ui';
        return array_values( array_unique( $features ) );
    }
);

Özel React denetimleri, @woocommerce/settings-ui paketinden dışa aktarılan registerSettingsExtension() ile yerleşiyor. PHP alanına 'component' => 'my-plugin/payment-picker' tanımlıyorsun, eşleşen React bileşenini { page, section } kapsamıyla kaydediyorsun ve WooCommerce onu kabuğun içine monte ediyor. Çözümleme sırası şu: önce alanda bildirilen bileşen, sonra eski uyum eşlemeleri, sonra tip bazlı görselleyiciler, en son yerel varsayılan.

Geri bildirim aynı gün dmallory42 tarafından açılan GitHub tartışması #66435‘te toplanıyor. Woo test edilen sürümü, katılan sayfayı, mevcut alan tiplerini, konsol uyarılarını ve değerlerin beklendiği gibi kaydedilip kaydedilmediğini istiyor. Bu bir izlenim değil, tarif edilmiş bir istek.

WordPress ve WooCommerce ekipleri için neden önemli

Üç bağlantı bu haberi bir arayüz tazelemesinden büyük yapıyor.

Birincisi, ayarlar SDK’sı. WooCommerce 10.9.2‘de bu çerçevenin altındaki sınıflar, yeterince güncellemeyi bozdu ve aynı gün çıkan bir nokta sürümü hem sınıfları korumak hem de kaldırılmış bir REST denetleyicisini işlevsiz bir uyum stubu olarak geri getirmek zorunda kaldı. O, tesisattı. Ayarlar Arayüzü test çağrısı, tesisatın taşımak için var olduğu şey. 10.9.2 sonrasında SDK öncesi ayar isim uzayı referanslarını denetlediysen (denetledin, değil mi?), bu döngü karşılığın alındığı yer.

İkincisi, tasarım simgeleri. Andrew Duthie’nin iki gün önce Make/Core’da yayımladığı tasarım sistemi temalandırma birleştirme önerisi, tüm yönetici sayfalarına önceden derlenmiş design-tokens.css sunan wp-theme tutamaçlarını getiriyor. Ayarlar Arayüzü çerçevesi tam olarak aynı simgeleri --wpds-* isim uzayı altında tüketiyor. WordPress 7.1 19 Ağustos’ta yayımlandığında, bu kabuk üzerine kurulmuş uzantı ayar sayfaları tema değişikliklerini bedavaya devralıyor — kullanıcının renk düzeninin nihayet Site Düzenleyici’ye ulaşması dahil ve zamanla Duthie’nin 7.1’in ötesine ertelediği karanlık kip çalışması dahil.

Üçüncüsü, yetenekler katmanı. Çekirdek yeteneklerin genişletilmesi birleştirme önerisi, manage_options ile kontrol edilen ve yeni show_in_abilities kayıt bayrağıyla açılan bir core/read-settings sunuyor. Ayarlar Arayüzü şeması üzerine yeniden kurulmuş uzantılar, alanlarının kanonik ve yapılandırılmış bir tanımına sahip oluyor — React’i besleyen şema, ilkesel olarak paralel bir uyarlayıcı olmadan yapay zekâ ajanlarına yönelik okumaları da besleyebiliyor. Bugün teslim edilmemiş ama biçim kasıtlı.

Satıcı için karşılık daha yalın: daha az zihinsel model, tutarlı kaydet düğmeleri, gerçekten çalışan klavye odağı, her yerde aynı anlama gelen durum tonları. Ajans için karşılık, “ayar ekranı yönetimin geri kalanına benzesin” isteğinin artık her projede özel bir görev olmaktan çıkması.

Peki ya devraldığın o eski uzantılar

Bir dakikalığına parlak yeni çerçeveyi bırakıp gerçek dünyaya bakalım. Bir WooCommerce ajansı olarak envanterinin çoğu senin yazmadığın kod. Devraldığın mağazalarda üç yıldır güncellenmemiş bir kargo eklentisi, satın alındığında bambaşka bir ekipten geçmiş bir abonelik uzantısı, ve geliştiricisi ortadan kaybolmuş yarım düzine küçük eklenti var. Birleşik ayar kabuğunun asıl sınavı işte bu uzun kuyrukta veriliyor — çünkü LegacySettingsPageAdapter tam olarak bu tür kodu, kimse dokunmadan React kabuğuna almak için tasarlandı.

Ben olsam test çağrısına katılırken sadece kendi güzel yazdığım uzantıları değil, tam olarak bu bakımsız olanları denerdim. İyi yapılandırılmış bir ayar dizisi zaten temiz gelecek; asıl bilgi, standart dışı bir alan tipini elle üreten ya da POST akışını kendince kırpan o eski eklentiden çıkacak. Uyarlayıcı orada kırılıyorsa, bunu şimdi tartışma #66435’te bildirmek, iki yıl sonra sessizce bozulmuş bir ayar ekranıyla uğraşmaktan çok daha ucuz. Bir çerçevenin gerçek dayanıklılığı en iyi kodda değil, en kötü kodda ölçülür.

Ben olsam ne yapardım, ne yapmazdım

Test et, taşıma. Bu bir test çağrısı, genel kullanıma sunum duyurusu değil.

Bu hafta bir hazırlık ortamında çalıştıracağım somut adımlar:

• WooCommerce 10.9.4 üzerinde, gerçekten bakımını üstlendiğin üç özel uzantının kurulu olduğu bir site ayağa kaldır — devraldıkların değil.
• Yukarıdaki woocommerce_admin_features süzgecini bir mu-plugin dosyasına düşür. Asla yönetici arayüzünden değil. Özellikleri arayüzden açıp kapatırsan birileri hangi ortamda olduğunu unutuyor.
• Her uzantı için bir ayar sayfasını LegacySettingsPageAdapter ile sar ve sayfayı React kabuğunda aç. Her konsol uyarısını harfiyen kaydet.
• Bir değer kaydet, sayfayı yenile, tekrar kaydet. Altta yatan seçenek satırını denetle. Değer form_post üzerinden temiz gidip geliyorsa alan tanımların zaten şema-temiz.
• Sonuçları tartışma #66435‘e yapılandırılmış bir yorum olarak yaz. Sürüm, sayfa, alan tipleri, uyarılar, kaydetme davranışı. Woo tam olarak bunu istedi. Belirsiz izlenimler yapıştırma.

Yapmayacağım şey: settings-ui bayrağını üretime çıkarmak. Ne müşteri mağazalarında ne de kendi sitelerimde. Bu, 10.9.x üzerinde bir özellik bayrağı ve 10.9 zaten iki hafta içinde alttaki tesisat için üç nokta sürümü çıkardı. WooCommerce 11.0, 28 Temmuz 2026’da varsayılan olarak açık ürün nesnesi önbelleklemesi ve Action Scheduler 4.0.0 ile geliyor. 11.0’ın oturmasını bekle, bayrağın test aşamasından mezun olmasını izle, ancak ondan sonra yayılım planla.

Ayrıca yapmayacağım bir şey daha: ayar ekranlarını ilk günden saf React olarak yeniden yazmak. LegacySettingsPageAdapter‘ın bütün amacı, mevcut PHP dizilerinin göç yolu olması. Özel React bileşenlerini gerçekten hak eden alanlara sakla — bir ödeme yöntemi seçici, bir kargo bölgesi görselleyicisi — ve geri kalanı uyarlayıcıda tut. Az kod hedef olmaya devam ediyor.

Parçalar hizalanıyor: ayarlar SDK’sı, tasarım simgeleri, yetenekler, birleşik uzantı kabuğu. Bu çeyrek yüzeyi hazırlama çeyreği. Üretim bir sonrakinde.