Gutenberg: Apakah iframe merupakan solusi jangka panjang yang layak untuk kotak meta?

1. ... Gutenberg saat ini menggunakan dua iframe terpisah untuk kolom utama dan sidebar. Jika kami mendukung kotak meta yang muncul setelah Judul, secara teoritis akan menghasilkan iframe ketiga. Apakah ini akan menghadirkan masalah terkait bagaimana plugin mengantrekan aset yang harus memengaruhi semua kotak meta iframed?

Saya melakukan beberapa pengujian kinerja malam ini, dan saya menemukan penemuan ini di tab Jaringan saya yang mengkhawatirkan. Tampaknya semua aset CSS dan JS yang diantrekan di jendela induk juga diantrekan di kolom utama iframe dan sidebar iframe - artinya setiap aset diminta sebanyak tiga kali, yang secara efektif melipatgandakan jumlah permintaan aset saat menggunakan Gutenberg .

Kerusakan berat halaman berkurang dengan browser caching diaktifkan, tetapi jumlah permintaan aset masih tiga kali lipat. Saya berasumsi ini dilakukan agar setiap iframe memiliki aset yang dibutuhkan agar kotak meta berfungsi, tetapi tentunya ini bukan solusi untuk mengantre aset di masa mendatang.

Terima kasih telah membuat masalah dan wawasan Anda @kevinwhoffman. Ada baiknya untuk sedikit berpikir bahwa apa yang kita miliki saat ini untuk metabox di Gutenberg adalah sebuah eksperimen, dalam banyak hal ini adalah pola penahanan saat proyek menentukan arah yang harus diambil. Mengatakan bahwa itu adalah salah satu yang berfungsi 'untuk saat ini' tetapi bukan itu yang akan kami kirimkan.

Semua hal di atas mengatakan, saya pikir penting untuk melihat untuk apa metabox di masa depan akan digunakan. Apa kasus (jika ada) yang tidak akan dikonversi menjadi blok? Apakah semua metabox harus berfungsi di perangkat seluler? Apakah ada antarmuka alternatif yang belum kami jelajahi? Saya yakin ada. Saat ini, ini tentang melihat kemungkinan-kemungkinan itu dan menempuh jalan yang sesuai untuk negara bagian saat ini dan masa depan.

Saat ini bug yang ada dengan versi metabox saat ini di Gutenberg perlu diperbaiki dan itu adalah fokus. Performa harus diperhitungkan dalam perbaikan ini. Dari segi seluler, metabox telah lama menjadi masalah, kami tidak memperburuknya di sini. Karena itu, kami harus bekerja untuk solusi yang lebih baik di masa depan. Penting untuk mengulang kembali dan mengingat ini hanya solusi 'hari ini' karena kami mengulang dan terus bebas memikirkan opsi yang lebih baik.

Ada baiknya untuk sedikit berpikir bahwa apa yang kita miliki saat ini untuk metabox di Gutenberg adalah sebuah eksperimen, dalam banyak hal ini adalah pola penahanan saat proyek menentukan arah yang harus diambil. Mengatakan bahwa itu adalah salah satu yang berfungsi 'untuk saat ini' tetapi bukan itu yang akan kami kirimkan.

Pendekatan iframe tidak berfungsi, bahkan tidak hanya 'untuk saat ini'. Masalah terkait yang tercantum di atas memberikan contoh kotak meta yang tidak berfungsi dengan baik. Selain itu, meskipun masalah tersebut telah diperbaiki, melipatgandakan bobot halaman dan jumlah permintaan tidak boleh dianggap 'berfungsi' dalam keadaan apa pun.

Semua hal di atas mengatakan, saya pikir penting untuk melihat untuk apa metabox di masa depan akan digunakan.

Hormat kami, ini terjadi setiap kali masalah kotak meta diangkat. Tolong, daripada mengalihkan percakapan ke blok meta di masa mendatang, akan sangat membantu untuk membingkai diskusi ini seputar masalah yang dihadapi kotak meta yang ada. Sekali lagi:

Dapatkah masalah ini diatasi tanpa memerlukan modifikasi tema atau plugin yang menghasilkan kotak meta?

Saya belum melihat bukti apa pun yang menunjukkan kotak meta akan terus bekerja dengan Gutenberg. Jika jawabannya tidak, maka kita harus berhenti berpura-pura bahwa 5.0 hanya akan menjadi rilis WordPress lain dan mulai jujur ​​tentang melanggar kompatibilitas mundur.

Hai Kevin,

Terima kasih atas laporan detailnya. Saya pikir banyak masalah yang bisa disentuh sampai tingkat tertentu. Ini juga merupakan eksplorasi apakah pendekatan iframe akan berhasil, dan seberapa jauh itu dapat diambil, jadi ada baiknya untuk memiliki dialog semacam ini dan mencatat kekurangan dari pendekatan ini.

Apakah mungkin untuk meluncurkan jendela konten dari kotak meta yang melampaui iframe?

Apakah maksud Anda seperti lightbox modal yang harus memenuhi seluruh halaman?

Apakah maksud Anda seperti lightbox modal yang harus memenuhi seluruh halaman?

Itu akan menjadi salah satu contoh, tetapi saya lebih mengacu pada skenario apa pun di mana konten perlu diungkapkan yang tidak berada dalam batasan iframe.

Misalnya, dapatkah saya mengklik tombol di sidebar yang memicu kotak konten di tengah halaman? Jika kotak konten itu berada di dalam iframe, maka itu tidak akan terlihat di luar dimensi iframe di sidebar.

Langkah logis berikutnya adalah memanggil fungsi di dokumen induk dari iframe. Tetapi plugin saat ini tidak ditulis untuk bekerja seperti itu, dan mengharuskan mereka untuk dimodifikasi akan menggagalkan seluruh tujuan mendukung meta box _legacy_. Saya tidak bisa cukup menekankan bahwa solusi apa pun yang diputuskan perlu berfungsi tanpa modifikasi pada tema atau plugin yang ada.

Mengetahui betapa negatifnya implementasi iFrame terkait dengan aset plugin / tema, saya pikir ini harus memberikan jeda proyek. Jawaban sebenarnya di sini adalah WordPress mengirimkan API Bidang https://github.com/sc0ttkclark/wordpress-fields-api - tanpa itu, menerapkan metabox secara efektif dengan Gutenberg hampir tidak mungkin dilakukan jika kita peduli dengan kinerja sama sekali.

Jika kita benar-benar tidak mengirimkan Gutenberg sampai "siap" maka saya katakan kita harus memberikan perhatian yang sama pada API Fields sehingga metbox bekerja dengan benar dan mulus dengan React di Gutenberg.

Langkah logis berikutnya adalah memanggil fungsi di dokumen induk dari iframe. Tetapi plugin saat ini tidak ditulis untuk berfungsi seperti itu, dan meminta mereka untuk dimodifikasi akan menggagalkan seluruh tujuan mendukung kotak meta lama. Saya tidak bisa cukup menekankan bahwa solusi apa pun yang diputuskan perlu berfungsi tanpa modifikasi pada tema atau plugin yang ada.

Yup, pasti menjadi perhatian saya saat melakukan ini. Komunikasi silang antar iframe tidak terdengar sangat bagus. Ada alternatif lain untuk dijelajahi juga.

Akan tetapi, pasti akan ada kasus di mana plugin tema tertentu akan rusak, dan tidak mungkin mengakomodasi setiap kasus penggunaan yang mungkin, saya pikir mungkin tujuan yang lebih baik adalah menciptakan pengalaman yang baik untuk sebagian besar pengguna, dan kasus penggunaan . Sangat mungkin bahwa solusi iframe saat ini tidak memenuhi tujuan tersebut.

Mungkin perlu dicatat bahwa dalam Postingan Catatan Pengembang Penyesuai Inti baru-baru ini, ada perhatian yang diarahkan pada penghapusan penggunaan iframe sebagai _improvement_. Sepertinya langkah mundur untuk menerapkan iframe sebagai solusi di sini.

Hai mathetos,

Jika kita benar-benar tidak mengirimkan Gutenberg sampai "siap" maka saya katakan kita harus memberikan perhatian yang sama pada API Fields sehingga metbox bekerja dengan benar dan mulus dengan React di Gutenberg.

Saya setuju bahwa Fields API akan lebih baik. Namun, itu juga memerlukan orang untuk mengadopsi API bidang. Jika tidak banyak yang mau menulis ulang plugin / tema mereka untuk Gutenberg, saya rasa mereka tidak akan mau melakukannya untuk API Fields. Saya juga berpikir bahwa hal itu telah diangkat dalam edisi sebelumnya di suatu tempat, jadi saya akan merekomendasikan untuk memburunya dalam sejarah GitHub, dan menambahkan pemikiran Anda tentang bagaimana API Fields dapat bermanfaat bagi Gutenberg.

... tidak mungkin mengakomodasi setiap kemungkinan kasus penggunaan, saya pikir mungkin tujuan yang lebih baik adalah menciptakan pengalaman yang baik untuk sebagian besar pengguna, dan kasus penggunaan.

Saya setuju, dan saya pikir tujuan itu akan jauh lebih dapat dicapai jika Gutenberg terus merombak editor daripada mengambil alih seluruh halaman. Kemudian kita bisa membiarkan hook yang ada di tempatnya dan meta box bisa terus berkomunikasi satu sama lain seperti yang mereka lakukan sekarang. Selain itu, antrean aset tidak akan menjadi masalah karena akan berfungsi seperti saat ini.

Saya sangat setuju dengan konsep yang diajukan oleh Yoast, yang menurut saya akan mempertahankan banyak pekerjaan yang sudah dilakukan sambil menskalakan kembali ruang lingkup proyek untuk fokus pada komponen editor.

Sumber: https://yoast.com/gutenberg-alternative-approach/

Saya juga sangat setuju dengan proposal yang diajukan oleh Yoast. Ini menyediakan tahap sementara yang baik yang memberikan waktu bagi pembuat plugin untuk mengonversi metabox ke blok baru. Kemudian sebagai bagian dari rencana untuk penggantian seluruh pengalaman editor, WP sebagai proyek dapat mengatakan sesuatu seperti "Dalam versi x, metabox tidak akan digunakan lagi" sehingga kami memiliki _plan_ untuk bergerak menuju tujuan akhir yang lebih baik.

Hanya perlu dicatat bahwa konsep ini merusak metabox yang ada, karena tidak ada instance TinyMCE pusat untuk berkomunikasi. Alih-alih mendukung 80% metabox, ini akan mendukung 90% (Saya membuat angka-angka ini).

Konsep ini tidak menyelesaikan masalah kompatibilitas ke belakang, tetapi hanya menunda resolusinya nanti dengan masalah yang sama. Gutenberg adalah langkah pertama menuju antarmuka JS di WP dan tidak akan berhenti di Gutenberg.

Menggunakan kembali potongan Gutenberg untuk membangun konsep ini relatif bisa dilakukan, tetapi ini bukan UX yang ingin kami optimalkan, kami ingin membangun editor terbaik terlebih dahulu dan membuatnya tersedia untuk orang-orang tanpa masalah kompatibilitas mundur (pemasangan baru, tidak ada metabox .. .).

Ketika kami berpikir bahwa visi ideal Gutenberg siap untuk dikirimkan, kami akan memiliki waktu untuk membahas strategi jalur peningkatan. Konsep seperti ini adalah opsi untuk jalur peningkatan, tetapi jelas bukan sebagai produk akhir. Jalur peningkatan lainnya juga dimungkinkan.

Mari buat editor terbaik sekarang.

Ketika kami berpikir bahwa visi ideal Gutenberg siap dikirim, kami akan punya waktu untuk mendiskusikan strategi jalur peningkatan ...

Saya sangat tidak setuju dengan ini. Mengapa mencurahkan ribuan jam untuk mengembangkan editor yang ideal jika tidak dapat dibuat kompatibel dengan situs yang ada? Jika kesan pertama adalah merusak UI yang mereka andalkan, pengguna tidak akan pernah merasakan editor yang ideal sejak awal.

Mengapa mencurahkan ribuan jam untuk mengembangkan editor yang ideal jika tidak dapat dibuat kompatibel dengan situs yang ada?

Hanya untuk memperjelas,

• tidak mungkin 100% kompatibel dengan situs web yang ada, apa pun opsi yang Anda pilih untuk editor karena plugin memiliki akses penuh ke DOM, apa pun yang Anda modifikasi di dom melanggar kompatibilitas mundur.
• Hanya ada satu cara untuk memastikan kompatibilitas mundur 100% untuk setiap perubahan: Jangan lakukan perubahan. Plugin yang menonaktifkan Gutenberg sudah tersedia.
• Editor sudah kompatibel dengan sejumlah besar situs web. Tapi seperti yang lainnya, Ketika rusak, itu selalu lebih terlihat.

tidak mungkin untuk 100% kompatibel dengan situs web yang ada

Sekarang setelah ini jelas, mari buat editor yang menurut kami terbaik untuk masa depan WordPress.

Apakah semua metabox harus berfungsi di perangkat seluler?

Ya, kenapa tidak?

Apa kasus (jika ada) yang tidak akan dikonversi menjadi blok?

Untuk postingan blog, saya mengerti mengapa Blocks For Everything mungkin masuk akal, tetapi ini mungkin mengabaikan kasus penggunaan umum untuk metadata: data yang tidak terlihat. Seperti, saya dapat menggunakan metabox untuk mengekspos UI untuk menambahkan data analitik ke sebuah posting.

