Gutenberg menghormati dukungan editor seperti yang dideklarasikan oleh CPT dan tidak akan memuat jika itu tidak didukung.

Jika ini berarti bahwa Gutenberg tidak memuat sama sekali dan editor Klasik digunakan sebagai gantinya, maka itu membuat kami berada di jalur menuju admin WP yang retak yang terbagi antara lingkungan Gutenberg dan Klasik. Ini akan berdampak buruk bagi WordPress dalam banyak hal.

• Pengguna baru harus mempelajari cara utama dan halus di mana kedua jenis antarmuka berbeda. Tindakan sederhana seperti memublikasikan postingan atau mengubah ke tampilan teks bekerja secara berbeda di editor Gutenberg dan Klasik.

• Pengembang yang ada akan dipaksa untuk mempertahankan fungsionalitas tema dan plugin mereka di kedua lingkungan. Kami tidak berbicara tentang masa transisi; kita berbicara tanpa batas. Plugin yang dimaksudkan untuk memperluas jenis posting apa pun akan paling terpengaruh. Jika pengembang tersebut akhirnya mengubah kotak meta mereka menjadi blok, maka mereka masih harus mempertahankan kotak meta lama jika ada yang menggunakan plugin mereka dalam jenis posting non-Gutenberg.

• Pengembang plugin baru yang memasuki pengembangan WordPress harus mempelajari cara membuat plugin dengan dua cara berbeda. Dengan asumsi mereka merangkul blok Gutenberg, fungsionalitas plugin mereka bahkan mungkin tidak tersedia dalam jenis posting menggunakan editor Klasik.

Sebanyak yang saya yakini kita harus membuat kotak meta berfungsi, cukup mematikan Gutenberg bukanlah solusi terbaik dalam jangka panjang.

Jika ini berarti bahwa Gutenberg tidak memuat sama sekali dan editor Klasik digunakan sebagai gantinya, maka itu membuat kami berada di jalur menuju admin WP yang retak yang terbagi antara lingkungan Gutenberg dan Klasik.

Dalam kasus di mana CPT tidak ingin mengaktifkan editor sama sekali, itu sepertinya jalan terbaik ke depan. Ini hanyalah tampilan admin yang berbeda, dioptimalkan untuk pengalaman yang berbeda. (Tampilan "perintah" dari Woo, misalnya.) Tidak akan membantu siapa pun untuk mencoba menerjemahkannya dalam konteks Gutenberg.

Ini mirip dengan munculnya Customizer—itu adalah paradigma antarmuka baru yang melakukan beberapa hal yang sama dalam konteks yang berbeda. Kami akan selalu membutuhkan antarmuka "manajemen" dan antarmuka "pengeditan". Itulah sebagian cara kami bergerak maju, dengan mengklarifikasi berbagai tujuan antarmuka.

Tetapi karena scope creep Gutenberg, ini bukan hanya tentang mengaktifkan atau menonaktifkan jenis editor. Karena Gutenberg sekarang menentukan seluruh antarmuka pengeditan, ada seluruh daftar efek samping yang terkait dengan jenis editor yang saya cantumkan di atas.

Kami akan selalu membutuhkan antarmuka "manajemen" dan antarmuka "pengeditan".

Itulah tepatnya peran yang dipenuhi editor dan kotak meta hari ini. Itu bukan pengalaman yang terisolasi. Mereka bekerja sama.

maka mungkin scope creep harus ditangani, dan Gutenberg harus dibatasi ke area yang dihuni oleh wp_editor() . Itu pasti akan memecahkan banyak masalah kompatibilitas.

Scope Creep

Mengatasi scope creep adalah preferensi saya dan sesuatu yang banyak dari kita telah menyerukan selama beberapa bulan terakhir. Melakukannya akan memungkinkan kami untuk meningkatkan editor tanpa memisahkan pengalaman admin.

Mengaktifkan Gutenberg Per Jenis Posting

Mengenai kemampuan untuk menonaktifkan Gutenberg per jenis posting, saya ingin menekankan bahwa menghindari masalah tidak sama dengan sampai pada solusi. Menonaktifkan Gutenberg per jenis posting dapat menghindari ketidakcocokan kotak meta untuk beberapa plugin, tetapi itu merusak lanskap WordPress dalam jangka panjang.

