Proposal Baru Meminta Kontributor untuk Berhenti Menggabungkan API Eksperimental dari Gutenberg ke WordPress Core

Praktik menggabungkan API eksperimental dari Gutenberg ke inti WordPress mungkin akan segera berakhir. Proposal baru, yang diterbitkan oleh kontributor yang disponsori Automattic, Adam Zielinski, meminta kontributor untuk menstabilkan API sebelum menggabungkannya menjadi inti.

Selama bertahun-tahun, sekitar 280 API eksperimental telah digabungkan dari plugin Gutenberg, yang diaudit Zielinski dalam tiket yang dia buka untuk edisi pada bulan April. Dalam menyeimbangkan dorongan untuk bergerak cepat dengan iterasi pada editor terhadap komitmen WordPress terhadap kompatibilitas mundur, jumlah API eksperimental menjadi tidak dapat dipertahankan dan praktik menggabungkannya ke dalam inti sekarang sedang dipertimbangkan kembali secara aktif.

Secara resmi, API eksperimental ditandai untuk mencegah penggunaan pihak ketiga, karena diperkirakan akan berubah. Dalam praktiknya, orang yang membangun untuk editor blok tetap menggunakannya karena mereka berada di inti dan mereka ingin memperluas fitur yang diaktifkan oleh API ini.

“Penulis plugin dan tema dipaksa untuk mengandalkan __experimental yang dapat dihapus atau diubah dengan cara yang tidak kompatibel kapan saja,” kata Zielinski, menggemakan frustrasi dan kekhawatiran yang dialami banyak pengembang dengan proyek tersebut beberapa tahun terakhir. “Ini adalah beban pemeliharaan yang serius. Setiap rilis Gutenberg/WordPress baru berarti berpotensi merusak perubahan.”

Pembuat inti WordPress Peter Wilson mengomentari tiket tersebut, dengan mengatakan bahwa dia mendukung pembatasan API eksperimental untuk produk yang lebih canggih. Mendorong kebutuhan akan perubahan ini, ia mengutip sejumlah dampak negatif yang dimiliki API eksperimental inti ini pada ekosistem:

• pembuat inti tidak mau menggunakan fitur perpustakaan tertentu untuk membuat tugas inti lebih mudah karena mereka tidak mempercayai keandalannya
• pengembang tidak lagi memutakhirkan situs klien WP. Sebagai pembuat komitmen inti yang telah berusaha untuk mempertahankan kompatibilitas ke belakang selama bertahun-tahun, ini mengecewakan saya. Sebagai anggota tim keamanan, ini sangat memprihatinkan
• pengembang memutuskan untuk menyertakan salinan paket dalam tema dan plugin daripada mengandalkan global wp.* . Sekali lagi ini menyangkut saya dari perspektif keamanan tetapi juga meningkatkan muatan JavaScript secara signifikan lebih dari mempertahankan kompatibilitas ke belakang
• laporan jeda kompatibilitas mundur dalam versi minor: "Anda tidak mengharapkan rilis 5.9.1 untuk mematahkan respons sekelompok gambar di situs kami di luar editor blok"
• pengembang mempertimbangkan untuk tidak pernah menggunakan blok inti karena terlalu tidak stabil: “Saya berhenti menggunakan/memperpanjang blok inti karena terlalu banyak berubah dan saya telah menggunakan Blok ACF sehingga setidaknya saya tahu bahwa saya dapat membuat blok yang tidak merusak. Memang UI tidak sebagus blok inti tetapi saya akan mengambil stabilitas dari blok yang pecah kapan saja. ”

Plugin Gutenberg dimaksudkan untuk berfungsi sebagai plugin fitur di mana gangguan dalam kompatibilitas mundur diharapkan sementara kontributor memoles fitur sebelum menggabungkannya menjadi inti. Kembali ke akar pendekatan ini, dan membuat editor kurang eksperimental, adalah inti dari proposal ini.

“Ketidakstabilan antar versi sudah mulai mengasingkan beberapa pendukung eksternal terbesar editor blok,” kata Wilson.

Mempertahankan tingkat ketidakstabilan ini dapat mencegah orang membangun di WordPress, mendorong mereka ke proyek lain yang lebih mudah yang dikelola dengan cara yang berbeda. Ada kemungkinan bahwa kebutuhan untuk mengandalkan API eksperimental telah membuat pengembang enggan membangun lebih banyak produk, memperlambat adopsi editor blok.