Untuk hal-hal seperti Jenis Pos Khusus, yang mungkin terdiri dari HANYA kotak meta, saya kesulitan memahami UI baru. Karena WordPress tidak memiliki CRUD API yang komprehensif untuk data, banyak pengembang menggunakan WP_Query dan rangkaian API terkaitnya sebagai stand-in, dan mereka menggunakan kotak meta pada layar edit CPT untuk mengisolasi UI untuk menambahkan data tertentu atau asosiasi. Banyak (sebagian besar) jenis pos khusus di alam bebas menghilangkan penekanan atau mengabaikan penggunaan tradisional "konten" - jadi untuk entri blog, ya, Konten adalah yang terdepan dan di tengah, tetapi untuk banyak kasus penggunaan CMS, WYSIWYG tidak membuat banyak akal.

Dalam iterasi saat ini, dukungan Meta Box adalah add-on, padahal dalam kenyataan banyak orang, Meta Box ADALAH UI, API, mekanisme yang mereka gunakan untuk menyusun CMS mereka. <iframe> s adalah gulag.

Dan kami melupakan nilai-nilai WP yang telah dibangun selamanya: Saya harus dapat memperbarui ke versi WP terbaru, dan tidak perlu menulis ulang apa pun. Saya memiliki begitu banyak proyek di alam liar di WP yang tidak akan pernah saya sentuh lagi. Dapatkah saya yakin bahwa beberapa dari mereka tidak akan rusak begitu saja dengan perubahan ini?

Saya akan mengakhiri dengan contoh ini: jika salah satu kotak meta "lama" saya memicu UI untuk Media untuk terbuka, bagaimana cara kerjanya dalam skenario "baru" ini, dari dalam iframe, tanpa seseorang (klien yang tidak lagi bekerja dengan saya ) menulis ulang kode?

Seperti yang telah saya lacak bersama dengan percakapan ini, saya tidak bisa tidak merasakan bahwa kekuatan-yang-ada yang berkembang dan membuat tembakan tentang Gutenberg tidak menggunakan atau menangani metabox sendiri. Rasanya seperti argumen tujuan-membenarkan-cara-cara yang mudah untuk mengatakannya karena sarana tidak dihargai secara signifikan untuk memulai.

Harap dipahami bahwa bagi banyak dari kita, kami memiliki lusinan situs yang akan langsung rusak saat diperbarui ke WordPress 5.0 - produk yang secara historis mengajari orang-orang bahwa aman untuk meningkatkan karena sangat rumit tentang kompatibilitas ke belakang. Apa yang dibahas di sini bukanlah jeda minor (misalnya gaya), tetapi penghenti pertunjukan potensial yang akan membuat sisi admin dari ribuan (atau lebih) situs langsung tidak dapat digunakan. Itu hal yang menakutkan. Sebagai sebuah industri, kami telah menjual orang-orang dengan keandalan WordPress yang kokoh.

Seperti yang ditunjukkan @staylor di atas, di sebagian besar situs web kami (situs perusahaan dengan kompleksitas kelas menengah ke atas), metaboxes _are_ UI. Editor (jika digunakan sama sekali) hanyalah sebagian darinya.

Ketika kami berpikir bahwa visi ideal Gutenberg siap untuk dikirimkan, kami akan memiliki waktu untuk membahas strategi jalur peningkatan. Konsep seperti ini adalah opsi untuk jalur peningkatan, tetapi jelas bukan sebagai produk akhir. Jalur peningkatan lainnya juga dimungkinkan.

Saya pikir itu mungkin suatu kesalahan untuk menunda ini terlalu jauh. Terutama karena banyak organisasi membutuhkan setidaknya 1-2 kuartal untuk mempersiapkan.

Ada pepatah yang saya dengar dari beberapa pengembang utama WordPress yang menurut saya penting untuk diingat di sini: Ketika seseorang mengadopsi WordPress untuk situs mereka, mereka tidak Mengadopsi WordPress 3.7 atau WordPress 4.8, mereka mengadopsi WordPress. Membuat jalur ini maju selancar mungkin mutlak diperlukan. Ini akan merusak banyak hal, dan tidak apa-apa (Ada jeda kompatibilitas di hampir setiap rilis WordPress), tetapi mereka perlu diminimalkan, didokumentasikan, dan dikomunikasikan.

tidak mungkin untuk 100% kompatibel dengan situs web yang ada

Jika Anda tidak akan cocok, daripada yakin pergi dan hancurkan barang. Panggil rilis pertama WP ++ atau WPNG. Jauh lebih baik untuk menyatakan sebelumnya bahwa segala sesuatunya kemungkinan besar akan rusak dan membiarkan orang bersiap untuk itu. "Penipuan" saat ini seolah-olah semuanya akan berjalan seperti biasa adalah buruk bagi semua orang.

Iframe buntu dalam hal kegunaan. Membuka widget pemilihan tanggal berbasis jquery di kotak meta, dan terkejut ketika mengklik di beberapa tempat acak lain di jendela tidak menutupnya. Butuh waktu beberapa menit untuk menyadari bahwa peristiwa klik berada di jendela induk dan tidak menyebar ke iframe. Jadi saya terkejut tetapi pada akhirnya saya mendapatkannya, tetapi bagaimana Anda akan menjelaskan hal seperti itu kepada pengguna? Apakah Anda mengharapkan setiap plugin menjawab pertanyaan setiap pengguna tentang harapan UX yang sepele seperti itu.
Dan bagaimana Anda mengharapkan tautan eksternal berfungsi?

Ada alasan bagus mengapa orang menggunakan iframe hanya sebagai pilihan terakhir.

Saran produktif saya, adalah untuk tidak menyatakan meta box ready, selama seo Anda tidak berfungsi dengan benar di dalamnya. Keduanya sedikit rumit dalam hal interaksi dan dipasang pada banyak situs. Jika gutenberg tidak dapat bekerja dengannya, mungkin tidak ada yang akan menggunakannya.

Saran produktif saya, adalah tidak menyatakan kotak meta siap

Seperti yang ditunjukkan oleh @karmatosed di atas: "Ada baiknya untuk berpikir sedikit bahwa apa yang kita miliki hari ini untuk metabox di Gutenberg adalah sebuah eksperimen, dalam banyak hal ini adalah pola penahanan saat proyek menentukan arah yang harus diambil. Dengan mengatakan bahwa itu satu yang berfungsi 'untuk saat ini' tetapi bukan yang akan kami kirimkan. "

Untuk memberikan beberapa data dunia nyata, saya ingin membagikan antarmuka ini dari situs WordPress yang pernah saya kerjakan sebelumnya. Bidang konten adalah bagian kecil dari jenis posting kustom ini, dan sementara beberapa bidang metabox kustom dapat dikonversi menjadi blok, sebagian besar berisi data yang digunakan oleh administrator, digunakan oleh layanan pihak ke-3 melalui REST API, atau digunakan untuk menambahkan metadata ke entri. Meskipun mungkin terlihat agak kacau, penyiapan ini dirancang khusus untuk bekerja dengan alur kerja klien dan menggunakan model konten yang ketat berdasarkan pemisahan yang jelas untuk memastikan versi situs yang akan datang dapat menangani setiap jenis konten secara independen.

Refactoring situs ini untuk bekerja dalam realitas Gutenberg akan memakan waktu lama dan membutuhkan sumber daya yang besar, jadi kecuali metabox ditangani dengan cara yang sangat cocok dengan apa yang sudah ada, pemilik situs ini kemungkinan akan kembali ke versi WP pra-Gutenberg dan tetap tinggal. di sana untuk waktu yang tidak terbatas.

Sebagai referensi, meskipun ini terlihat luas, ini bukanlah pengaturan metabox paling kompleks yang pernah saya buat atau pengaturan paling kompleks yang pernah saya lihat. Apa yang ditunjukkan contoh ini adalah solusi dunia nyata, melalui metabox, untuk memenuhi kebutuhan pemodelan konten yang tepat dan pemisahan di luar blob konten, sesuatu yang ditangani Gutenberg _must_ dengan anggun dan fungsional.

Membuat jalur ini maju selancar mungkin mutlak diperlukan.

Sepakat

Ini akan merusak banyak hal, dan tidak apa-apa (Ada jeda kompatibilitas di hampir setiap rilis WordPress), tetapi mereka perlu diminimalkan, didokumentasikan, dan dikomunikasikan.

Sepakat

tidak mungkin 100% kompatibel dengan situs web yang ada, apa pun opsi yang Anda pilih untuk editor karena plugin memiliki akses penuh ke DOM, apa pun yang Anda modifikasi di dom melanggar kompatibilitas ke belakang.

Setuju, saya tidak berpikir ada orang yang akan tidak setuju dengan Anda di sini. Namun, saya pikir masih ada ruang untuk membahas apa yang rusak dan kapan rusak. Keputusan semacam itu _juga_ memengaruhi jenis pekerjaan yang harus dilakukan pengembang untuk memperbaiki apa pun yang rusak. Ada perbedaan yang signifikan antara menyesuaikan hal-hal karena penyeleksi dom telah dimodifikasi, vs harus menulis ulang model konten khusus agar sesuai dengan paradigma Gutenberg baru di mana metabox hanya berfungsi :) Perselisihan seputar metabox menunjukkan kepada saya bahwa itu adalah sesuatu yang mungkin tidak hal yang baik untuk menargetkan pemutusan pada rilis awal Gutenberg pada intinya.

Saya _dapatkan_ bahwa semua ini adalah eksperimen, saya rasa @kevinwhoffman juga melakukannya. Saya melihat masalah ini sebagai _evaluation_ yang dipikirkan dengan matang dari eksperimen ini dan seharusnya dianggap seperti itu. Apakah eksperimen ini cukup sebagai solusi akhir? Tidak. Jadi apa percobaan selanjutnya?

Saya juga tidak berpikir kita akan melihat peningkatan besar dari pengembang yang mengubah pekerjaan mereka yang ada menjadi Gutenberg sampai proposal penggabungan ada, dengan mengingat hal itu, apa jeda dalam rilis awal masalah Gutenberg _does_.

tldr; Apakah kita mengharapkan kerusakan dengan Gutenberg? Iya! Tapi kita tetap harus selektif tentang _what_ yang kita hancurkan, dan sejauh mana kerusakan itu terjadi pada iterasi _initial_ dari Gutenberg yang digabungkan ke inti.

Ya, kita semua sudah cukup lama berada di sekitar pengembangan WordPress untuk mengharapkan beberapa hal terputus dari satu rilis ke rilis berikutnya. Dan dengan cara itulah tepatnya maksud saya. Selama kami menyajikan Gutenberg hanya sebagai pembaruan WordPress lainnya, maka itu tidak boleh merusak apa pun lebih atau kurang dari pembaruan lainnya. Jika kita merusak kepercayaan itu, tidak masalah seberapa bagus editor di penghujung hari.

Berikut tangkapan layar saat ini dari plugin yang telah saya kembangkan selama beberapa bulan terakhir. Dalam situasi ini, editor visual tidak memiliki nilai apa pun, dan mencoba memasukkan jenis antarmuka yang diperlukan ke dalam antarmuka yang dirancang untuk pengeditan visual konten tidak masuk akal.

Saya benar-benar serius mempertimbangkan apakah saya harus repot-repot terus mengembangkan ini untuk WordPress, mengingat semua pekerjaan saya mungkin dibatalkan dengan versi berikutnya.

Seperti yang Anda lihat, saya memerlukan akses ke pengunggah media di metafields saya, dan menurunkan sebagian besar halaman ke iframe akan membuat antarmuka ini sangat kikuk.

Ada jutaan antarmuka seperti ini di plugin, alat, dan situs kustom, yang dibuat di WordPress. Memperlakukan pengguna ini seperti warga negara kelas dua, yang mendukung blok "baru" tidak dapat diterima. Metabox perlu mempertahankan tingkat integrasi dan keunggulannya saat ini di halaman edit.

Saya sangat mendukung pandangan Yoast tentang Gutenberg. Tidak jelas bagi saya bagaimana "upgrade editor visual" diinterpretasikan kembali menjadi "ganti seluruh antarmuka edit posting" oleh tim Gutenberg, tetapi tampaknya secara langsung bertentangan dengan apa yang disebut "Ship of Theseus".

Dalam kasus ini, kurangnya arah yang jelas dan dukungan untuk alur kerja standar yang ada secara aktif merugikan pengembang sekarang. Bagaimana saya dapat bergerak maju membangun sebuah proyek, tanpa seperangkat pengait dan alat tepercaya yang dapat saya andalkan? Tidak masuk akal untuk berpikir bahwa proyek perangkat lunak besar seperti itu akan sepenuhnya mengubah alur kerja standar untuk pengembang dalam satu pembaruan. Dan sungguh gila bahwa percakapan ini baru saja terjadi sekarang, di bulan November, ketika rencana penggabungan disetujui di awal tahun.

@aaronjorbin yah, sepertinya ada masalah komunikasi di sini seperti di https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ itu secara eksplisit dikatakan

Rilis ini mencakup dukungan meta-box yang telah lama ditunggu (perlu diuji!),

ini bukan "ide", ini bukan "eksperimen", ini hanya sesuatu yang seperti setiap perangkat lunak mungkin masih mengandung bug. Saya tidak akan mengujinya jika itu disebut "percobaan" di posting itu.

Kembali ke subjek, saya melihat bahwa masalah utama di sini adalah upaya untuk menghindari menyatakan kerusakan. Dari pemahaman saya yang terbatas tentang bingkai bingkai JS, sangat sulit untuk menjadi "setengah hamil" dengan mereka, dan begitu Anda memutuskan bahwa kontrol layar utama Anda sudah selesai dengan mereka, semuanya perlu dilakukan dengan mereka, oleh karena itu satu-satunya cara untuk maju adalah dengan buat kotak meta warga kelas satu di layar edit gutenberg.
Karena plugin "lawas" kemungkinan tidak akan beradaptasi, ini berarti bahwa gutenberg perlu menjadi opsi keikutsertaan eksplisit untuk situs yang ada. Saya benci gagasan tentang garpu UX, tetapi setidaknya dengan cara ini akan ada jalan ke depan yang akan berhasil, dan jika itu akan dideklarasikan sekarang orang akan dapat bersiap.