Jika Anda tidak dapat memahami alasannya, bayangkan menjadi pengembang plugin baru yang memasuki industri ini dua tahun dari sekarang, setelah Gutenberg bergabung.

• Sebagai pengembang, apakah Anda menulis UI plugin sebagai blok atau sebagai kotak meta? Jika Anda ingin mendukung semua jenis posting, Anda harus menulisnya sebagai keduanya.
• Saat pengguna mencari plugin, apakah mereka sadar bahwa fungsionalitas yang Anda janjikan di halaman plugin Anda hanya berfungsi di jenis posting yang mendukung Gutenberg? Apakah mereka akan kecewa ketika mengetahui bahwa mereka tidak dapat menggunakannya bersama editor Klasik?
• Ketika pengguna yang sama menghubungi Anda untuk mendapatkan dukungan, apakah Anda tahu jika mereka bertanya tentang cara kerja plugin Anda di editor Klasik atau editor Gutenberg. Apakah pelanggan itu tahu bedanya?
• Ketika Anda ingin menambahkan fungsionalitas beberapa bulan setelah peluncuran, apakah Anda bersedia melipatgandakan waktu pengembangan Anda untuk membangun fungsionalitas itu ke dalam kotak meta PHP dan blok JS?

Itu hanya beberapa pertanyaan yang membingungkan lanskap ketika kita bergerak maju dengan dua editor dan tidak ada jalan menuju singularitas di UI.

show_in_rest

Fakta bahwa postingan tidak dapat menggunakan Gutenberg saat show_in_rest tidak disetel hanyalah contoh lain dari fungsionalitas yang tidak terkait yang memengaruhi pengalaman pengeditan. Tidak ada alasan mengapa preferensi saya untuk visibilitas posting publik di REST API harus memengaruhi antarmuka apa yang saya gunakan saat mengedit. Saya mengerti alasan teknisnya tetapi logikanya tidak ada, dan saya curiga banyak pengembang bahkan tidak menyadari ini adalah batasan pada saat ini.

Bagaimana Gutenberg keluar dari cakupan parameter wp_editor() masih membingungkan saya. Jika "editor" Gutenberg akan dibatasi ke wp_editor() maka "mengaktifkan sebagai opsi" per jenis posting menjadi kenyataan dan jauh lebih mudah dikelola dan diperluas di masa depan. Saya masih belum melihat penjelasan rasional tentang mengapa scope creep Gutenberg tidak dapat dikurangi dan hanya ditampung di dalam wp_editor().

Tidak masuk akal jika Gutenberg diaktifkan untuk Jenis Posting Kustom yang tidak menggunakan editor dan yang tidak langsung ditampilkan di frontend.

Saya telah melihat berbagai situs web di mana CPT digunakan tidak hanya untuk jenis posting asli, tetapi sebagai metode untuk membuat antarmuka admin untuk berbagai pengaturan dan elemen.

Misalnya, situs penulis tempat saya bekerja memiliki CPT untuk "Buku" dan "Tautan toko". Memiliki Gutenberg sebagai editor untuk halaman daftar Buku benar-benar masuk akal. Tetapi "Tautan toko" tidak memiliki posting atau halaman sendiri, tetapi digunakan untuk menyediakan logika tautan ke toko buku online di setiap halaman "Buku". Templat halaman Buku menampilkan Tautan Toko ke halaman produk yang cocok dengan wilayah (mis. Inggris Raya, AS) dan format (mis. eBook, cetak), menyisipkan ISBN yang disimpan dalam bidang meta pos ke dalam struktur URL setiap toko online - lihat tangkapan layar.

CPT mungkin bukan cara terbaik untuk mengelola data dan pengaturan semacam ini, tetapi ada banyak situs web yang menggabungkan berbagai fungsi menggunakan CPT tanpa editor dan bidang meta khusus - saya dapat memberikan contoh lain dari penggunaan semacam ini. Akan membingungkan dan kontraproduktif untuk memaksa editor Gutenberg ke CPT yang tidak menggunakan editor sama sekali.

Tidak masuk akal jika Gutenberg diaktifkan untuk Jenis Posting Kustom yang tidak menggunakan editor dan yang tidak langsung ditampilkan di frontend.

