WooCommerce Ayarlar Arayuzu Uzanti Testine Aciliyor

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.

Bu bir “React geliyor, PHP kodlarınızı yiyecek” anı değil. Bu bir “mevcut PHP ayar diziniz, siz 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üz, betik tutamaçlarınızı bildirirsiniz ve bir kaydetme uyarlayıcısı seçersiniz (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ıyorsunuz, eşleşen React bileşenini { page, section } kapsamıyla kaydediyorsunuz 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ı denetlediyseniz (denetlediniz, 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ı.

Yerinizde olsam ne yapardım, ne yapmazdım

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

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ı bekleyin, bayrağın test aşamasından mezun olmasını izleyin, ancak ondan sonra yayılım planlayın.

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 dizilerinizin göç yolu olması. Özel React bileşenlerini gerçekten hak eden alanlara saklayın — bir ödeme yöntemi seçici, bir kargo bölgesi görselleyicisi — ve geri kalanı uyarlayıcıda tutun. 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.