Setelah membaca diskusi dan memikirkan tentang proyek yang saya bangun dengan WordPress, dan hal-hal yang saya lihat dilakukan orang-orang dengan WordPress, saya sampai pada kesimpulan bahwa Gutenberg harus memilih untuk jenis posting khusus. Ini akan memungkinkan situs web saat ini yang menggunakan CPT untuk data terstruktur untuk terus berfungsi dan situs web baru tempat WordPress digunakan sebagai CMS untuk dibangun. Saya hanya ingin mengingatkan Anda bahwa ketika mendaftarkan jenis posting kita dapat secara eksplisit menyatakan dukungan untuk bidang editor bersama dengan fitur lainnya. Lalu mengapa tidak menambahkan dukungan eksplisit untuk Gutenberg di sana? Tentu saja ini tidak akan menyelesaikan masalah dengan kotak meta yang ditambahkan ke posting dan halaman, tetapi akan memungkinkan WordPress digunakan sebagai CMS di masa mendatang.

Dapat menambahkan satu masalah baru dengan iframe tersebut. Saat sesi Pengguna keluar, layar login WP ditampilkan di atas Gutenberg, dan di dalam iframe, dua kali.

Hanya agar pengembang menyadarinya.

Semakin saya mengikuti semua ini, semakin saya yakin bahwa hanya cara yang mungkin seperti yang dilakukan Microsoft.

Windows XP = WordPress tanpa Gutenberg
Windows 10 = Wordpress dengan Gutenberg.

2 itu tidak dapat dicampur dan diperbarui dengan paket yang lain.

Joomla dan Drupal melakukannya. Kenapa tidak. Bukan sesuatu yang saya sukai sama sekali, tapi apa alternatifnya.

Setelah membaca diskusi dan memikirkan tentang proyek yang saya bangun dengan WordPress, dan hal-hal yang saya lihat dilakukan orang-orang dengan WordPress, saya sampai pada kesimpulan bahwa Gutenberg harus memilih untuk jenis posting khusus.

Seorang admin terpisah akan menjadi salah satu hasil terburuk yang bisa keluar dari Gutenberg. Saya telah menjelaskan alasannya di https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490.

Diskusi ini menjadi sangat kafka. Tampaknya tidak peduli berapa banyak orang yang mengusulkan penyelesaian pragmatis untuk titik-titik rasa sakit saat ini, ada beberapa orang kunci yang tampaknya sama sekali tahan terhadap kritik. Sayangnya orang-orang inilah yang memiliki keputusan akhir, karena sejauh ini diskusi telah menunjukkan bahwa beberapa orang kunci dapat mengatasi ratusan pengembang yang khawatir. Saya khawatir tentang semua kerusakan yang terjadi pada ekosistem WordPress. Jadikan Gutenberg sebagai editor, bukan layar edit. Jangan merusak WordPress.

Kevin Hoffman:

Saya sangat setuju dengan konsep yang diajukan oleh Yoast, yang menurut saya akan mempertahankan banyak pekerjaan yang sudah dilakukan sambil menskalakan kembali ruang lingkup proyek untuk fokus pada komponen editor. Sumber: https://yoast.com/gutenberg-alternative-approach/

Saya percaya bahwa jalur ke depan yang diusulkan oleh Yoast akan menjadi peningkatan besar untuk WordPress Core. Editor baru untuk membuat konten, yang akan diterima oleh banyak pengguna sebagai peningkatan dari yang sekarang. Langkah yang lebih kecil untuk WordPress, tetapi merupakan peningkatan besar bagi pengguna.

Ini adalah topik yang hangat. Saya akui bahwa terkadang kami (setidaknya saya) dapat meremehkan komentar saya dan saya minta maaf untuk ini. Kami menerima banyak umpan balik, baik, buruk, objektif, tidak berguna, dan terkadang sulit untuk membedakannya. Kami adalah manusia. Cobalah untuk berada di sisi lain persamaan, jadilah orang yang membangun hal ini dan menerima semua umpan balik ini. TI bisa terasa dekat dengan "serangan pribadi", otak cenderung bereaksi dengan meremehkan, kita seharusnya tidak.

Orang-orang yang mengomentari dan membaca postingan blog sering mengira kami menemukan masalah kotak meta dan semua yang terkait. Tidak. Kami sedang mengerjakan Gutenberg selama satu tahun sekarang. Mungkin Anda baru saja menemukan / mencoba Gutenberg tetapi kami tidak melakukannya, kami mengerjakannya cukup lama sekarang untuk merasa nyaman dengan sebagian besar masalah kompatibilitas ke belakang dan kami memiliki jawaban untuk sebagian besar masalah tersebut.

Harap berpikiran terbuka, dan mari kita mulai dengan menjawab beberapa pertanyaan:

Apa tujuan Gutenberg?

Tidak, dan tidak pernah, tujuan utama Gutenberg adalah membuka jalan menuju masa depan WordPress Core. Secara teknis, dengan memanfaatkan REST API, UI sisi klien dan menyatukan Konsep Inti: Widget, Shortcode, Blok, Metabox Konten di bawah konsep unik "A Block" dan pengalaman bijak dengan menjawab pertanyaan berikut: Bagaimana menyederhanakan pembuatan situs web (pikirkan penyesuaian) dan menerbitkan konten (think editor) di WordPress.

Apa tujuan Editor Gutenberg?

Tidak seperti apa yang Anda baca di sana-sini, fokusnya selalu tentang mendesain ulang seluruh halaman, Maket pertama untuk Halaman Editor Gutenberg telah diperlihatkan di pertemuan Gutenberg mingguan kedua atau ketiga. Kami masih dalam tahap pembuatan prototipe. Beberapa bulan sebelum alfa pertama. Desainnya mirip dengan yang kita miliki sekarang.

Bagaimana dengan Metabox, apakah penting untuk WordPress?

Mereka. Seperti Shortcode, Custom TinyMCE Buttons, mereka banyak digunakan dan disalahgunakan untuk memperluas halaman editor WordPress.

Apa perbedaan antara Shortcode, TinyMCE Buttons dan Metaboxes?

Perbedaan utamanya adalah bahwa "Metabox" tidak memiliki "tujuan", itu hanya cara untuk memperluas halaman editor tanpa konsistensi sementara tombol Shortcode dan TinyMCE memiliki satu.

Kode pendek adalah string yang dikonversi ke konten dalam fase rendering, Tombol TinyMCE adalah tombol kustom yang ditambahkan ke toolbar TinyMCE dan menggunakan API TinyMCE untuk berkomunikasi dengan konten editor. Metabox? Saya tidak tahu, mereka bisa apa saja, Anda tinggal menambahkan sekumpulan HTML, Javascript dan PHP untuk memperluas halaman editor dan bagaimana perilakunya saat menyimpan.

Apakah kurangnya "tujuan" ini menjadi masalah, atau keuntungan?

Baik! Ini dapat dilihat sebagai "pro", karena plugin dapat melakukan apapun yang mereka inginkan dengan editor termasuk hal-hal seperti:

• Mengganti tombol, area teks, input, div, apa pun. Akses Penuh ke DOM
• Menggunakan variabel javascript global apa pun, termasuk instance global TinyMCE

Fleksibel kan! Tapi bagaimana dengan pembaruan WordPress. Pembaruan apa pun pada layar editor. Setiap pembaruan TinyMCE, perubahan kelas apa pun, div , tombol apa pun dihapus / dipindahkan, perubahan apa pun merusak kompatibilitas dengan plugin karena sebagai pengembang WordPress Inti, Anda tidak tahu plugin apa yang menggunakan Metabox untuk.

Bisakah kita menyimpulkan bahwa untuk jangka panjang WordPress, Metabox mengunci evolusinya (terlepas dari Gutenberg)?

Ya begitulah. Dan sejarah Internet berkali-kali membuktikan bahwa teknologi yang tidak berevolusi mati. (tolong jangan bereaksi dengan 👎 Jika Anda tidak menyukai jawaban ini, itu fakta dan bukan pendapat)

Oke, tapi bagaimana kita bisa memajukan WordPress jika kita terjebak dengan Metabox?

Itu pertanyaan yang bagus dan sebelum menjawabnya, kita perlu memahami penggunaan Metabox saat ini di plugin WordPress

Untuk apa plugin saat ini menggunakan Metabox?

Menurut saya, ada dua kategori plugin "Metabox":

• Metabox sebagai konten (sering disimpan dalam meta posting tetapi tidak selalu)
• Metabox sebagai Peningkatan pengalaman editor (SEO, periksa ejaan,…)

Oke, mengetahui hal ini, bagaimana kita bisa maju?

Kami membutuhkan tiga hal:

• Sediakan cara untuk membangun atau meningkatkan plugin ini saat Gutenberg (atau pembaruan apa pun ke WordPress) dikirimkan.
• Berikan jalur peningkatan terbaik untuk orang-orang yang menggunakan plugin ini. Ini termasuk: lihat apakah plugin ini masih dapat bekerja dengan evolusi yang akan datang dan cara meminimalkan kerusakan.

Oke, tetapi bukankah Anda mengatakan bahwa perubahan apa pun pada halaman editor akan merusak plugin (termasuk hanya mengganti area konten)?

Baik! Jadi jika keinginan kami adalah untuk tidak merusak plugin apa pun, kami memiliki opsi unik. Berikan cara untuk tetap menggunakan halaman edit saat ini tanpa perubahan. Untuk itulah plugin menonaktifkan Gutenberg.

Saya tidak akan menyebut ini jalur peningkatan yang baik secara pribadi, ini bahkan bukan peningkatan, ada yang lebih baik?

Jalur peningkatan ini (menonaktifkan Gutenberg) adalah suatu kebutuhan, tetapi ya, kami dapat melakukan lebih baik. Jika Anda melihat plugin menggunakan Metabox, 90% di antaranya tidak memiliki interaksi dengan area konten, jadi, jika kami hanya mengganti area konten (pendekatan Anda), kami akan merusak 10% dari plugin saja.

Jadi, satu-satunya cara tanpa kerusakan adalah menonaktifkan Gutenberg.

Pengalaman Pengguna Gutenberg yang optimal terdiri dari mengganti plugin metaboxes dengan plugin yang menyediakan fungsionalitas yang sama dengan API Ekstensibilitas Gutenberg yang baru.

Karena itu, kami memperhatikan bahwa sebagian besar plugin yang menggunakan Metabox menggunakannya sebagai konten yang disimpan untuk memposting meta dan kami dapat membuatnya berfungsi di layar Gutenberg untuk menikmati seluruh pengalaman sementara penulis plugin meningkatkan plugin mereka.

Apakah ini solusi iframe yang dibicarakan semua orang?

Ya itu. Kami menunjukkan kotak meta di iframe yang memiliki kekurangan (tautan, modal, memuat ulang aset) tetapi pada saat yang sama memungkinkan 80% plugin berfungsi sambil menikmati seluruh Pengalaman Gutenberg. Solusi ini baru saja mendarat dan kami masih bereksperimen dengannya. Yang pasti, adalah tidak ada cara untuk membuat semua metabox berfungsi dan membuat perubahan pada editor.

Begitu, bisakah Anda merangkum kemungkinan peningkatan?

Tentu.

1- Nonaktifkan Gutenberg: jangan merusak 100% plugin
2- Gutenberg hanya menggantikan area konten: 90% dari plugin berfungsi, UX menderita
3- Gutenberg menggantikan seluruh layar: 80% plugin berfungsi, UX lebih baik
4- Gutenberg dengan plugin yang kompatibel: UX terbaik

Jadi apa yang harus kita lakukan?

Tujuan kami adalah membuat opsi ke-4 karena ini adalah opsi terbaik untuk masa depan WordPress. Tujuan kami juga adalah untuk membangun Gutenberg dengan cara yang dapat kami gunakan kembali untuk mendapatkan opsi ke-2 dan ke-3 jika diperlukan.

Bagaimana saya bisa ikut serta pada opsi di atas yang lain?

Ini belum diputuskan. Memiliki plugin untuk memilih jalur peningkatan mana yang Anda inginkan adalah kemungkinan. Mendowngrade secara otomatis dengan mendeteksi beberapa Metabox adalah sebuah pilihan ...

Itulah pendapat saya untuk menjelaskan alasan di balik masalah ini, jika Anda ingin menjawab dengan kata-kata seperti "konyol", "tidak dikelola dengan baik", "implementasi yang buruk" ... kesabaran saya sebagai pengembang sederhana yang menghabiskan sepanjang tahun memikirkan tentang cara terbaik ke depan untuk WordPress secara keseluruhan (inti dan komunitas) hampir mencapai batas. Saya pribadi mungkin tidak menjawab lebih lanjut tentang masalah ini, tetapi saya mendengarkan umpan balik dan akan menyesuaikan alasan saya jika diyakinkan oleh umpan balik.

Kami semua berada di perahu yang sama, kami menginginkan yang terbaik untuk WordPress.

Penjelasan yang sangat teliti, Riad. Terima kasih telah meluangkan waktu untuk menulisnya. Izinkan saya membantu Anda menghindari batas itu dengan 💪 dan 🤗. Semoga membantu.

Berkenaan dengan metabox, saya akan sangat senang jika memiliki API Bidang pada intinya. Akan menulis ulang plugin kami hanya untuk menyingkirkan semua solusi metabox kustom yang cenderung berkumpul setelah beberapa waktu.