Tidak, itu tidak masuk akal, tetapi selama Gutenberg adalah pengganti layar penuh, maka keputusan untuk memasukkan atau mengecualikan Gutenberg memiliki konsekuensi yang lebih besar yang melampaui apakah Anda menginginkan editor dalam jenis posting Anda atau tidak.

Misalnya, bayangkan Anda seorang pengembang plugin dan Anda ingin kotak meta "Pengaturan tautan toko" Anda tersedia di satu jenis kiriman yang menggunakan Gutenberg dan jenis kiriman kedua yang tidak. Saat Anda mendistribusikan plugin ke ribuan pengguna yang mengharapkannya berfungsi dengan jenis posting apa pun, Anda tidak memiliki kemewahan untuk memilih. Saat itulah pertanyaan yang disebutkan di https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663 ikut bermain.

Perlu diulangi bahwa kotak meta yang diisolasi dalam jenis posting mereka sendiri adalah yang paling sedikit terpengaruh oleh Gutenberg, jadi kami harus mempertimbangkan bagaimana hal itu memengaruhi fungsionalitas plugin yang berfungsi di seluruh jenis posting.

Ya, saya dapat melihat bahwa plugin yang harus mendukung antarmuka Gutenberg dan non-Gutenberg akan menjadi masalah utama yang sedang berlangsung

Saya kira pertanyaannya kemudian adalah bagaimana Gutenberg harus menangani CPT yang tidak mendukung editor - bagaimana Gutenberg berfungsi dalam konteks di mana tidak masuk akal untuk membangun halaman dari blok, di mana itu hanya didorong oleh meta?

...bagaimana Gutenberg harus menangani CPT yang tidak mendukung editor - bagaimana Gutenberg berfungsi dalam konteks di mana tidak masuk akal untuk membangun halaman dari blok, di mana itu hanya didorong oleh meta?

Jika Gutenberg akan mengurangi dan hanya mengganti editor seperti dalam konsep Yoast yang saya sebutkan di https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018, maka mengaktifkan atau menonaktifkan Gutenberg menjadi cukup mudah.

• Jika editor diaktifkan, maka editor blok hadir dan kotak meta dapat muncul di atas atau di bawahnya tergantung pada kait yang digunakan.
• Jika editor dinonaktifkan, maka editor blok tidak ada dan kotak meta meluncur ke atas untuk menjadi antarmuka utama untuk jenis posting.

Pada dasarnya itulah cara kerjanya hari ini, dan dengan mempertahankan perilaku itu, itu akan memungkinkan plugin untuk secara bertahap mentransisikan kotak meta ke blok jika itu masuk akal. Itu juga akan menghindari banyak pertanyaan membingungkan yang tercantum di atas yang terkait dengan pengalaman admin terpisah.

Saya menemukan "scope creep" sebagai istilah yang aneh untuk digunakan, mengingat posting kickoff , dan berkat yang telah diterima proyek . Rasanya meremehkan pekerjaan yang sudah dilakukan, di depan umum, sejak 11 Januari di mana kami mulai mendiskusikan dan meneliti bagaimana meningkatkan pengalaman pengeditan secara keseluruhan . Tidak ada yang mengganggu kami, ini selalu merupakan rencana, dan itulah sebabnya tidak ada istilah yang ditetapkan untuk fokus.

Bagaimanapun, saya ingin berbicara sedikit tentang perspektif desain , dan mengapa saya merasa bahwa mendesain editor yang berfokus pada hanya mengganti area konten akan menjadi pengalaman yang sangat mengorbankan, hanya demi mempertahankan lengkap kompatibilitas mundur dengan setiap plugin yang dibuat untuk memperluas editor dalam dekade terakhir. Status quo adalah jalan keluar yang mudah, tetapi tidak selalu jalan yang benar.

Menambahkan blok ke editor yang ada tanpa memikirkan kembali alurnya akan menambah kerumitan di mana sudah ada kerumitan .

Mengingat mandat — untuk memikirkan kembali penulisan posting untuk melibatkan blok untuk mengganti kode pendek, HTML khusus, widget, dan banyak lagi — saya akan menyia-nyiakan tanggung jawab saya sebagai desainer dengan tidak melihat keseluruhan alur penulisan, pengeditan, dan penerbitan secara holistik.