“Sebagai pembuat plugin yang saat ini menggunakan banyak __experimental API, saya ingin melihat ini stabil,” kata kontributor yang disponsori WP Engine, Nick Diego. “Sebagian besar menyediakan fungsionalitas penting tetapi membangun produk yang bergantung pada __experimental API selalu sedikit membingungkan. Selama prosesnya sangat transparan, dipublikasikan dengan baik, dan kami menyediakan panduan bagi penulis plugin/tema tentang cara bermigrasi ke versi stabil, maka saya menyukai inisiatif ini.”

Setelah berbulan-bulan berdiskusi tentang tiket, Zielinski menyaring kekhawatiran kontributor ke dalam rencana aksi yang diusulkan di blog Make WordPress Core.

Proposal tersebut menunjukkan bahwa sebagian besar API eksperimental yang sudah ada yang telah digabungkan menjadi inti akan mendapatkan alias yang stabil.

“Ini akan menjaga kompatibilitas mundur dan seharusnya tidak terlalu mempengaruhi ukuran bundel,” kata Zielinski. “Beberapa akan membutuhkan perawatan yang berbeda; mari kita bahas kasus per kasus itu.” Dia juga merekomendasikan kontributor untuk mempertimbangkan apakah API eksperimental yang sudah ada di inti perlu dihapus. Dia tidak mengantisipasi banyak contoh ini tetapi merekomendasikan ini menggunakan praktik yang mapan untuk menghubungi penulis plugin, menggunakan penghentian lunak, dan menerbitkan posting Inti.

“Saya juga melihat dua hal yang berperan di sini: penggunaan dan penyalahgunaan API eksperimental selama desain API (umumnya untuk digunakan dan diuji dalam plugin Gutenberg) dan kurangnya proses yang rajin untuk menstabilkannya ketika memenuhi kriteria desain,” Arsitek utama Gutenberg Matias Ventura mengomentari tiket asli. “Yang dianggap publik secara de facto adalah yang telah ada untuk banyak rilis dalam bentuk yang stabil terlepas dari nomenklaturnya.”

Demi menjaga kemampuan WordPress untuk memenuhi janji kompatibilitas mundur, proposal tersebut merekomendasikan API eksperimental dibatasi untuk plugin Gutenberg dan tidak pernah digabungkan menjadi inti. Dalam kasus di mana fitur stabil bergantung pada API eksperimental, Zielinski mengidentifikasi jawaban sederhana:

“Maka itu sebenarnya tidak stabil. Mari kita stabilkan dependensinya terlebih dahulu. ”

Ini pada dasarnya adalah cara baru untuk bergerak maju yang akan meningkatkan stabilitas dan kepercayaan pada API dan pembaruan WordPress, tetapi ini memiliki beberapa kelemahan.

Pengguna dan kontributor dapat mengharapkan bahwa fitur Gutenberg mungkin lebih lambat bergabung ke dalam inti, karena mereka tidak dapat mengandalkan API eksperimental ketika mereka mencapai distribusi prime time dalam rilis utama. Zielinski juga mencatat bahwa kontributor mungkin juga mengalami kesulitan untuk memfaktorkan ulang API ini setelah mereka dikirim dan digunakan di jutaan situs WordPress.

Sejauh ini proposal tersebut mendapat dukungan yang sangat positif, karena banyak yang percaya bahwa API ini seharusnya tidak pernah sampai ke inti di tempat pertama saat masih dalam tahap percobaan.

“Saya sangat mendukung pendekatan ini,” kata pengembang WordPress Mark Root-Wiley. “Saya membuat tema khusus dan memiliki beberapa plugin sederhana. Untuk keduanya, saya menemukan diri saya agak sering dipaksa untuk berurusan dengan API eksperimental dan kesulitan untuk tetap up to date dengan mereka ketika fitur dimasukkan ke dalam inti yang hanya dapat dimatikan, disesuaikan, atau diperluas melalui API eksperimental.

“Kembali ke stabilitas inti semacam ini akan sangat membantu untuk mendapatkan kembali beberapa niat baik pengembang,” kontributor WordPress Dovid Levine mengomentari proposal tersebut.

Batas waktu untuk mengomentari proposal adalah 7 September, yang akan menutup diskusi hanya tiga minggu sebelum WordPress 6.1 Beta 1 diharapkan. Ini memberi kontributor waktu untuk lebih mengaudit API eksperimental sebelum rilis besar berikutnya, jika mereka mencapai konsensus untuk membatasi mereka ke plugin Gutenberg.