Sekarang bagi orang-orang yang memiliki penyiapan metabox kompleks, Fields API adalah penyelamat mereka selama mereka membangunnya di atas kerangka kerja seperti ACF atau CMB. Pengembang kerangka kerja tersebut hanya perlu beralih ke API baru dan semuanya baik-baik saja. Bukan tugas yang mudah, tapi bagus untuk semua orang. Sekarang bagi mereka yang memiliki barang-barang "hard-code" yang tergeletak di sekitar, sekarang adalah saat yang tepat untuk mengatur ulang hal-hal dengan cara yang lebih bersih, lebih terbukti di masa depan. Anda dalam kondisi yang lebih baik, Gutenberg atau tidak.

Kami adalah manusia. Cobalah untuk berada di sisi lain persamaan, jadilah orang yang membangun hal ini dan menerima semua umpan balik ini. TI bisa terasa dekat dengan "serangan pribadi", otak cenderung bereaksi dengan meremehkan, kita seharusnya tidak.

Ada manusia yang bekerja sangat keras di Gutenberg. Ada manusia yang mata pencahariannya (tema dan pluginnya) akan terpengaruh oleh Gutenberg. Dan ada manusia yang menggunakan tema dan plugin yang dipengaruhi oleh Gutenberg untuk melakukan pekerjaannya sendiri. Kami semua memperhatikan satu sama lain dan menginginkan yang terbaik untuk WordPress di penghujung hari. Meskipun kita mungkin sangat tidak setuju tentang apa arti "terbaik".

Tidak seperti apa yang Anda baca di sana-sini, fokusnya selalu tentang mendesain ulang seluruh halaman, Maket pertama untuk Halaman Editor Gutenberg telah ditampilkan di pertemuan Gutenberg mingguan kedua atau ketiga ...

Maket saja tidak menandakan bahwa basis kode dari seluruh halaman pengeditan akan ditulis ulang di React. Tidak ada yang tahu melihat mockup bahwa kait kritis akan dihapus atau kotak meta rusak. Namun, ketika menjadi jelas bagi saya bahwa pengambilalihan halaman penuh akan menimbulkan masalah untuk kotak meta, saya menyuarakan kekhawatiran itu pada tanggal 15 Juni , sehari sebelum 0.1.0 diberi tag untuk rilis. Empat bulan dan 15 rilis kemudian adalah pertama kalinya kami benar-benar melihat kotak meta muncul di antarmuka, dalam iframe.

Saya membuat masalah ini berdasarkan pengalaman saya mengikuti dan menguji Gutenberg sejak tahap pra-alfa. Ini hanyalah masalah terbaru yang terkait dengan tantangan kotak meta yang sedang berlangsung, tetapi yang terpenting, ini adalah yang pertama berdasarkan pengujian konkret dari penerapan kotak meta Gutenberg.

Perbedaan utamanya adalah bahwa "Metabox" tidak memiliki "tujuan", itu hanya cara untuk memperluas halaman editor tanpa konsistensi sementara tombol Shortcode dan TinyMCE memiliki satu.

Ini sekali lagi menandakan kesalahpahaman mendasar tentang bagaimana kotak meta digunakan oleh pengembang plugin dan tema. Kami berharap bahwa shortcode dan tombol TinyMCE akan perlu diadaptasi karena mereka sebenarnya digunakan dalam editor konten. Kotak meta tidak.

Menyarankan bahwa kotak meta — blok bangunan dasar pengembangan WordPress kustom — tidak memiliki tujuan lagi untuk memberi tahu komunitas bahwa Gutenberg memprioritaskan pengalaman inti "pemasangan baru" dengan mengorbankan pengembang plugin dan tema.

Pembaruan apa pun pada layar editor. Setiap pembaruan TinyMCE, perubahan kelas apa pun, div baru, tombol apa pun dihapus / dipindahkan, perubahan apa pun merusak kompatibilitas dengan plugin karena sebagai pengembang WordPress Inti, Anda tidak tahu plugin apa yang menggunakan Metabox untuk.

Kita mungkin tidak tahu tujuan dari kotak meta, tapi kita tahu persyaratan dasar untuk mendaftarkan kotak meta dan kait yang mereka gunakan. Kami tahu bahwa tidak ada yang dikembangkan untuk bekerja dalam iframe. Selama bertahun-tahun kami telah memahami cara memperluas dan menyempurnakan WordPress tanpa merusaknya. Sekali lagi, jika 5.0 hanyalah rilis WordPress lainnya, maka jumlah kerusakan seharusnya tidak berbeda dari rilis lainnya.

Kami menunjukkan kotak meta di iframe yang memiliki kekurangan (tautan, modal, memuat ulang aset) tetapi pada saat yang sama memungkinkan 80% plugin berfungsi sambil menikmati seluruh Pengalaman Gutenberg.

Jika Anda memiliki bukti untuk angka 80% / 90% ini yang terus-menerus direferensikan, silakan bagikan. Jika tidak, mohon jangan gunakan statistik hipotetis saat meminta komunitas untuk membuat keputusan sebesar ini.

Tolong Berhenti dan Evaluasi Ulang Sekarang, Bukan Nanti

Setelah semua diskusi ini dan apa yang saya pikir adalah bukti bahwa iframe bukanlah solusi jangka panjang yang layak, saya menemukan https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341476059 yang sepertinya menambahkan yang ketiga iframe ke Gutenberg.

Sudah waktunya untuk berhenti mengejar editor yang ideal seolah-olah batasan tidak ada, dan mulai mempertimbangkan pendekatan yang tidak merusak WordPress.

Berbicara sebagai pengembang yang telah mengamati dan mendiskusikan editor Gutenberg sejak hari pertama, saya menyesal mengatakan bahwa argumen Riad memiliki lubang besar.

Pertama, orang telah mengemukakan masalah metabox sejak hari pertama, bersama dengan beberapa masalah lain yang masih mengudara. dalam fase Mockup kami diberi tahu "semuanya adalah kasus visual terbaik, kami akan membahas metabox nanti". Kemudian, pada fase prototipe munculah "Ini semua bukti kode konsep, metabox akan ditangani nanti". Kemudian ketika iterasi pertama dari fitur plugin dirilis (yang, sangat mengejutkan bagi siapa pun, bukan penulisan ulang dari awal, dan hanya pengemasan ulang dari bukti kode konsep saat ini), argumen itu tiba-tiba menjadi "Antarmuka lama seperti metabox akan memiliki beberapa dukungan untuk saat ini". Kemudian, ketika protes publik menjadi memekakkan telinga, itu adalah "kami salah bicara, metabox bukanlah warisan". Tapi sekarang, argumen ini hanya mendorong agenda "warisan" lagi.

Metabox bukan kode lama, karena saat ini tidak ada pengganti yang layak.

Dalam metabox, saya bisa dengan mudah menambahkan editor bersarang berfitur lengkap menggunakan wp_editor . Gutenberg saat ini tidak memiliki UI untuk blok bersarang, dan tidak dijadwalkan untuk rilis 5.0, sehingga tidak dapat melakukan hal yang setara, tanpa sejumlah besar kode UI khusus.

Itu adalah satu contoh, tetapi merendahkan pengalaman metabox bukanlah solusi yang dapat diterima, sampai Gutenberg melampaui paritas. Itu tidak akan terjadi oleh WP 5.0

Berikut ini peta jalan menuju rencana "admin terpadu" untuk Gutenberg yang benar-benar akan berhasil:

• batasi rilis awal ke area yang saat ini dihuni oleh wp_editor, tetapi berikan Blok UI lengkap dalam ruang itu
• mempromosikan dan memperluas fleksibilitas dan kemampuan yang diizinkan oleh block ui, dengan mengirimkan api bidang yang membuatnya mudah untuk dirancang di ruang itu
• saat popularitas tumbuh, ganti bagian lain dari ui dengan instance Gutenberg dalam kotak pasir yang serupa. Menu, widget, penyesuai, dan Perpustakaan Media adalah semua antarmuka yang relatif stagnan bagi pengembang, dan dapat memanfaatkan struktur UI yang umum.
• karena UI umum menjadi lebih fleksibel dan bertenaga, orang akan memilih untuk menggunakannya melalui metabox, karena ia menawarkan seperangkat alat umum, dan lebih banyak opsi
• secara bertahap menggabungkan lubang di antara contoh Gutenberg yang terisolasi, karena perkembangan di ruang tersebut mandek.

Dengan begitu, developer bisa mulai memanfaatkan Gutenberg pada alat produksi tanpa kehilangan kemampuan yang dimiliki saat ini. Gutenberg akan mendapatkan keuntungan dari semua kasus penggunaan edge yang dikembangkan untuk para pengembang ini, menciptakan solusi fleksibel yang benar-benar akan memenuhi kebutuhan mereka yang saat ini menggunakan metabox.

Pada saat metabox tidak digunakan lagi, pembuat plugin akan memiliki cukup waktu untuk mempelajari dan menggunakan manfaat Gutenberg di alam liar, dan itu akan menjadi pilihan yang jelas.

Gutenberg seperti mobil konsep. Skala mundur sekarang, dan kirimkan perbaikan berulang ke editor (bukan halaman editor). Kemudian, selama satu atau dua tahun ke depan, Anda dapat menjalankan proyek menuju cakupan admin 100%.

Saya hanya ingin masuk dari perspektif penyedia layanan klien yang telah mereferensikan komitmen vokal WordPress untuk kompatibilitas mundur untuk meredakan kekhawatiran klien tentang pembaruan yang merusak situs web mereka. Dengan itu, saya menyadari bahwa penggunaan WordPress saya kemungkinan besar telah mengubah persepsi saya tentang layar edit.

Sampai saat ini, sepertinya masalah ini telah diremehkan / diberhentikan / diremehkan ketika di kotak meta dunia saya telah menjadi titik penjualan _major_ untuk WordPress sejak Jenis Posting Kustom menjadi mudah tersedia untuk digunakan secara luas. Saya senang diskusi ini terjadi.

Gutenberg adalah proyek yang mengesankan, ya, tetapi klien tempat saya bekerja sangat senang dengan solusi berbasis kotak meta yang telah mereka sediakan. Memiliki opsi untuk menonaktifkan Gutenberg itu bagus, tetapi saya khawatir tentang hal itu yang disisihkan melalui plugin. Terlepas dari upaya terbaik saya untuk melatih pelanggan, saya tidak membayangkan mereka akan bersedia memasang plugin baru sendiri, mereka juga tidak akan tahu apa itu Gutenberg bahkan jika secara terang-terangan ditampilkan di layar selamat datang peningkatan.

Ada kemungkinan (bahkan kemungkinan besar) bahwa plugin kotak meta yang saya gunakan di situs klien dapat diperbarui menjadi "kompatibel dengan Gutenberg" tetapi bahkan seluruh alur kerja akan berubah untuk klien tersebut dalam semalam. Rasanya seperti menanyakan banyak klien tersebut ketika alur kerja mereka yang ada telah berjalan dengan baik untuk mereka sejak situs mereka dikirim namun lama sekali.

Saya sepenuhnya mendukung tujuan Gutenberg meningkatkan pengalaman pengguna, tetapi menurut saya kami tidak dapat menghindari preseden yang telah diterapkan (disengaja atau tidak) untuk menggunakan kotak meta untuk pengeditan konten. Saya pikir pendekatan Yoast sangat bagus, itu adalah sesuatu yang mencentang sejumlah kotak centang untuk berbagai macam solusi potensial untuk masalah ini.

Hanya dua sen saya, berharap untuk mengamati hasilnya di sini.

Jumlah plugin yang bekerja dengan Gutenberg mungkin 80%, 90% atau 0% seperti dalam pengujian kami, yang harus dihindari adalah ribuan dan ribuan pemilik situs harus mencari tahu sendiri apakah konfigurasi mereka mungkin akan berfungsi atau tidak akan berfungsi dengan Gutenberg. Itu akan membuang-buang waktu (= uang), menyebabkan banyak kebingungan dan membunuh banyak kepercayaan.

Saya ingin melihat plugin / tema ditandai sebagai kompatibel / tidak kompatibel dengan Gutenberg (atau 'tidak relevan'), sehingga pemilik situs dapat diberi tahu tentang potensi masalah sebelum hal itu menjadi aktif di situs mereka dan dapat bertindak sesuai kebutuhan. Data tidak hanya dapat berasal dari pemilik plugin tetapi juga dari uji komunitas selama waktu pengujian beta (beta nyata ..., dan rentang waktu itu harus lama, tidak hanya beberapa minggu.) Dan seterusnya.

Saya sadar bahwa ini tidak akan pernah lengkap atau 100% akurat, tetapi harus dapat dilakukan untuk plugin yang paling menonjol.

PS.
Untuk proyek saya sendiri (platform situs mikro intranet untuk klien> 30.000 karyawan, dan sekelompok situs bisnis kecil / nirlaba) kami memutuskan untuk menonaktifkan Gutenberg hingga setidaknya satu tahun berhasil di alam liar.

Persentase tidak menceritakan keseluruhan cerita. Setiap diskusi tentang dampak Gutenberg perlu mempertimbangkan berapa banyak situs web yang terpengaruh oleh penerapan metabox-nya, daripada berapa banyak plugin yang terpengaruh. Gutenberg hanya dapat memengaruhi beberapa plugin dan masih memengaruhi jutaan pengguna, karena beberapa plugin yang paling banyak digunakan bergantung pada metabox dan bidang khusus - ACF dan Yoast SEO menjadi dua contoh yang jelas.

Saya telah mengikuti perkembangan Gutenberg dari jauh selama berbulan-bulan sekarang dan saya _ tahu_ bahwa masalah metabox telah ada sejak lama. Saya mendukung filosofi di balik Gutenberg dan saya pikir akhirnya Gutenberg akan menjadi bagian yang sangat kuat dari inti WordPress yang memungkinkan WordPress menjadi perangkat lunak yang layak dan kompetitif selama bertahun-tahun di masa depan. Saya SANGAT memahami seluruh konsep Gutenberg dan tujuannya.