Saya tidak yakin bahwa WordPress akan relevan dalam lima tahun , kecuali jika proyek secara keseluruhan mengambil langkah berani untuk memenuhi masa depan. Inti JavaScript telah diiklankan di ceramah State of the Word selama bertahun-tahun. Dengan mengingat hal itu, dan peluang yang kita miliki untuk secara radikal menyederhanakan penulisan konten postingan yang kaya, melihat keseluruhan pengalaman pengeditan alih-alih jendela kecil bukan hanya sebuah peluang, tetapi bisa dibilang akan lalai untuk mendesain sebaliknya, terlepas dari tantangan yang dibawanya. dengan itu.

Tidak mungkin merancang editor yang baik tanpa melihat keseluruhan layar . Ini tidak nyaman, membuat proyek menjadi sulit, dan mengingat warisan WordPress, itu membuatnya lebih sulit. Itu tidak mudah, dan kami memiliki cara untuk tetap tenang, terutama tentang bagaimana Gutenberg dapat diperluas secara asli. Tetapi mengambil setengah langkah, membangun Gutenberg untuk menggantikan hanya area teks konten, akan menjadi kerugian besar bagi WordPress dan desain yang buruk untuk boot.

Memuat satu komponen Gutenberg , hanya kanvas editor, ke layar pengeditan saat ini dimungkinkan. Ini akan menjadi pengalaman yang sangat dikompromikan dan Frankenstein dari UI, tetapi ini bisa menjadi salah satu jalan untuk dijelajahi untuk memastikan jalur migrasi yang baik dari 4,9 ke 5,0. Tetapi harus dijelaskan bahwa ini bukan pengalaman saham, atau yang optimal.

Saya kira pertanyaannya kemudian adalah bagaimana Gutenberg harus menangani CPT yang tidak mendukung editor - bagaimana Gutenberg berfungsi dalam konteks di mana tidak masuk akal untuk membangun halaman dari blok, di mana itu hanya didorong oleh meta?

@CalebWoodbridge ini sudah cara kerjanya. Lihat: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

Saya berpendapat bahwa menggunakan istilah 'scope creep' tidak benar. Ini adalah istilah yang tentu saja tidak berlaku untuk proyek yang dimaksudkan untuk melakukan apa yang dilakukan Gutenberg.

Maafkan saya karena mengambil sudut pandang ini, tapi saya pikir itu layak untuk dikatakan. Sama seperti rasa hormat yang diberikan kepada pengembang ketika mereka mengatakan sesuatu yang teknis, pikirkan tentang para desainer dengan cara yang sama. Para desainer yang mengerjakan proyek ini memiliki banyak pengalaman dan keterampilan, saya sangat menghargai pekerjaan ini dan senang menjadi pemimpin desain sebuah proyek dengan desainer yang luar biasa.

Saya merasa terhormat memiliki kesempatan untuk bekerja dengan para desainer yang ada di Gutenberg. Ini adalah kesenangan sehari-hari dan sesuatu yang tidak selalu kami dapatkan di WordPress. Sebagian besar waktu sebagai desainer pada intinya Anda adalah orang yang sendirian, sungguh luar biasa bisa bekerja sama.

Pengalaman adalah kunci ketika kita melihat pendekatan desain. @jasmussen dalam visi asli bersama dengan @matias menetapkan dasar dari pengalaman yang lengkap. Sebagai pemimpin desain kedua, ini adalah sesuatu yang saya hargai dan ingin pertahankan.

Salah satu masalah besar dengan WordPress di masa lalu dari perspektif desain adalah spiral iterasi kecil di atas iterasi kecil. Meskipun berfungsi untuk beberapa yang pertama, seiring waktu itu menambah pengalaman yang disatukan dengan tambalan perbaikan. Ada banyak WordPress yang menderita karena ini. Editor adalah satu, media adalah hal lain dan masih banyak lagi yang bisa ditunjuk.