Apa yang saya _tidak_ mengerti adalah keinginan untuk naik dari 0 ke 100 sekaligus. Mengapa rilis berulang bukan jalur yang diambil di sini? Mengapa dua opsi 'tidak merusak apa-apa' atau 'menghancurkan segalanya'?

Metabox adalah alasan mengapa WordPress sekuat itu. Tujuannya adalah untuk memperluas layar edit.

Saya pikir itu bagus bahwa Gutenberg ingin merombak seluruh layar, tapi menurut saya itu tidak realistis untuk dilakukan sekaligus, terutama jika itu berarti memperlakukan salah satu komponen terpenting WordPress (sejauh pengembangan khusus..yang mana adalah bagian besar dari kesuksesan WordPress) sebagai tambahan.

2- Gutenberg hanya menggantikan area konten: 90% dari plugin berfungsi, UX menderita

UX tidak menderita. Pengguna akan melihatnya saat bagian editor dirubah. Ini akan memberi mereka cara baru untuk membuat konten - cara yang sebagian besar dari mereka akan temukan memberdayakan setelah mereka menyesuaikan, dan itu tidak akan merusak alur kerja yang ada yang mereka miliki atau membuat mereka bertanya-tanya bagaimana menyelesaikan hal-hal yang biasa mereka capai. editor.

4- Gutenberg dengan plugin yang kompatibel: UX terbaik

Ini adalah tujuan yang sangat bagus, tetapi ini adalah tujuan jangka panjang. Akhirnya ya, tentu saja, itu harus Gutenberg dengan plugin yang bekerja dengan atau di dalam pengalaman Guteneberg.

Tujuan kami juga adalah untuk membangun Gutenberg dengan cara yang dapat kami gunakan kembali untuk mendapatkan opsi ke-2 dan ke-3 jika diperlukan.

Saya tidak begitu yakin apa artinya ini. Anda ingin membangun Gutenberg dengan asumsi bahwa semua plugin hanya bekerja dengannya, dan menggunakan solusi itu untuk mengayuh kembali ke opsi 2 dan 3? Membangun pertama menuju 2 dan kemudian beralih ke 3, bukankah itu yang akan membawa kita ke 4?

Saya suka peta jalan yang diusulkan oleh @gschoppe , sebagai pengembang yang membangun situs web WordPress khusus, ini adalah pendekatan yang dapat saya lakukan, pendekatan yang tidak akan berdampak negatif pada pengembang atau klien mereka atau pengguna WordPress biasa, dan masih membawa kami sampai akhir tujuan Gutenberg - meskipun dengan kecepatan yang lebih mudah untuk ditelan.

Seiring dengan kekhawatiran Kevin tentang iframe, saya ingin menunjukkan beberapa masalah aksesibilitas. Pertama, meskipun pengguna yang mengalami situs secara visual akan mengalami frameset dan iframe sebagai satu kesatuan yang kohesif bersama dengan halaman lainnya, namun pengguna pembaca layar tidak. Pengguna pembaca layar mengalami setiap frame dalam sebuah frameset, dan setiap iframe, sebagai bagian yang berbeda, terpisah dari halaman lainnya, karena halaman web dialami secara linier. Beberapa pembaca layar, (terutama Jaws untuk Windows, yang merupakan salah satu dengan pangsa pasar terbesar menurut survei penggunaan pembaca layar tahunan WEBAIM), memiliki pengaturan konfigurasi untuk mengabaikan bingkai, termasuk yang sebaris, karena dapat sangat mengganggu beberapa layar pengguna pembaca. Ketika pengaturan abaikan frame dipanggil, konten dalam frame dan iframe menghilang. Bahkan jika Gutenberg mengikuti setiap praktik terbaik aksesibilitas dalam hal iframe, meminta pengguna untuk menonaktifkan pengaturan ini demi dapat mengedit konten sepenuhnya juga memaparkan mereka ke setiap contoh iframe dan membingkai praktik terburuk di internet. Satu-satunya alternatif lain bagi pengguna ini adalah meminta mereka membuat profil terpisah hanya untuk menggunakan Gutenberg, yang bukan merupakan proses yang sederhana, karena itu berarti mereka perlu mengonfigurasi setiap pengaturan browser dan pengaturan ucapan lagi. Ini juga berarti mereka harus mengikuti setidaknya dua profil browser yang terpisah. Saya akan menjadi orang pertama yang memberi tahu Jaws untuk pengguna Windows untuk bermigrasi ke NVDA penuh waktu karena alasan. Gutenberg menggunakan iframe untuk dukungan metabox bukanlah salah satu alasan tersebut.

.. kesabaran saya sebagai pengembang sederhana yang menghabiskan waktu sepanjang tahun untuk memikirkan cara terbaik untuk WordPress secara keseluruhan (inti dan komunitas) mendekati batas.

Aku bersumpah aku benci bersikap kasar tetapi kamu mungkin perlu bersikap lebih tebal dalam kasus itu. Anda frustrasi dengan tanggapan dalam menghadapi "satu tahun penuh" yang telah Anda habiskan untuk memikirkan hal ini, dan terima kasih telah melakukannya, tetapi ini adalah keputusan yang akan memengaruhi pekerjaan bertahun -

Dalam kasus saya, dari apa yang saya baca, hampir setiap situs web yang saya buat selama 3 tahun terakhir dapat langsung rusak. Saya tidak lagi bertanggung jawab atas situs ini, tetapi apa yang akan terjadi di biro iklan tempat saya dulu bekerja ketika lusinan klien menelepon sekaligus dengan situs rusak. Bagaimana hal itu akan berdampak pada agen kecil itu, pekerjaan mereka sehari-hari, keuntungan mereka? Bagaimana pengaruhnya terhadap klien mereka? Itu adalah kekhawatiran saya dan saya hanyalah salah satu pengembang kecil (secara kiasan) di ekosistem yang relatif besar ini.

Saya akui bahwa terkadang kami (setidaknya saya) dapat meremehkan komentar saya dan saya minta maaf untuk ini.

Orang-orang khawatir, dan menjadi frustrasi dan menurut saya mereka memiliki hak untuk melakukannya karena persepsinya adalah bahwa tim yang bekerja di Gutenberg memiliki sedikit pemahaman tentang bagaimana kotak meta digunakan, sedikit perhatian tentang apa dampaknya, dan akan terus maju dengan visi mereka apa pun yang terjadi.

Itu membuat saya sedih untuk menulis ini tetapi saya tidak akan dalam jutaan tahun menyarankan siapa pun memulai proyek besar dengan WordPress sekarang.

2- Gutenberg hanya menggantikan area konten: 90% dari plugin berfungsi, UX menderita

@youknowriad , bagaimana Anda bisa mengatakan UX tidak menderita dengan Gutenberg versus TinyMCE? Saya benar-benar menanyakan pertanyaan itu, bukan membentak. Saya dapat memberi tahu Anda bahwa UX memang sangat menderita di Gutenberg dibandingkan dengan TinyMCE dan kotak meta. Saya akan mendorong Anda untuk menemukannya sendiri dengan:

(1) Cabut mouse Anda.
(2) Jika Anda menggunakan Mack, tekan perintah + f5, dan coba lakukan sesuatu yang produktif menggunakan VoiceOver.
(3) Jika Anda menggunakan PC, unduh NVDA, instal, cabut mouse Anda, dan lakukan pengujian yang sama. Cobalah melakukan sesuatu yang produktif dengan Gutenberg dalam situasi seperti itu.

Saya pikir Anda akan menemukan bahwa UX adalah mimpi buruk mutlak pada saat ini. Itu tidak berarti bahwa itu tidak bisa berubah menjadi lebih baik. Gutenberg memberikan kesempatan bagi WordPress untuk membersihkan banyak hutang teknis terkait dengan aksesibilitas, dan jika ini dilakukan dengan hati-hati dan benar, maka beberapa pencapaian besar dapat diperoleh. Tetapi jika ini dilakukan secara tidak benar atau sembarangan, banyak pekerjaan yang telah dilakukan oleh Tim Aksesibilitas WordPress dan kontributor inti lainnya sejak 2012 harus dimulai lagi. Saya ingin melihat WordPress sebagai sebuah proyek yang tidak membuat kesalahan yang sama seperti yang dimulai dengan: Tidak mempertimbangkan aksesibilitas web sejak awal, yang berarti bahwa tim aksesibilitas dan kontributor terkait lainnya telah menemukan diri mereka mengejar aksesibilitas setelah fakta, yang merupakan tugas yang tidak akan pernah bisa diikuti, karena WordPress bukanlah basis kode yang stagnan.

Saya mengerti bahwa kalian telah bekerja di Gutenberg selama setahun. Saya juga mengerti bahwa mengerjakan ini sulit dan dengan sendirinya, dan umpan balik negatif tidak membantu situasi itu. Akhirnya, saya mengerti bahwa tampaknya orang-orang di antara kita yang bersikap kritis seperti kita mungkin tampak menyebut bayi Anda jelek, atau hanya bereaksi terhadap ketakutan akan perubahan, dan sebagai pencipta, itu paling membuat frustrasi dan menyakitkan paling buruk. . Tapi berbicara sendiri, bayinya tidak jelek. Ada banyak potensi yang belum disadari untuk menjadi anak paling keren di blok, atau si brengsek kecil yang membuat hidup semua orang sengsara. Saya ingin melihatnya menjadi yang pertama dan bukan yang terakhir. Berkenaan dengan kotak meta secara khusus, mereka adalah pokok literal dari pengembangan kustom WordPress, mungkin lebih dari itu shortcode atau tombol TinyMCE. Mereka tidak boleh diabaikan begitu saja, atau dimasukkan ke dalam iframe sampai kita dapat menemukan cara untuk menyingkirkannya.

Kisah sederhana saya dengan WordPress adalah bahwa WordPress telah menjadi mesin situs web pilihan saya untuk membuat situs web untuk pelanggan perorangan, bisnis kecil, dan perusahaan selama lebih dari satu dekade. Saat itu, ada tiga hal yang menjadikan WordPress alat pilihan:

1. Sumber terbuka. Saya pikir penonton ini bisa setuju betapa kuat dan menguntungkannya ini.
2. Kemudahan penggunaan. WordPress membuatnya sangat mudah bagi non-pengembang untuk membuat dan memperbarui konten. Ini sangat besar di tahun-tahun awal saya membuat situs web untuk individu dan bisnis.
3. Mendefinisikan konten. Jenis posting kustom, taksonomi kustom, dan kotak meta kustom. Ketika segala sesuatu yang mengarah ke ini mencapai singularitas, saya tidak berpikir saya mencapai ketika saya mengatakan ini adalah saat WordPress "dapat dijual" ke komunitas bisnis sebagai lebih dari sekedar perangkat lunak blog. (WordCamp Phoenix 2012 - CMB. Tulisan bagus Justin Tadlock tentang mendefinisikan jenis pos, taksonomi, dan kotak meta.)

Saya akan melangkah lebih jauh dengan mengatakan kotak meta khusus - kemampuan untuk membuat antarmuka admin khusus ini, menciptakan pengalaman pengguna yang luar biasa bagi orang-orang, sangat besar. Hancurkan itu, dan Anda melanggar WordPress .

Ide di balik Gutenberg, membuat pengalaman editor konten lebih hebat, adalah ide bagus. Ini layak dilakukan, tetapi harus dilakukan dengan benar, dengan hati-hati, dan tidak terburu-buru. Saat ini, rasanya sangat terburu-buru, dan belum siap.

@jchristopher mengatakannya dengan sangat baik:

Saya sepenuhnya mendukung tujuan Gutenberg meningkatkan pengalaman pengguna, tetapi menurut saya kami tidak dapat menghindari preseden yang telah diterapkan (disengaja atau tidak) untuk menggunakan kotak meta untuk pengeditan konten. Saya pikir pendekatan Yoast sangat bagus, itu adalah sesuatu yang mencentang sejumlah kotak centang untuk berbagai macam solusi potensial untuk masalah ini.

@jnicol dan @aurooba membuat poin bagus dan mengajukan pertanyaan bagus. Mengapa itu tampak seperti itu semua atau tidak sama sekali dan bukan lebih seperti peta jalan yang berulang? Alternatif Yoast jauh lebih masuk akal daripada apa yang pernah dilihat dan saya pikir "eksperimen iframe" membuktikan hal itu. Terima kasih, @amandarush , atas masalah aksesibilitasnya. Saya menantang semua orang untuk mencoba bekerja dengan Gutenberg seperti yang dia uraikan. Ini mungkin mengubah beberapa perspektif.

@aaronjorbin mengatakannya sebelumnya, ketika seseorang mengadopsi WordPress, mereka tidak mengadopsi WordPress (nomor versi-di sini), mereka mengadopsi WordPress secara keseluruhan.

Ada versi lain dari itu, yang mungkin sering didengar oleh siapa pun di layanan klien. Ketika seseorang datang kepada Anda dan mengatakan bahwa mereka membutuhkan situs web baru (kami tidak berbicara tentang blog), mereka biasanya tidak berkata, “Saya perlu situs web Wordpress baru”, atau "Saya ingin situs Drupal baru", dll. Mereka hanya menginginkan situs baru, yang berfungsi, dan berfungsi dengan baik.

WordPress telah menjadi solusi terbaik untuk jutaan situs web: kemudahan penggunaan dan sumber terbuka menjadi kuncinya. Memecah kotak meta khusus (lupakan nomor plugin, bagaimana dengan semua situs web yang ada dengan UI admin khusus?) Dengan implementasi yang terburu-buru dari antarmuka editor baru merusak kemudahan penggunaan itu.

kesabaran saya sebagai pengembang sederhana yang menghabiskan waktu sepanjang tahun untuk memikirkan cara terbaik ke depan untuk WordPress secara keseluruhan (inti dan komunitas) mendekati batas.

Saya akan terus terang, di sini:

Ini dan beberapa komentar lain seperti ini membuat saya berpikir bahwa beberapa dari Anda harus menjauh dari peran pengambilan keputusan dalam proyek ini. Jika Anda tidak dapat mengambil umpan balik yang jujur, dipikirkan dengan matang, tetapi kritis tentang suatu produk, maka sejujurnya, Anda tidak boleh mengambil peran pengambilan keputusan di tim produk. Saya telah berada di posisi Anda beberapa kali, biasanya dalam pertemuan tatap muka dan dalam kasus-kasus yang berhasil, semua orang di ruangan itu menyadari bahwa tidak peduli seberapa memanasnya perdebatan tersebut, yang terpenting adalah memberikan produk terbaik yang kami bisa untuk pelanggan. Menerima kritik tentang ide dan arahan produk adalah bagian dari menjadi pembuat keputusan di tim produk dan harus mengarah pada produk yang lebih baik karena tidak ada yang mungkin memikirkan cara terbaik untuk melakukan segalanya. Itu juga berlaku untuk tim.

Saya yakin semua orang di tim inti ingin memberikan revisi WordPress yang luar biasa, tetapi Anda pasti mendekati sebuah proyek; Anda tahu apa yang diperdebatkan, dipertimbangkan, ditolak, dll. Dan sulit untuk menarik dan melihat sesuatu dari perspektif luar. Tapi Anda bukanlah totalitas komunitas WP; kamu tidak bisa. Apa yang Anda dengar adalah kekhawatiran yang valid tentang arahan produk. Jika Anda tidak dapat menerima itu, pikirkan tentang apa yang dikatakan dan mengapa itu dikatakan, silakan, menjauhlah dari membuat keputusan tentang arah Gutenberg.

Atau (dan ini akan menjadi JAUH lebih baik), LAKUKAN pikiran-pikiran ini. Pertimbangkan benar-benar apa yang dikatakan orang. Pahami kekhawatiran kami sebagai orang yang menjalankan bisnis yang menggunakan WordPress dan memahami bahwa kami peduli tidak hanya untuk diri kami sendiri, tetapi juga untuk klien kami.

Saya telah menggunakan WP sejak awal 2008, dan saya tidak dapat memikirkan fitur atau keputusan baru yang telah menciptakan banyak divisi selama itu seperti pengenalan Gutenberg, dalam bentuknya saat ini.

Meskipun WordPress ditujukan untuk pengguna, itu hanyalah alat, dan pengguna tidak akan dapat menggunakan alat itu jika mereka tidak memiliki profesional WP untuk membantu mereka mencapai tujuan mereka.

Saya melihat referensi yang ingin melayani pengguna yang baru menginstal (apa? ~ 1% dari peningkatan web per tahun?), Tetapi itu tampaknya dengan mengorbankan basis pengguna yang ada (~ 28%), sebagian besar kemungkinan akan menjalankan plugin yang memiliki setidaknya satu kotak meta. Sepertinya naluri bisnis yang buruk dalam skala apa pun.

Saya mendapatkan ideologi: buat editor kasus terbaik, lalu gunakan pola adaptor untuk menjadi yang lama berbicara dengan yang baru. Masalahnya adalah, PHP dan JS adalah teknologi yang berbeda, dan meneruskan masalah itu ke dunia iframe HTML tidak dapat dilakukan, karena semua alasan yang diberikan sebelumnya.

Itu adalah operan pertama, ini adalah percobaan, tetapi upaya ini tidak berhasil. Semakin cepat diketahui, semakin cepat kita dapat beralih ke saran berikutnya.

Tidak ada yang datang dengan solusi yang cocok dalam hal kotak meta yang memuaskan semua pihak.

Itu berarti satu pihak perlu mengalah - dan apakah itu 10-50 pengembang pro-Gutenberg, atau ratusan / ribuan pengembang yang _scared_ atau dampak perubahan terhadap mereka, apalagi penggunanya, kita akan lihat.

Setelah semua saran solusi habis, mungkin akan ada konsesi bahwa menimpa seluruh halaman tidak mungkin dilakukan oleh semua pihak. Setidaknya tidak dalam satu klik yang saat ini sedang dicoba.

Untuk kembali ke pertanyaan awal - apakah iframe adalah solusi jangka panjang untuk kotak meta? Beberapa pengembang (dan jangan lupa, mereka juga Pengguna) telah menjelaskan mengapa jawabannya tidak.

Kami telah melakukan diskusi yang sangat konstruktif di sini. Ingat:

Kami mengkritik ide, kode, dan piksel, bukan manusia di belakangnya. Kami mungkin memiliki pendapat berbeda tentang jalan terbaik ke depan, tetapi kami tidak mempertanyakan kredensial. Ketika kita berbicara kepada individu, itu untuk mengangkat mereka dan memberi mereka pujian untuk pekerjaan yang dilakukan dengan baik. Dengan begitu banyak hal yang terjadi di dunia ini, kita harus saling menjaga. Ini adalah tantangan yang monumental, tetapi kita akan sampai di sana bersama.

Izinkan saya mengingatkan semua orang bahwa metabox di Gutenberg adalah hasil dari @ BE-Webdesign yang meningkatkan dan menyelesaikan ini, terlepas dari semua orang dengan sedikit bantuan, muncul entah dari mana. Jika bukan karena @ BE-Webdesign, tidak akan ada metabox di Gutenberg. Dari 47 komentar yang tersisa di sini, mungkin hanya 2 orang yang benar-benar menyentuh kode metabox untuk keperluan review dan UX.

Masalah mendasar di sini adalah bagaimana cara mendapatkan metabox dengan aman di halaman sebagai warga kelas satu tanpa membangun kode yang tidak aman, yang mengarah ke pertukaran hacky kludges atau memiliki gotchas.

• Iterasi pertama melibatkan gotcha, membuat WP berpura-pura berada di halaman edit.php , dan menghasilkan metabox seperti itu. Laporan awal menunjukkan itu memiliki masalah kompatibilitas dan sangat hacky, dan bukan solusi yang layak. Ini karena banyak plugin hanya mendaftarkan metabox jika keadaan tertentu terpenuhi dan tidak mempercayai WP untuk mengetahui kapan harus merendernya
• Iterasi kedua yang digabungkan menggunakan iframe, sehingga metabox ditampilkan di editor klasik, meskipun semuanya kecuali metabox dihapus. Ini agak rumit tetapi membuat metabox berfungsi, meskipun dengan masalah
• Ada juga solusi di mana kami mengambil kode HTML dan kemudian memasukkannya secara grosir ke dalam sebuah komponen, yang akan menjadi bencana keamanan, meskipun merupakan solusi yang sangat jelas. Oleh karena itu mengapa belum dilakukan seperti ini.

Saran saya, adalah:

alih-alih memuat Gutenberg di halaman setelan, mari muat ke halaman editor klasik utama, muat metabox di lingkungan aslinya, lalu angkat node DOM penampungnya ke dalam komponen melalui JS

Kami kemudian menggunakan jenis sakelar yang berbeda untuk memastikan editor klasik masih dapat digunakan. Cara ini:

• kami menghindari omong kosong iframe
• metabox bekerja seperti yang selalu mereka lakukan sejauh menyangkut pendaftaran
• JS yang ada berfungsi seperti yang diharapkan, dan tidak ada peretasan yang diperlukan untuk membuat semuanya berfungsi pada akhir PHP

Juga, desain yoast cantik, tapi kemana perginya meta blok?

Sayangnya, saya memiliki sedikit pengalaman dengan js pada level yang diperlukan untuk menyumbangkan kode sebenarnya ke Gutenberg. Saya baru mulai terjun ke dunia pengembangan WordPress daripada mengembangkannya di atasnya. Jadi yang terbaik yang bisa saya lakukan adalah memberikan tanggapan saya, menguji editor (saya aktif menggunakan Gutenberg di blog pribadi saya), dan memberikan saran / pemikiran. Jika saya _bisa_ menyumbangkan kode, saya pasti akan melakukannya. Jika ada cara lain yang bisa saya bantu, saya ingin tahu. Karena saya sangat peduli tentang ini. :)

Berkontribusi datang dalam berbagai bentuk. Sementara waktu dan upaya yang dikerahkan untuk mengembangkan upaya ini dihargai, pengujian dan diskusi yang mencegah biaya hangus di masa depan bisa sama berharganya. Misalnya, ada sejumlah masalah yang baru dibuka terkait dengan implementasi iframe. Kami dapat menghabiskan lebih banyak waktu untuk mencoba memperbaiki masalah tersebut, atau kami dapat menggunakan pengujian dan alasan di utas ini untuk menentukan arah yang berbeda diperlukan. Saya harap itulah realisasi bahwa kami telah tiba sebagai sebuah grup.

Izinkan saya mengingatkan semua orang bahwa metabox di Gutenberg adalah hasil dari @ BE-Webdesign yang meningkatkan dan menyelesaikan ini, terlepas dari semua orang dengan sedikit bantuan, muncul entah dari mana. Jika bukan karena @ BE-Webdesign, tidak akan ada metabox di Gutenberg.

Meskipun pujian dan pemujaannya bagus 😄, saya pasti mendapat bantuan, dan ini sebagian besar merupakan upaya tim dari banyak orang.

Saran saya, adalah:

alih-alih memuat Gutenberg di laman setelan, mari muat Gutenberg ke laman editor klasik utama, muat> metabox di lingkungan asalnya, lalu angkat simpul DOM penampung mereka ke dalam komponen melalui JS

Ya, ini kemungkinan besar adalah pengulangan berikutnya, dan menurut saya ini adalah saran yang bagus serta ide yang konstruktif. Belum 100% yakin bagaimana melakukan ini dengan rapi, tetapi sangat mungkin untuk tidak menggunakan iframe, dan memiliki peningkatan UX yang sama dengan yang sudah disediakan Gutenberg. Akan ada pembaruan yang akan datang untuk meningkatkan pengalaman kotak meta, yang kemungkinan akan melibatkan penghapusan iframe. Metode iframe telah berfungsi sebagai cara untuk melihat bagaimana dukungan meta box dapat diimplementasikan, sekarang perbaikan yang lebih baik akan dilakukan. Ketika hal-hal pertama kali dieksplorasi dengan kotak meta beberapa bulan yang lalu (bukan topik baru), masuk akal untuk bergerak maju dengan pendekatan iframe, karena keadaan Gutenberg saat itu, sekarang digabungkan dan banyak bagian lainnya telah dipindahkan sekitar, penggunaan iframe mungkin tidak lagi diperlukan, dari sudut pandang teknis. Lebih banyak pekerjaan perlu dilakukan.

@ BE-Webdesign Terima kasih atas upaya dan masukan Anda di sini. Mari kita tutup ini dan mulai masalah baru ketika pendekatan itu siap untuk didiskusikan.

Tolong Berhenti dan Evaluasi Ulang Sekarang, Bukan Nanti

Tidak semua orang terbiasa dengan pendekatan desain proyek ini, tetapi ini adalah proyek yang mengikuti evaluasi ulang harian terus menerus dari hampir semua hal. Bandingkan mock up asli dengan editor saat ini. Banyak hal berubah. Kebanyakan potongan tidak diatur di atas batu. Satu-satunya cara untuk benar-benar mengevaluasi apakah sesuatu akan berhasil adalah dengan benar-benar melakukannya. Tidak semua orang mendekati desain produk dengan cara yang sama, tetapi saya pikir iterasi yang cepat dari Gutenberg telah menyajikannya dengan baik, daripada mencoba mencari tahu hal-hal yang tidak diketahui sebelumnya.

Terima kasih semuanya untuk diskusi. Saya senang percakapan difokuskan kembali pada akhirnya ke masalah topik: _ apakah pendekatan saat ini ke meta-box dalam iframe viable_? Dengan jawaban tidak. Iframe adalah detail implementasi yang menurut saya bisa kita jatuhkan dengan relatif mudah. Jadi mari kita fokus pada itu.

Saya ingin menambahkan, sebagai beberapa pemikiran penutup, bahwa tidak mengubah apa pun tentang layar edit akan menjadi cara paling sederhana untuk kita lakukan. Itu juga tidak adil untuk tujuan proyek dan pengguna WordPress jangka panjang. Apa yang oleh sebagian orang disebut sebagai pendekatan pragmatis tidak sejalan dengan arah desain yang dimiliki proyek ini sejak awal - menuju penyesuaian situs penuh - dan apa yang telah menentukan keputusan kami sejauh ini. Tidak ada di sini yang harus menjadi solusi akhir, kami sedang mengeksplorasi apa yang mungkin dilakukan di dalam tempat desain dan meletakkannya di sana untuk pengujian. Ini tidak dapat kita bangun sendiri dan dengan tulus kami menyambut semua bantuan yang dapat kami peroleh dari Anda semua, karena ada beberapa masalah sulit yang terkubur di jalan untuk diatasi.

WordPress selalu bergerak bersama pengguna, dan kami mengambil beban untuk mencari tahu jalur pengembangan untuk memudahkan transisi untuk kode kami yang sudah ada. Sebagai sebuah proyek, kami telah mengatakan sebelumnya bahwa kami tidak melepaskan dukungan untuk meta-box dari WordPress, tetapi juga bahwa kami harus menjelajahi keputusan antarmuka apa yang harus kami buat dalam paradigma baru, termasuk kemungkinan memuat editor klasik saat kami mendeteksi meta-box yang tidak dapat kami tangani atau yang secara langsung bertentangan dengan editor yang berupaya untuk menggambarkan dengan lebih jelas apa itu konten dan apa itu meta-data. Ada orang di luar sana yang bisa mendapatkan keuntungan dari pengalaman Gutenberg default sekarang. Sebagai pengembang, kami memiliki hak istimewa untuk dapat membuat solusi, tetapi juga bertanggung jawab untuk tidak mengabaikan perubahan yang harus kami buat untuk memungkinkan orang-orang, yang jika tidak akan kesulitan, untuk hadir di web terbuka.