Gutenberg telah memberi kami ruang untuk menghapus tambalan, untuk melihat apa yang kami miliki dan membangun lagi. Ini memberi kami awal dari bahasa visual yang kuat untuk beralih ke Kustomisasi dan seterusnya. Untuk benar-benar memiliki bahasa visual yang memajukan WordPress dalam 10 tahun ke depan. Ya, kita harus berpikir sejauh itu.

Saya ingin mengambil poin untuk juga memperingatkan terhadap Frankendesigns. Setiap desainer tunggal di dunia pada suatu saat memiliki seseorang yang menyarankan mereka 'letakkan saja x di sini atau y di sana'. Ini tidak memungkinkan desainer untuk mendesain. Sebagai sebuah proyek, kami berada di spiral ke bawah jika kami tidak membiarkan desainer mendesain. Ini adalah jenis proses yang terus terang, mematikan api pada desainer. Mari kita terus menyalakan api.

Ini adalah catatan pribadi, yang melampaui Gutenberg. Saya bersemangat kami menciptakan ruang di mana desainer dapat berkembang dan tumbuh - kami tidak selalu sebagai sebuah proyek. Mari kita tunjukkan dengan Gutenberg bahwa kita melakukan itu. Gairah memang hebat, tetapi hormati visi desain seperti yang kami lakukan di WordPress pada visi teknis. Mari kita dengarkan para desainer sebanyak kita mendengarkan mereka yang berbicara tentang kerangka kerja JS terbaru.

Sampai-sampai soal berani dimunculkan oleh @jasmussen , desain yang bagus itu berani. Selalu begitu. Ini juga membutuhkan ruang untuk mengeksplorasi dan berpikir, Gutenberg luar biasa untuk itu. Kami memiliki (kami masih memiliki) ruang di mana kami dapat mengeksplorasi ide-ide yang sebelumnya kami rasa terlalu berat untuk ditangani. Ada kebebasan untuk mengulangi, bereksperimen, dan mencoba. Ini telah menghasilkan beberapa desain yang luar biasa, jangan lupakan itu.

Saya ingin menjadi jelas, saya tidak mengatakan Gutenberg 'selesai' atau sempurna sebagai desain. Kita perlu mengulangi dan kita perlu menguji. Apa yang tidak kita butuhkan adalah mundur, mengambil dari bahasa desain yang kuat yang sudah mapan. Kita tidak perlu Frankendesign. Yang kami butuhkan adalah menguji, mendapatkan umpan balik, dan mengizinkan desainer untuk melakukan iterasi.

Salah satu masalah besar dengan WordPress di masa lalu dari perspektif desain adalah spiral iterasi kecil di atas iterasi kecil. Meskipun berfungsi untuk beberapa yang pertama, seiring waktu itu menambah pengalaman yang disatukan dengan tambalan perbaikan.

Mencoba mendamaikan pernyataan seperti ini dengan pernyataan publik seperti ini http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/ membuat sangat sulit bagi pengguna untuk merasa seperti mereka menerima komunikasi yang jujur ​​tentang karya tersebut sedang dilakukan. WordPress digunakan oleh jutaan orang dalam jutaan cara, dan telah dibuat dengan sangat jelas bahwa, sehubungan dengan aspek teknis seperti dukungan metabox atau format penyimpanan pos, diperlukan pendekatan tambahan, dengan kerusakan sesedikit mungkin. Keputusan ini telah memperumit beberapa bagian implementasi, dan telah memaksa keputusan yang kurang optimal tetapi didukung dengan lebih baik dalam banyak hal.

Tidaklah masuk akal untuk menahan pengembangan ke satu standar dan desain ke yang lain. Terkadang 'desain berani' perlu dikurangi untuk produksi yang wajar. Ini terkenal di manufaktur otomotif, dan itulah sebabnya mudah untuk membandingkan Gutenberg dengan mobil konsep.

Tentu, Anda menginginkan desain holistik yang menggunakan javascript untuk keseluruhan admin, tetapi itu tidak bisa menjadi rilis v5 tanpa merusak pengalaman jutaan pengguna. Sebaliknya, jika Anda mengurangi untuk fokus pada editor, daripada halaman edit, Anda dapat memberikan pengalaman yang jauh lebih baik (yang dapat mencapai banyak tujuan sekunder Anda dengan penggunaan css yang bijaksana), tanpa kerusakan.