@mtias Saya sangat menghargai komentar Anda yang masuk akal, terutama bagian tentang "WordPress selalu bergerak bersama pengguna".

Sayangnya itu benar-benar bertentangan dengan apa yang telah dikomunikasikan @youknowriad di utas ini, dan karena Anda berdua bekerja di Automattic, saya mendorong Anda untuk berbicara dengannya tentang arahan produk, karena saat ini kami mendapatkan sinyal yang beragam.

Sayangnya, Anda tidak membahas sketsa Yoast yang diusulkan yang akan memberi kita semua fleksibilitas Gutenberg sekaligus kompatibel dengan metabox yang ada. Mengapa seseorang tidak dapat mengetahui mengapa Anda tidak mempertimbangkan pendekatan ini?

Sayangnya, hal itu sangat bertentangan dengan apa yang dikomunikasikan @youknowriad di utas ini

Saya pikir Anda hanya salah paham dengan apa yang saya katakan, saya hanya menyebutkan fakta dan saya membagikan pemikiran @mtias 100%

@tokopedia

Apa yang oleh sebagian orang disebut sebagai pendekatan pragmatis tidak sejalan dengan arah desain yang dimiliki proyek ini sejak awal - menuju kustomisasi situs penuh

Saya sangat tidak setuju dengan pandangan ini. Membuat peningkatan berulang yang dibatasi untuk editor itu sendiri, tetapi memiliki kekuatan untuk menggantikan metabox, serta merilis dan mempromosikan API bidang akan menjadi cara yang mulus untuk mentransisikan massa plugin ke paradigma blok, hanya dengan kemudahan penggunaan , dibandingkan dengan lanskap retak yang kita miliki sekarang.

Dengan membuat transisi perantara itu dengan lancar, Anda akan membuatnya lebih mudah untuk menghentikan pembuatan / manipulasi DOM langsung pada layar post_edit, karena pada saat itu, solusi standar dalam praktik tidak lagi melibatkan manipulasi semacam itu. Saya tidak percaya ada orang yang mengatakan "manipulasi DOM langsung harus menjadi pengalaman utama selamanya". Mereka berkata "Ini adalah solusi utama sekarang".

jika Anda dapat mempertahankan fleksibilitas penuh manipulasi dom dengan solusi layar penuh, lakukanlah ... tetapi tampaknya itu adalah tujuan yang sangat mulia, dan saya ragu segala bentuk pengangkatan dari layar edit klasik benar-benar dapat memberikan hasil pada tingkat kompatibilitas yang wajar. Mungkin saya salah, tetapi tampaknya seperti peretasan yang sangat rumit untuk mencoba mentransisikan pengguna, ketika pendekatan yang lebih berulang dapat melakukan pekerjaan yang sama.

Dengan mempertahankan keunggulan paradigma saat ini, sambil merilis yang baru, Anda mendorong adopsi tanpa melukai pengalaman siapa pun saat ini. Kemudian, setelah sebagian besar alur kerja dialihkan ke paradigma blok, kontrol dom langsung dapat dihentikan untuk mendukung solusi layar penuh.

Ini tidak mengkhianati tujuan proyek, hanya menangani jadwal rilis untuk membuat perubahan lebih mudah dikelola untuk ribuan agensi dan pengembang.

@youknowriad Izinkan saya memposting beberapa cuplikan dari apa yang telah Anda tulis untuk mendukung apa yang saya katakan:

dengan memanfaatkan REST API, UI sisi klien dan menyatukan Konsep Inti: Widget, Shortcode, Blok, Metabox Konten di bawah konsep unik "A Block"

Tidak ada yang meminta "Metabox konten" untuk diubah menjadi blok, dan itu tidak dikomunikasikan sampai Gutenberg mengirimkan versi awalnya. Sebenarnya, inilah inti dari argumen tersebut. Saya tidak akan mengulangi apa yang orang lain katakan dengan lebih baik, hanya saja metabox seringkali bukan konten halaman.

Tidak seperti apa yang Anda baca di sana-sini, fokusnya selalu tentang mendesain ulang seluruh halaman, Maket pertama untuk Halaman Editor Gutenberg telah diperlihatkan di pertemuan Gutenberg mingguan kedua atau ketiga. Kami masih dalam tahap pembuatan prototipe.

Tim Gutenberg terus mengatakan sketsa itu hanya untuk pertunjukan dan bukan desain akhir. Selain itu, sketsa tidak dapat menunjukkan apakah seluruh layar edit telah diubah menjadi React atau hanya ditata secara berbeda. Fakta bahwa seluruh halaman akan didesain ulang menjadi kejutan besar bagi semua orang yang telah saya ajak bicara.

Apa perbedaan antara Shortcode, TinyMCE Buttons dan Metaboxes?
Perbedaan utamanya adalah bahwa "Metabox" tidak memiliki "tujuan", itu hanya cara untuk memperluas halaman editor tanpa konsistensi sementara tombol Shortcode dan TinyMCE memiliki satu.

Ini adalah kesalahpahaman raksasa yang harus menaikkan alis dalam Automattic. (Dan saya berharap @mtias dan @m mendengarkan). Itu tidak benar dan saya benar-benar mempertanyakan penilaian Anda setelah pernyataan ini.

Bisakah kita menyimpulkan bahwa untuk jangka panjang WordPress, Metabox mengunci evolusinya (terlepas dari Gutenberg)?
Ya begitulah.

Saya akan mengatakan hampir tidak ada yang setuju dengan Anda di sini, dan saya pikir Automattic perlu memberikan suara untuk menentukan arah produk.

Saya juga mempertanyakan @mtias yang mengatakan hal-hal seperti orang yang perlu berkontribusi. Jelas bahwa tim Gutenberg yang terkait dengan Automattic tidak bergeming sedikit pun dan menangkis semua kritik.

Saya benar-benar tidak yakin bahwa jika saya membuat PR untuk mengurangi Gutenberg menjadi hanya komponen edit, itu akan dipertimbangkan oleh tim Gutenberg, karena pernyataan yang dibuat oleh beberapa individu di Automattic.

@bayu_joo

Saya ingin menambahkan, sebagai beberapa pemikiran penutup, bahwa tidak mengubah apa pun tentang layar edit akan menjadi cara paling sederhana untuk kita lakukan. Itu juga tidak adil untuk tujuan proyek dan pengguna WordPress jangka panjang.

Melangkah selangkah demi selangkah tidak , dengan cara apa pun, membahayakan tujuan proyek. Anda masih dapat menuju ke penyesuaian ukuran penuh jika itu tujuannya, tetapi dengan melakukannya secara bertahap, Anda akan membawa serta komunitas pengembang lainnya.

Customizer adalah contoh utama dari ini. Ya, memang ada kritiknya, tetapi konsep akhirnya akan terwujud seiring waktu, menjadi fitur yang memungkinkan kelompok pengguna tertentu memanfaatkan WP secara efisien sebagai alat untuk mengelola situs mereka.

Ada orang di luar sana yang bisa mendapatkan keuntungan dari pengalaman Gutenberg default sekarang.

Benar. Tetapi ada juga jumlah yang jauh lebih besar yang akan memiliki pengalaman merugikan dengan Gutenberg default sekarang.

Saya berharap kita semua dapat melanjutkan dengan rasa hormat dan memisahkan orang-orang dari produk dalam tanggapan kita. Gairah itu hebat, tetapi penting bagi kita untuk memikirkan manusia yang berinteraksi dengan kita dalam utas seperti ini. Setiap orang yang terlibat dalam proyek ini peduli, mereka tidak akan masuk ke utas ini dan berinteraksi jika tidak. Sekarang, mari kita tarik napas dan semua ingat betapa kita semua sangat peduli tentang WordPress dan ingin menjadi inti dari komentar kita menjaga komunitas ini tetap aman, produktif untuk semua orang.

@khromov , sebagai pimpinan desain proyek ini, sama seperti Matias yang memimpin bagian teknis, saya berdiri 100% di belakang @youknowriad. Saya mengerti Anda penuh gairah, tetapi Anda tidak menghormati. Harap sesuaikan pendekatan yang Anda lakukan dengan memanggil satu orang. Mari berhenti menjadi pribadi.

Penting juga untuk diingat bahwa banyak dari mereka yang bekerja di Gutenberg adalah anggota komunitas WordPress sebelumnya, yang (masih) kontributor inti sebelumnya. Ya, itu termasuk saya sendiri. Saya akan berbicara sangat pribadi di sini, setelah Anda melakukan PR, beri tahu saya dan saya akan memeriksanya dan memastikan semua ulasan memiliki rasa hormat yang sama, tidak peduli dari mana asalnya. Tolong, mari kita beralih dari melihat proyek ini sebagai proyek 'us v them'. Tidak dan kami memiliki beberapa kontributor non Automattic yang luar biasa di sini, pernyataan itu membuat mereka tidak memberikan layanan.

@tokopedia

Saya umumnya dipandang sebagai pencela Gutenberg, karena posting dan komentar saya menyoroti masalah yang saya lihat dengan pendekatan dan implementasi, tetapi saya merasa bahwa tujuan dan kemajuan Gutenberg terkadang disalahartikan dalam komentar, karena miskomunikasi atau kurangnya pemahaman tentang tujuan proyek yang menyeluruh.

Pemblokiran bukanlah cara visual untuk merepresentasikan dan mengedit konten posting, blok juga tidak harus menjadi bagian dari menu pemilih konten, atau drag / droppable. Mereka dapat digunakan untuk hal-hal itu, tentu saja, dan itulah alur kerja yang disorot oleh sebagian besar bagian yang terlihat di Gutenberg. Namun, abaikan sejenak apa yang Anda ketahui tentang paradigma itu, dan lihatlah seperti ini:

Pemblokiran dimaksudkan sebagai struktur kontrol fundamental untuk situs, terlepas dari antarmuka atau penyimpanannya.

• Widget dijadwalkan menjadi blok. Itu TIDAK berarti bahwa mereka akan ada di editor dan disimpan di post_content. Ini berarti bahwa mereka akan dikontrol dengan sistem yang dibangun dalam kerangka JavaScript, dengan API tunggal yang umum.
• Penyesuai direncanakan untuk diganti dengan blok. Antarmuka mungkin akan tetap (kurang lebih) sama, tetapi bagian Penyesuai akan dikontrol oleh API yang sama.
• Halaman plugin, editor tema, dasbor itu sendiri, semuanya dijadwalkan untuk menjadi blok. Jika gagasan bagian ini, persis seperti apa adanya, tidak mungkin dibayangkan dibuat ulang dengan API umum, maka Anda mungkin memiliki beberapa kesalahpahaman terkait dengan apa itu blok, dalam bahasa WordPress.

Masalahnya bukanlah bahwa metabox tidak dapat dibuat ulang di dalam paradigma blok, pada kenyataannya, blok non-front-end yang ditambahkan secara terprogram ke jenis posting, dikunci di tempatnya, dan disimpan ke post-meta alih-alih post_content dijadwalkan untuk rilis WordPress 5.0 (perbaiki saya jika saya salah).

Intinya, itu mencakup semua kebutuhan bidang meta sepele seperti kotak teks dan seleksi. Anda dapat dengan tepat menduplikasi antarmuka itu dalam blok, jika Anda mau, atau Anda mungkin dapat merampingkannya, berdasarkan bahasa visual baru yang memblokir pasokan ... yang akan sepenuhnya menjadi panggilan Anda.

Masalahnya bukanlah bahwa metabox tidak pernah bisa diblokir. Masalahnya adalah saat ini, ada antarmuka yang dibuat di metabox, yang belum didukung di blok (baik oleh WordPress atau pihak ketiga), dan menerapkan ulang pekerjaan itu adalah tugas yang sangat berat bagi pengembang, terutama karena alat ini tidak dibuat. dari API umum seperti Fields API yang diusulkan, tetapi dengan cara hodge-podge yang secara langsung mengubah DOM halaman, dan mengantrekan sumber daya dengan cara ad-hoc dan tidak terkelola.

Keadaan saat ini juga menyebabkan masalah bagi pengembang. Misalnya, jika Anda menggunakan Visual Composer, bersama dengan Piklist untuk bidang, Piklist akan menimpa banyak gaya admin Anda, membuat VC sangat sulit dinavigasi.

Atau jika Anda menggunakan WooCommerce bersama dengan plugin apa pun yang mengantrekan versi baru Perpustakaan Select2, salah satu atau lainnya akan merusak antarmuka admin Anda, dengan kesalahan JS kritis.

Hal yang sama dapat terjadi jika dua plugin berbeda mengandalkan versi kerangka kerja CMB2 yang berbeda.

Blocks bermaksud untuk menyelesaikan masalah ini dengan memperkenalkan kerangka kerja umum di sekitar berbagai penambahan halaman. Beberapa dari kerangka kerja ini akan difokuskan pada penawaran barang visual drag and drop wiz-bang ke editor, tetapi sebagian besar sebenarnya tidak terikat dengan itu. Ini hanya memastikan bahwa hal-hal yang muncul di admin dikelola dengan cara yang sama.

Sekarang, ada argumen yang valid bahwa WordPress telah berkembang dengan sikap pengembang Wild West, dan kerangka umum ini meningkatkan penghalang masuk bagi pengembang yang tidak tahu bereaksi. Dan ada argumen yang valid bahwa antarmuka Block tidak akan mencapai adopsi dev yang tersebar luas sebelum rilis. Bahkan ada argumen yang valid bahwa API blok saat ini agak naif, dan tidak memperhitungkan banyak alur kerja umum, sehingga mustahil untuk mengadaptasi plugin sampai kapabilitas tersebut dibuat dan didokumentasikan.