Kemudian, dengan menyediakan Fields API yang terdokumentasi dengan baik, Anda dapat mengonversi plugin dan tema ke mentalitas blok Gutenberg selama tahun depan, dengan membuatnya lebih mudah dan lebih logis untuk menghasilkan antarmuka yang sama. Dengan sangat cepat, metabox menjadi cara lama dalam melakukan sesuatu, dan semua plugin bernilai tinggi akan beralih ke blok... sekali lagi, ini harus terjadi secara organik. Memaksa tangan orang dengan mencela fitur atau membuat antarmuka terpisah di mana pembuat plugin harus membuat kode untuk gutenberg dan metabox tidak dapat dipertahankan.

Ada baiknya Anda menyebut media overhaul sebagai area yang perlu dikerjakan ulang... yaitu area yang mengalami kerusakan akibat runaway, overhaul yang tidak fleksibel. Itu adalah bagian pertama WordPress yang sepenuhnya merangkul kerangka kerja JS, dan sebagian besar merupakan langkah mundur yang besar bagi pengembang. Kurangnya penyesuaian di Perpustakaan Media bukanlah tanda bahwa itu sempurna, melainkan karena kurangnya desain yang bijaksana yang mempertimbangkan kasus penggunaan di masa depan dan saat ini. Saya telah mencoba memodifikasi antarmuka media berkali-kali, hanya untuk menemukan bahwa seseorang, di beberapa titik memutuskan bahwa komponen utama harus dikodekan ke dalam kerangka tulang punggung. Saya benar-benar mengalami salah satu kasus ini kemarin! (seperti yang Anda lihat di paragraf ketujuh di sini: https://gschoppe.com/wordpress/disable-attachment-pages/)

Menskalakan Gutenberg kembali ke editor, daripada halaman edit akan memberi Anda jalan ke depan yang tidak merusak segalanya. Setelah Gutenberg ditetapkan dengan baik sebagai dasar antarmuka pos kustom, maka visi khusus JavaScript dapat bergerak untuk mengambil alih sisa halaman edit. Iterasi semacam ini benar-benar penting dalam paket perangkat lunak besar, kecuali (seperti yang diklaim matt tidak dapat diterima) Anda menawarkan rilis LTS, dan menjadikan setiap versi utama sebagai perubahan yang benar-benar penting.

Ada dua lubang di mana Anda berisiko jatuh, dan Anda telah mengidentifikasi salah satunya. Ya, tanpa bergerak menuju antarmuka terpadu menggunakan teknologi modern, WordPress kemungkinan akan mati dalam setengah dekade mendatang. Tetapi juga, jika WordPress gagal memberikan dukungan yang memadai untuk komunitas pengembang dan pengguna profesionalnya yang besar selama transisi ini, WordPress akan mati lebih cepat.

Bersiaplah, kurangi skala, dan berikan sesuatu yang membuka kotak alat kepada pengguna, tanpa merusak alur kerja yang ada. Kemudian Anda dapat meningkatkan skala, versi demi versi. Anda memiliki mobil konsep yang indah, tetapi yang kami butuhkan adalah mobil produksi yang berfungsi untuk semua kasus berkendara di dunia nyata. Tetapi dengan memberikan konsep, Anda dapat mengambil ide itu dan menerapkannya ke ruang lingkup yang lebih terbatas, dan dalam satu tahun, prinsip-prinsip itu akan ada di mana-mana.

@gschoppe , terima kasih telah meluangkan waktu untuk menjawab.

Pertama, beberapa kejelasan. Saya tidak setuju bahwa komentar saya bertentangan dengan posting Matias. Saya berdiri dengan pos yang dia buat sepenuhnya, itu adalah visi saya juga dan kami sebagai pemimpin proyek ini bersatu dalam cara kami melihat arah. Pendapat pribadi Anda adalah milik Anda, jadi mari kita beralih dari titik itu.

Tidaklah masuk akal untuk menahan pengembangan ke satu standar dan desain ke yang lain.

Saya setuju dan komentar saya tidak bertujuan agar desain lebih didengar atau memiliki standar yang berbeda, ini tentang mendengar semua suara, menerapkan standar yang sama untuk semua.

Ada baiknya Anda menyebut media overhaul sebagai area yang perlu dikerjakan ulang... yaitu area yang mengalami kerusakan akibat runaway, overhaul yang tidak fleksibel.

Saya ingin melihat media yang fokus dari bawah ke atas dengan desainer dan pengembang, yang belum terjadi.

Tetapi juga, jika WordPress gagal memberikan dukungan yang memadai untuk komunitas pengembang dan pengguna profesionalnya yang besar selama transisi ini, WordPress akan mati lebih cepat.

Sangat menarik Anda mengatakan ini karena tidak ada yang mengambil fungsi apa pun. Tidak ada saran desain dari Gutenberg yang melakukan itu. Dengan satu atau lain cara, semua fungsi yang ada dapat diselesaikan, bahkan jika itu menggunakan plugin editor klasik.

Saya tidak bisa memikirkan apa pun selain Frankendesign selain mengandalkan iframe untuk menyatukan UI. Sementara saya memahami kotak meta melemparkan kunci pas utama ke dalam proses desain, bagian dari desain berurusan dengan keterbatasan. Bergerak maju seolah-olah batasan itu tidak ada atau menunda rencana transisi sampai akhir akan menambah kekhawatiran lebih lanjut bagi komunitas yang sudah khawatir dan skeptis.

Jika rencana jangka panjang untuk Gutenberg adalah wilayah plugin, maka saya akan mengatakan bereksperimen tanpa batas. Tetapi jika itu tidak ditakdirkan untuk menjadi plugin yang orang-orang harus pilih daripada memilih keluar, maka itu harus berurusan secara realistis dengan inti dan semua beban yang dibawanya.

komentar saya tidak bertujuan agar desain lebih didengar

Setiap desainer tunggal di dunia pada suatu saat memiliki seseorang yang menyarankan mereka 'letakkan saja x di sini atau y di sana'. Ini tidak memungkinkan desainer untuk mendesain. Sebagai sebuah proyek, kami berada di spiral ke bawah jika kami tidak membiarkan desainer mendesain. Ini adalah jenis proses yang terus terang, mematikan api pada desainer. Mari kita terus menyalakan api.

Di setiap bisnis di dunia, desain disesuaikan dengan kendala implementasinya. Jika kompatibilitas mundur untuk metabox adalah kendala, desain harus menerimanya dan bekerja dalam batasan.

Terus terang, apakah dukungan lengkap untuk metabox, tanpa kehilangan aksesibilitas, merupakan kendala desain atau tidak? Saya ingin jawaban yang jelas, seperti halnya ribuan orang lainnya.

Tidak ada saran desain dari Gutenberg yang melakukan itu. Dengan satu atau lain cara, semua fungsi yang ada dapat diselesaikan, bahkan jika itu menggunakan plugin editor klasik.

Saat ini, Gutenberg menempatkan semua metafield dalam iframe. Itu merusak fungsionalitas pada tingkat yang sangat dalam. Kami berada di era Aksesibilitas, dan mengambil metode utama yang diharapkan untuk membuat pengalaman pengguna khusus dan memenjarakannya dalam iframe pada dasarnya menghapus semua aksesibilitas dari alat tersebut. Ini juga melipatgandakan jumlah permintaan yang diperlukan untuk memuat editor, dan memberi pengguna ui yang buruk, memenjarakan pengalaman modal layar penuh ke area kecil.

Saat ini, utas ini membahas apakah Gutenberg harus ikut serta atau tidak untuk jenis posting khusus. Jika ikut serta, keputusan UI yang sebelumnya konsisten yang dibuat oleh pengembang yang ingin mendukung semua jenis posting akan terpecah antara pengalaman Gutenberg, dan pengalaman klasik, membutuhkan dua kali kerja dev untuk memberikan pengalaman pengguna yang wajar untuk keduanya, dan memastikan tidak ada konsistensi dari pengalaman pengguna.

Saat ini, fungsi wp_editor() (yang merupakan cara praktik terbaik saat ini untuk mengimplementasikan salinan fitur lengkap dari pengalaman pengeditan pada halaman non-edit) tidak menyediakan antarmuka Gutenberg, artinya saya tidak bisa buat pengalaman edit khusus pada halaman non-posting ... apa jalan saya ke depan di sana, selain memberi pengguna UX terpisah?

Meskipun plugin untuk menghapus Gutenberg dapat memecahkan beberapa masalah, Anda tidak dapat mengirimkannya sebagai solusi untuk pengembang plugin. Mereka tidak memiliki kebebasan untuk mengatakan "jika Anda menginginkan antarmuka pengguna yang konsisten dan dapat diakses di seluruh jenis posting, Anda perlu menonaktifkan editor baru".

Penghapusan fitur BUKAN kompatibilitas mundur untuk alur kerja standar. Penghapusan fitur adalah pilihan terakhir untuk 1% pengguna yang tidak dapat diakomodasi sebagai pengalaman kelas satu. Dalam hal ini, tidak ada contoh yang saya berikan adalah masalah 1%.

Untuk menambahkan sedikit minyak ke dalam api: Baru minggu lalu, saya mengalami masalah besar dengan menggunakan iFrames, yaitu. mereka mungkin bermain bagus di sistem Desktop, tetapi dalam 90% kasus yang diuji, mereka gagal secara besar-besaran di Seluler / Responsif. Setelah menggali banyak utas papan pesan, artikel di internet, dan pertanyaan tentang Stack Overflow, saya memutuskan untuk sepenuhnya meninggalkan pendekatan iframe, karena responsivitas menjadi sangat rumit dengan em .. ugh. Beberapa tugas konversi agak mudah dilakukan, seperti "gunakan pengalihan ke subdomain sebenarnya tempat proyek berada" daripada mengandalkan iframe untuk memasang dekorasi yang bagus alias hanya menampilkan domain utama yang seharusnya, tetapi yang lain jauh lebih menyedihkan.

Meskipun demikian, dibandingkan dengan sejumlah besar pekerjaan yang harus saya lakukan untuk mendapatkan RWD dengan benar, dan yang terpenting, andal DAN dapat dipelihara, untuk bekerja dengan iframe, perputarannya jauh lebih sedikit usaha dan dengan demikian jalan keluar yang lebih baik.

Singkatnya, meskipun iframe sekilas terlihat seperti jalan keluar yang mudah, itu adalah pilihan desain yang SANGAT BURUK, bukan hanya karena (banyak) masalah aksesibilitas.

Hanya 0,02 sen saya,
cu, w0lf.

Terima kasih @mtias telah menunjukkan masalah ini.
Di bawah ini saya memposting pemikiran saya tentang bagaimana Gutenberg dapat membuka pintu bagi pengembang plugin WordPress.

Kelas CSS yang dapat disesuaikan untuk setiap blok yang ada

Dibutuhkan: Kelas CSS untuk setiap pembungkus blok dan akses penuh untuk menyesuaikannya. Akan sangat bagus jika Gutenberg membutuhkan kelas CSS di elemen paling atas bahkan dari pengembang pihak ketiga.

Tujuan: Dengan cara ini kita dapat menambahkan kelas khusus ke blok untuk penataan tingkat lanjut. Kami juga dapat menggunakan kelas untuk menambahkan animasi atau properti blok lanjutan lainnya.

Contoh penggunaan: Kami membuat situs web untuk klien besar dengan bahasa desain yang ditentukan secara ketat. Editor samping harus dapat membuat blok dengan jumlah gaya yang telah ditentukan sebelumnya yang dibuat oleh desainer kami, terutama untuk klien ini.

Atribut data yang dapat disesuaikan untuk setiap blok yang ada

Diperlukan: Kemungkinan untuk menambahkan atribut data khusus untuk pembungkus blok apa pun.

Tujuan: Alternatif yang lebih bersih dan fleksibel untuk kelas CSS khusus yang dijelaskan di atas. Dengan atribut data, kita dapat menata elemen apa pun di halaman. Selain gaya, atribut data khusus dapat digunakan untuk menyimpan metadata tambahan untuk JS.

Contoh penggunaan:

• blok responsif : tandai blok untuk ditampilkan di ponsel/desktop saja
• blok bersyarat : tandai blok yang akan ditampilkan/disembunyikan dengan JS <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"...
• blok animasi : tandai blok yang akan dianimasikan <div data-animation="on-load animation-style-3"...
• desain blok : <div data-skin="dark"...