Tetapi berpendapat bahwa Metabox gratis untuk semua, sebagaimana adanya, adalah solusi akhir segalanya, dan harus dipertahankan untuk selamanya tidak menawarkan jalan yang bagus ke depan bagi siapa pun. Agar WordPress dapat menawarkan opsi yang lebih baik untuk semua pengguna, termasuk pengembang, beberapa jenis sistem umum perlu ada.

Alangkah baiknya jika sistem ini adalah Fields API yang umum, bertahun-tahun yang lalu, sehingga semua perubahan ini sebagian besar hanya akan menjadi pengganti langkah rendering untuk API tersebut, tetapi sebagaimana adanya, jalur ke depan perlu ditemukan.

Semua yang dikatakan, saya masih sangat mendukung solusi sementara yang diusulkan Yoast, sebagai cara terbaik dunia nyata untuk bergerak menuju UI bersama yang akhirnya. Saya tetap kritis, tentu saja, tetapi saya ingin memastikan bahwa kami kritis terhadap fakta, dan bukan kesalahpahaman.

Sayangnya itu benar-benar bertentangan dengan apa yang telah dikomunikasikan @youknowriad di utas ini, dan karena Anda berdua bekerja di Automattic, saya mendorong Anda untuk berbicara dengannya tentang arahan produk, karena saat ini kami mendapatkan sinyal yang beragam.

Saya akan mengatakan hampir tidak ada yang setuju dengan Anda di sini, dan saya pikir Automattic perlu memberikan suara untuk menentukan arah produk.

Jelas bahwa tim Gutenberg yang terkait dengan Automattic tidak bergeming sedikit pun dan menangkis semua kritik.

Saya benar-benar tidak yakin bahwa jika saya membuat PR untuk mengurangi Gutenberg menjadi hanya komponen edit, itu akan dipertimbangkan oleh tim Gutenberg, karena pernyataan yang dibuat oleh beberapa individu di Automattic.

Saya hanya ingin menyatakan yang sudah jelas, tetapi Gutenberg adalah proyek komunitas WordPress, bukan produk Automattic . Saya sendiri mungkin seorang Automattician, tetapi hal itu tidak memberi saya otoritas lebih pada proyek ini daripada orang lain, apakah mereka seorang freelancer, CEO agensi, atau dev berdedikasi yang memenuhi komitmen 5% perusahaan, tidak seperti yang disarankan beberapa orang. Demikian pula, WordPress sendiri adalah proyek komunitas, bukan proyek Automattic.

Automattic tidak "merilis" atau "membangun" WordPress, dan Gutenberg bukanlah produk Automattic

Selain itu, sebelum percakapan ini menjadi lebih emosional, dan orang-orang melupakan hutan demi pepohonan, saya ingin meluangkan waktu untuk menghargai kesulitan tugas yang telah diberikan tim Gutenberg, dan seberapa baik mereka menanganinya secara umum. Mereka telah ditugaskan untuk membuat paradigma yang akan menjadi dasar untuk pengalaman admin WordPress secara keseluruhan, dalam batasan yang hanya memungkinkan mereka untuk mendemonstrasikan keefektifannya di satu sudut kecil antarmuka.

Jumlah kesalahpahaman yang disebabkan oleh gagasan bahwa "editor mengambil alih" sangat besar, dan pasti sangat sulit untuk dikelola. Bidang mereka adalah membuat blok bangunan umum untuk admin WordPress, dan mengujinya dengan membangun kembali editor. Meskipun saya percaya bahwa tugas ini akan jauh lebih enak dan fleksibel bagi publik jika mereka baru saja membangun kembali antarmuka wp_editor() dan memperluas dari sana, dapat dimengerti mengapa semua komponen yang terhubung dari 'pengalaman edit' membuat uji coba yang lebih lengkap untuk paradigma baru yang diusulkan.

Saya mengerti, dan saya menghargai upaya tahun ini yang telah dilakukan untuk pekerjaan ini. Saya masih kritis terhadap beberapa keputusan yang dibuat, dan percaya ada waktu untuk membuat beberapa modifikasi yang akan sangat meningkatkan adopsi awal, tetapi saya sepenuhnya setuju dengan tujuan menyeluruh pada akhirnya menyediakan kerangka kerja yang lebih terstruktur untuk pengalaman admin WordPress , untuk pengembang dan pengguna.

@tokopedia

Alasan saya menyebutkan @youknowriad adalah karena dia satu-satunya yang terlibat dalam diskusi tersebut. Sebuah diskusi yang melibatkan ratusan developer dan ribuan jam tanpa kemajuan apapun, meski sudah ada konsensus yang jelas dari pihak developer. Saya tidak berpikir itu tidak sopan untuk mempertanyakan legitimasi keputusan yang dibuat ketika dibuat oleh sekelompok kecil pengembang, bahkan jika itu melibatkan memanggil orang-orang tertentu.

Terlepas dari itu, saya melakukan obrolan pribadi dengan @youknowriad dan dia telah menjelaskan kepada saya peta jalan yang akan datang yang menurut saya terdengar lebih masuk akal daripada apa yang dikomunikasikan ke luar.

@tokopedia

Saya dengan hormat tidak setuju. Keputusan penting dibuat oleh ahli otomotif , dan setelah berbicara dengan

@gschoppe Saya hanya berharap "perubahan paradigma" ini didiskusikan secara terbuka dan bekerja sama dengan komunitas pengembang. Mungkin itu niatnya, tapi dalam hal ini sisi komunikasi tidak berfungsi dengan baik.

Mengapa seseorang tidak dapat mengetahui mengapa Anda tidak mempertimbangkan pendekatan ini?

@khromov kami sudah , dan di beberapa tempat lain di obrolan editor, dll. Masalah ini khususnya adalah tentang implementasi iframe.

Saya benar-benar tidak yakin bahwa jika saya membuat PR untuk mengurangi Gutenberg menjadi hanya komponen edit, itu akan dipertimbangkan oleh tim Gutenberg, karena pernyataan yang dibuat oleh beberapa individu di Automattic.

Tidak semuanya. Kami menganggapnya sendiri sejak awal, melihatnya terlalu membatasi dan tidak sesuai untuk mendorong visi yang kami miliki. Ini mungkin masih merupakan kompromi yang masuk akal bagi banyak orang, dan bisa menjadi plugin yang bagus untuk dijelajahi. Pekerjaan yang dibutuhkan untuk mewujudkannya, bagaimanapun, akan meningkatkan Gutenberg secara umum dengan membuatnya lebih dapat digunakan kembali, jadi saya tidak akan menentang orang yang mengerjakannya. Jika seseorang mengerjakan PR seperti itu, saya mungkin akan menyarankan untuk menambahkan pengaturan di bagian Menulis untuk mengaktifkan perilaku alih-alih menjadikannya default.

Kami memiliki fitur signifikan yang muncul di sekitar blok bersarang, blok global, mendeklarasikan templat blok, kolom, dll, yang benar-benar mendapat manfaat dari lembar konten menjadi halaman penuh dan akan terasa agak buruk jika tidak, membatasi apa yang dapat dilakukan pengembang dan apa yang dapat dialami pengguna. Ada juga alat bagus seperti garis besar dokumen yang terintegrasi dengan mulus dan secara real-time di editor layar penuh yang akan dibuat hanya dengan menggantikan TinyMCE.

Melangkah selangkah demi selangkah tidak, dengan cara apa pun, membahayakan tujuan proyek.

Pastinya! Kami telah mengusulkan pendekatan bertahap, dari posting fokus baru asli Matt, itu hanya mempertimbangkan langkah-langkahnya secara berbeda. Biasanya ada tiga tahap untuk proyek Gutenberg: dari editor posting, ke templat halaman, hingga pembangunan situs. Apa yang primordial adalah bahwa paradigma adalah satu di mana konten adalah satu area, dengan _block_ sebagai konsep utama, dan di mana hasilnya dapat secara visual diwakili dengan jelas dan tanpa abstraksi yang berlebihan.

Benar. Tetapi ada juga jumlah yang jauh lebih besar yang akan memiliki pengalaman merugikan dengan Gutenberg default sekarang.

Tentu saja, dan itulah mengapa ada kedua plugin untuk kembali ke pengalaman saat ini sesuka hati, dan kami akan memiliki mekanisme untuk menangani ketidakcocokan, memungkinkan lebih banyak hal untuk diikutsertakan (katakanlah jika Anda merasa nyaman dengan meta-box Anda ditampilkan di Gutenberg Anda dapat menyatakan dukungan untuk itu, atau sebaliknya).

@gschoppe Saya tahu bahwa kita pernah mengalami banyak ketidaksepakatan di masa lalu, tetapi saya menghargai komentar Anda di sini dan kesediaan untuk berpartisipasi bahkan melalui sudut pandang yang berbeda. Anda membuat beberapa poin bagus tentang faktor penggumpalan blok. Mungkin suatu hari nanti kita akan bertemu di konferensi WC dan kita bisa memulai diskusi filosofis yang menyenangkan tentang kapal Theseus paradox. Siapa tahu. 😉

Anda dari Automattic tidak boleh mengeluh bahwa kami tidak menghargai pekerjaan Anda, dan kami terlalu memaksakan diri.
Bukan untuk 7000 - 10.000 € gaji pro bulan Anda dibayar. Bodoh. Tidak seperti ketika orang-orang mengeluh di WP Trac kepada relawan pengembang.
Jika Gutenberg membuat Anda pusing, bicarakan dengan atasan Anda. Dia memberi Anda tugas yang mustahil untuk dilakukan.

Kedua, Anda adalah pembuat kode yang jauh lebih baik daripada mayoritas orang yang berkomentar di sini. Mengapa Anda mencoba melewatkan solusi "Iframes"?
Sudah kubilang, kamu memperlakukan orang seperti anak-anak. Mari kita coba dengan iframe dan lihat apakah orang-orang akan berteriak terlalu banyak, terlalu emosional. Jika ada banyak noise, kami menjauh dari iframe.

Mengapa Anda mencoba melewatkan solusi "Iframes"?
Sudah kubilang, kamu memperlakukan orang seperti anak-anak. Mari kita coba dengan iframe dan lihat apakah orang-orang akan berteriak terlalu banyak, terlalu emosional. Jika ada banyak noise, kami menjauh dari iframe.

Ketika dukungan meta box pertama kali diterapkan, editor baru ada di halaman admin yang sama sekali baru, bukan post.php, editor memuat secara berbeda, dan secara umum ada banyak kendala, sebagian dari menyelesaikan masalah meta box menggunakan iframe, menerangi beberapa kendala tersebut, yang sudah tidak ada lagi, dan akibatnya kotak meta, kemungkinan besar tidak perlu menggunakan iframe lagi.

Proyek ini mendukung peningkatan bertahap di seluruh rilis daripada kesempurnaan dalam satu rilis. Tidak ada yang mencoba untuk melihat apakah orang akan berteriak. Kenyataannya adalah bahwa pendekatan iframe bekerja dengan baik untuk sebagian besar kotak meta, terlepas dari apa yang orang-orang lakukan. Sekarang itu akan ditingkatkan lebih jauh, dan akan ada semakin sedikit 😱 🙀.

@StaggerLeee harap

Saya tidak akan sebagai pimpinan desain untuk proyek ini melihat pernyataan pribadi seperti yang Anda katakan kepada siapa pun. Saya tidak peduli di mana seseorang bekerja atau latar belakangnya, itu adalah detail pribadi yang tidak berhak Anda hubungi. Silakan tinggalkan personal dan kembali fokus pada produk.

Sekarang, mari kita lanjutkan dan fokus untuk membuat produk terbaik yang kita bisa. Saya benar-benar memahami poin Anda sering kali datang dari tempat yang penuh gairah. Anda bisa bersikap hormat dan bersemangat, harap kembali menjadi seperti itu.

Anda dari Automattic tidak boleh mengeluh bahwa kami tidak menghargai pekerjaan Anda, dan kami terlalu memaksakan diri.
Bukan untuk 7000 - 10.000 € gaji pro bulan Anda dibayar. Bodoh. Tidak seperti ketika orang-orang mengeluh di WP Trac kepada relawan pengembang.
Jika Gutenberg membuat Anda pusing, bicarakan dengan atasan Anda. Dia memberi Anda tugas yang mustahil untuk dilakukan.

@StaggerLeee Saya berharap saya mendapatkan banyak petunjuk petunjuk 😂 tetapi Automattic bukan Google, dan saya bisa menghasilkan lebih banyak di tempat lain di dunia WP. Kehadiran saya di sini murni dari punggung saya sendiri, saya tidak dibayar untuk berada di sini, dan tidak banyak orang lain yang mengerjakan ini. Sebenarnya saya dibayar untuk melakukan tinjauan kode dan membantu meluncurkan klien perusahaan!

Jadi percayalah bahwa pesan telah diterima, buktinya ada di tab Permintaan Tarik di bagian atas, ini bukan konspirasi Automattic untuk memecahkan kode Anda dan menghapus klien Anda (_jangan lupa, Automattic telah membayar klien yang gunakan metabox juga_)

Bagi mereka yang masih khawatir dengan iframe , saya sarankan untuk melihat permintaan Pull ini (https://github.com/WordPress/gutenberg/pull/3345) yang mencoba membatalkan iframe dan menerapkan saran saya yang dibuat sebelumnya.

Karena iterasi berikutnya dari implementasi metaboxes, akan lebih baik untuk menguji dan mengidentifikasi masalah kompatibilitas, melemparkan buah busuk ke A8C mungkin terasa baik tetapi itu tidak membantu.