FWIW ketika saya berbicara dengan pengembang web mereka semua menggunakan metabox untuk konten sehingga mereka memiliki kontrol yang maksimal. Saya tidak yakin metabox akan dianggap "warisan" bagi banyak orang, melainkan bagian dari masa depan. Mungkin ada baiknya menjangkau orang-orang VIP WordPress untuk mendapatkan pendapat mereka.

Saya tidak yakin metabox akan dianggap "warisan" bagi banyak orang, melainkan bagian dari masa depan. Mungkin ada baiknya menjangkau orang-orang VIP WordPress untuk mendapatkan pendapat mereka.

Maafkan saya, ungkapan itu buruk. Metabox akan tetap ada. Itulah mengapa sidebar metabox diupgrade dalam bentuk sidebar "Pengaturan Posting" yang baru.

Apa yang ingin saya katakan adalah bahwa metabox baru harus ditulis dalam JS, dan akan muncul di sidebar Pengaturan Posting di samping stok. Metabox yang ditulis dalam PHP idealnya harus ditingkatkan menjadi JS, tetapi harus terus bekerja dalam bentuk PHP mereka juga. Untuk itulah panel "Pengaturan Diperluas", dan berada di sana di bagian bawah bukan karena kita tidak ingin mereka menjadi bagian dari sidebar, tetapi lebih karena sangat sulit untuk mencampur metabox PHP dan JS di sidebar.

Ada beberapa tantangan besar dalam mengirimkan metabox yang dikelola PHP melalui JS dan Ajax, terutama dalam cara menangani pembaruan metabox render untuk mencerminkan status yang baru disimpan: https://core.trac.wordpress.org/ticket/7756

Saya ingin tahu apakah menyematkan metabox lama melalui iframe bisa menjadi solusi di sini, di mana src iframe adalah sesuatu seperti /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings dan hanya menampilkan metabox yang satu itu ke dalam dokumen.

Apa yang ingin saya katakan adalah bahwa metabox baru harus ditulis dalam JS, dan akan muncul di sidebar Pengaturan Posting di samping stok.

Apakah ini berarti metabox JavaScript hanya dapat ditempatkan di sidebar, dan tidak dapat menjadi bagian dari bagian "pengaturan tambahan"? Di bagian atas kepala saya, saya dapat memikirkan banyak plugin di mana sidebar tidak benar-benar menyediakan ruang yang cukup & membuat sidebar berpotensi berantakan. Hanya beberapa plugin yang mungkin bermasalah dengan pendekatan ini:

• Yoast SEO: menyediakan sejumlah besar bidang, yang mungkin tidak muat di bilah sisi - mungkin bisa memiliki metabox bilah sisi yang membuka modal untuk lebih banyak opsi, tetapi ini terasa seperti mengatasi batasan yang tidak perlu

• Plugin bidang khusus / pembuat halaman seret & lepas - ini menggantikan atau sebagian menggantikan area konten utama & jadi membutuhkan banyak ruang layar. Potensi pembuat halaman penuh menjamin mereka membangun antarmuka mereka sendiri yang benar-benar kustom sebagai tampilan terpisah, tetapi dalam beberapa kasus sejumlah bidang terstruktur tambahan diperlukan sebagai tambahan untuk area konten utama (dan saya menghargai Guttenburg harus mengurangi kebutuhan untuk jenis plugin, tetapi sama-sama tidak dapat mencakup setiap kasus penggunaan)

• WooCommerce - menambahkan metabox untuk pesanan & data item baris, sambil menghapus editor utama (Woo berencana untuk akhirnya membangun antarmuka khusus mereka sendiri, tetapi saya menduga ini masih jauh, dan plugin lain akan berada dalam situasi yang sama)

(Saya berasumsi Guttenburg pada akhirnya direncanakan untuk mengganti tampilan post-new / post-edit.php saat ini, daripada hanya menjadi alternatif?)

Ha terima kasih @braders - Yoast UX-er check in di sini dengan pertanyaan yang sama :)

Metabox kami memang cukup besar dan luas saat ini, karena ia melakukan banyak hal. Kami tidak keberatan mengerjakan fitur-fitur itu lebih banyak ke dalam metabox berbeda di sidebar untuk menawarkan integrasi yang lebih erat, tetapi saya bertanya-tanya apakah itu mungkin? Misalnya, dapatkah kita menambahkan skor SEO ke kotak Publikasikan seperti yang kita lakukan saat ini? Dan jika tidak, dapatkah kita tetap terhubung ke kotak pengaturan yang diperluas bahkan jika metabox kita dikodekan dalam JS?

Kita harus benar-benar melihat cara membuat Pengaturan Pos baru dapat dicolokkan, sehingga Anda dapat menambahkan metabox javascript ke bilah sisi. Mungkin sudah waktunya untuk membuka tiket untuk itu. Tiket ini sebagian besar untuk metabox yang ditulis dalam PHP, yang perlu bekerja dengan cara transisi.

Sejalan dengan metabox di bagian extended, apakah sudah ada diskusi atau mockup yang dilakukan tentang bagaimana jenis postingan yang tidak mendukung pengeditan konten postingan akan disajikan? Dalam kasus tersebut, metabox di area tengah diandalkan untuk pengalaman pengeditan utama. Haruskah Gutenberg menampilkan mode "Hanya Judul"? Atau judul postingan harus ditangani secara berbeda jika editor tidak ada.

Sejalan dengan metabox di bagian extended, apakah sudah ada diskusi atau mockup yang dilakukan tentang bagaimana jenis postingan yang tidak mendukung pengeditan konten postingan akan disajikan? Dalam kasus tersebut, metabox di area tengah diandalkan untuk pengalaman pengeditan utama. Haruskah Gutenberg menampilkan mode "Hanya Judul"? Atau judul postingan harus ditangani secara berbeda jika editor tidak ada.

Sebaiknya buat tiket terpisah untuk! Dengan tangkapan layar dari jenis posting yang ada, jika Anda memilikinya! ✨

Saya juga ingin menekankan bahwa banyak plugin menggunakan jenis posting khusus yang mengandalkan kotak meta tanpa editor konten sama sekali. Jika jenis posting terdaftar tanpa dukungan untuk editor , harus ada mode hanya judul yang membuka kanvas penuh untuk digunakan oleh kotak meta.

+1 untuk menjangkau VIP WordPress. Ini juga menjadi masalah di utas Calypso: https://github.com/Automattic/wp-calypso/issues/587

Fitur yang sangat penting untuk pasar teratas!

Saya ingin tahu apakah menyematkan metabox lama melalui iframe bisa menjadi solusi di sini, di mana src iframe adalah sesuatu seperti /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings dan hanya menampilkan metabox yang satu itu ke dalam dokumen.

Saya punya ide yang sama juga. Ini juga merupakan ide bagus untuk sandboxing dan alasan manajemen sesi. Kemudian kita dapat mengidentifikasi kasus penggunaan umum fitur ini dan menerapkan API untuk menanganinya.

Saya ingin masuk sebagai pengembang plugin dan sebagai seseorang yang menggunakan WordPress terutama sebagai alat eCommerce. Juga karena @kevinwhoffman menyuruhku.

Saya lelah dengan Gutenberg hari ini dan saya benar-benar tidak dapat memproses ini sebagai WordPress tanpa melihat bagaimana metabox dan tombol editor (ditambahkan melalui hook media_buttons) menjadi bagian dari ini.

Saya juga bukan penggemar berat editor WordPress dan metabox-palooza saat ini. Saya baru saja menghitung dan dalam pengunduhan (jenis posting produk Easy Digital Download) tampilan posting tunggal saya memiliki 14 kotak meta kustom yang ditambahkan oleh Yoast, Unduhan Digital Mudah, dan kode kustom saya sendiri menggunakan CMB2. Itu banyak, tapi aku butuh itu. WordPress tidak ada gunanya tanpa antarmuka itu dan apa yang dieksposnya.

Saya khawatir ini tidak dipertimbangkan sejak awal karena saya telah mengerjakan begitu banyak situs di mana antarmuka bidang khusus ditambahkan dengan ACF, Pod, CMB2 dll adalah keseluruhan pengalaman pengeditan.

Berikut adalah masalah teknis saya:
1) Tombol ditambahkan melalui media_buttons. Di plugin saya Caldera Forms (80K + pemasangan aktif), kami menggunakan tindakan ini untuk menambahkan tombol penyisipan formulir yang menampilkan modal untuk memasukkan kode pendek ke editor posting. Mungkin kami akan pindah ke blok khusus di Gutenberg.
2) Bagaimana tindakan save_post tetap kompatibel dengan versi sebelumnya? Begitu banyak plugin, tema, dan kode khusus yang terhubung di save_action dan mengakses $ _POST super global. Itu bukan desain yang bagus, tetapi ini adalah hutang teknis yang memengaruhi jutaan situs.
3) Ada saran untuk merender metabox lama di iFrame. Ini membuat saya khawatir karena mengakses konten iFrame melalui JavaScript tidak memungkinkan.

@ Shelob9 hai!

Ada saran untuk merender metabox lama di iFrame. Ini membuat saya khawatir karena mengakses konten iFrame melalui JavaScript tidak memungkinkan.

Mengakses konten iframe melalui JavaScript _is_ memungkinkan, selama berada di domain yang sama, seperti dalam kasus ini.

Bagaimana tindakan save_post tetap kompatibel dengan versi sebelumnya? Begitu banyak plugin, tema, dan kode khusus yang terhubung di save_action dan mengakses $ _POST super global. Itu bukan desain yang bagus, tetapi ini adalah hutang teknis yang memengaruhi jutaan situs.

Hanya banyak yang dapat kami lakukan untuk memudahkan transisi dari metabox lawas ke Gutenberg. Ada perbedaan mendasar dalam bagaimana data dimodelkan di Gutenberg vs layar edit posting saat ini. Artinya, data sekarang sebenarnya dimodelkan untuk pertama kalinya. Dengan pemodelan data, kita akhirnya dapat menggunakan antarmuka JavaScript untuk memanipulasi status posting dan postmeta dengan cara yang tidak mungkin menggunakan $_POST dan tindakan save_post , apalagi dapat _preview_ mengubah postmeta. Dengan merutekan perubahan postmeta melalui model, ini akan memungkinkan postmeta untuk dipratinjau untuk pertama kalinya. Jadi, meskipun Gutenberg dapat menyertakan metabox lawas bila memungkinkan, mereka secara inheren akan selalu dibatasi seberapa banyak mereka dapat memanfaatkan antarmuka baru. Saya pikir kenyataan itu sama besarnya dengan kenyataan bahwa kita memiliki hutang teknis.

Saya pikir itu adalah keputusan Matt yang disengaja dan disadari bahwa utang teknis harus dibatalkan jika WordPress ingin berkembang sedemikian rupa sehingga akan tetap relevan di masa depan. Semakin banyak kita bisa mendapatkan ACF, Pod, dan CMB2 yang diperbarui untuk menggunakan model data yang diperkenalkan oleh Gutenberg, menurut saya akan semakin mudah transisi ini. Tidak diragukan lagi akan ada banyak tantangan dan kerja keras ke depan!

Terima kasih

Saya menduga beberapa pembahasan di sini juga sebagian tentang real estate layar yang tersedia.

Sepertinya metabox Gutenberg JS dapat memperoleh akses ke bilah samping yang dapat dialihkan (yang tidak masalah bagi saya) sementara metabox PHP lama mendapatkan akses ke area yang jauh lebih luas yang tersedia di bagian bawah layar (yang juga baik-baik saja oleh saya).

Sayangnya saya berharap bahwa keinginan untuk real estate layar yang tersedia ini dapat mengganggu diskusi yang dimaksudkan tentang cara menangani metabox PHP lama secara efektif.

Saya setuju bahwa alih-alih mendukung semua cara lama, pembuat plugin harus mempertimbangkan kembali metabox mereka dan bagaimana mereka dapat berintegrasi dengan lebih baik dengan tata letak baru. Pada saat yang sama, saya juga setuju bahwa kemungkinan serupa untuk diintegrasikan juga harus ditawarkan di editor baru (dan saya percaya mereka akan melakukannya). Saya yakin # 1352 adalah tempat utama untuk membahasnya saat ini. Masalah ini untuk membahas cara kami menyediakan kompatibilitas mundur untuk metabox PHP yang tidak diperbarui saat peluncuran.

Saya ingin tahu apakah menyematkan metabox lama melalui iframe bisa menjadi solusi di sini

Mengakses iframe bukanlah pengalaman yang super menarik bagi pengguna pembaca layar. Ada pilihan lain?

Hanya ingin berpadu di sini, sidebar tidak cukup besar untuk kebanyakan kotak meta yang kita lihat di plugin dan tema. Memaksa kami menjejalkan barang ke ruang kecil ini adalah kemunduran menurut saya. Saya pikir editor baru ini bagus, namun tidak jika itu berarti mengorbankan cara kita menggunakan kotak meta saat ini.

Saya sangat setuju dengan @kevinpmiller . Metabox membutuhkan banyak real estat dan tidak dapat disembunyikan di sidebar. Status metabox saat ini terputus-putus dan desainnya buruk, tetapi mereka juga mencerminkan apa itu WordPress - CMS yang sangat dapat diperluas.

Sebagai balasan untuk @westonruter terima kasih telah mengklarifikasi tentang kompatibilitas mundur. Saya pikir itu perlu dibuat SANGAT jelas bahwa WordPress 5.0 atau di mana pun tanah ini tidak kompatibel ke belakang karena itulah harapan pengguna.

Saya juga khawatir tentang bagaimana metabox akan ditangani, terutama di Jenis Posting Kustom tertentu di mana editor konten mungkin bukan fokus utama CPT. Saya akan memilih WooCommerce di sini karena ini adalah plugin yang terkenal, tetapi ada banyak plugin dan tema lain yang memiliki masalah serupa.

Misalnya, pesanan WooCommerce tidak memiliki editor konten - itu tidak diperlukan. Detail tentang urutan adalah yang penting, bukan pengeditan konten, dan seharusnya menjadi fokus utama halaman itu.

Akankah CPT seperti ini memiliki kemampuan untuk menghapus editor jika tidak diperlukan? Plugin tampaknya tidak sepenuhnya terintegrasi dengan metabox kustom di CPT sehingga sulit untuk mengetahui apakah ini telah dipertimbangkan atau tidak.

Produk WooCommerce juga memunculkan masalah lain di mana ada dua area konten - satu untuk deskripsi produk dan satu lagi untuk deskripsi singkat produk. Apakah yang satu perlu diutamakan daripada yang lain di area editor "utama", sementara yang lain terjebak di sidebar? Sepertinya pengalaman mengedit yang kurang optimal untuk yang ada di sidebar.

Dapatkah ada opsi untuk secara sengaja mendaftarkan pengaturan ini di area di bawah (atau di atas?) Editor daripada menjejalkan semuanya di sidebar? Ini bisa serupa dengan parameter konteks dan prioritas add_meta_box . Mungkin, bahkan beralih di antara beberapa editor konten (atau metabox lain) yang termasuk dalam bagian halaman yang lebih luas.

Mungkin saya melewatkan sesuatu di sini (tolong koreksi saya jika saya salah), tetapi tampaknya ada dorongan besar yang dibuat untuk editor yang lebih baik padahal pada kenyataannya, tidak semua penggunaan WordPress memerlukan sesuatu yang berbeda dari yang digunakan saat ini.

PERTANYAAN bagaimana kami mendefinisikan CPT untuk tidak menggunakan Gutenberg (setara dengan tanpa editor), dan HANYA menunjukkan metabox lebar penuh yang diandalkan bisnis kami.
Saya mengandalkan metabox. CPT saya paling sering terlihat seperti ini
'supports' => array( 'title' )
Dan diperpanjang dari sana. Harap pertimbangkan bagi kami yang telah membangun alat bisnis untuk klien menggunakan CPT dengan metabox sebagai entri data formulir yang dibatasi dan dipandu, bukan untuk penulisan artikel.
Pekerjaan saya sebagian besar adalah ekstensi khusus untuk CMB2 yang berinteraksi dengan sistem klien. EG daftar real estat yang menggunakan sistem pihak ke-3.

Saya tidak ingin terdengar dramatis, tetapi saya akan tetap menggunakan WP4.9 sampai masalah ini terselesaikan dan saya sangat prihatin tentang masa depan. Saya mengerti bahwa Gutenberg sedang "membatalkan hutang ke masa lalu"! Tapi hutang jatuh pada orang-orang seperti saya.

Tema di sini tampaknya adalah masalahnya bukan dengan Guttenburg, melainkan dengan kurangnya kompatibilitas ke belakang.

Ada beberapa masalah Guttenburg yang sebenarnya, di mana tiket terpisah mungkin harus dinaikkan (izinkan metabox untuk menggunakan lebar penuh, tiruan Guttenburg tanpa dukungan editor), tetapi Gutturnberg tidak dapat sepenuhnya mereplikasi layar saat ini dan juga tidak harus mencoba IMHO.

Namun, saya bertanya-tanya apakah lebih banyak yang harus dilakukan untuk membuat Guttenburg ikut serta / menyisih. Beberapa ide:

• Saya kira sebagian besar CPT saat ini menggunakan metabox secara berlebihan di editor utama. Jadi mungkin pembuat plugin harus memilih Gutturnberg dengan 'supports' => array( 'gutenburg' ) atau yang serupa

• Untuk posting dan halaman, Guttenburg mungkin harus opsional sebagai pengaturan situs. Bahkan dimungkinkan untuk menanyakan pengguna apakah mereka ingin menggunakan Guttenburg setelah update 5.0 dan menyimpan pilihan ini di DB.

• Atau sebagai alternatif, tema dapat menyatakan dukungan melalui post_type_supports (), tetapi hal ini dapat sangat mengganggu penyerapan - atau tema dapat menyisih yang tidak akan membantu pengguna tema lama dan tidak terawat yang tidak lagi diperbarui. (Mungkin plugin remove-guttenburn akan cukup untuk pengguna tema lama?)

Namun, terlepas dari implementasinya, menurut saya tampilan saat ini akan tetap ada, meskipun semakin tersembunyi dari sebagian besar pengguna ...

Saya menyukai ide teoritis CPT yang secara eksplisit meminta 'supports' => array( 'gutenberg' ) untuk mempertahankan fungsionalitas yang ada jika flag dukungan 'gutenberg' tidak ditentukan. Ini akan menghemat banyak pekerjaan untuk memperbaiki situs lama untuk klien yang marah yang memperbarui ke WP5.

Saya perhatikan bahwa fitur 'support' => yang ada (judul, editor, penulis, ...) memiliki nama yang sangat deskriptif, Gutenberg menonjol sebagai nama _project_ di sini. Saya ingin tahu apakah nama fitur yang lebih deskriptif akan dipertimbangkan untuk penggunaan itu; mungkin "editor blok"? 'supports' => array( 'block-editor' )

Tentu perlu ada strategi untuk menangkap kesalahan seperti 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . Saya berasumsi bahwa flag 'block-editor' hanya akan menimpa mode 'editor' yang lebih lama.

Pengembang plugin lain di sini dengan kekhawatiran.

Jika meta bilah sisi hanya dapat diakses melalui JS, apa artinya ini untuk metabox terdaftar PHP dengan konteks side ? Memindahkannya ke bagian Extended Settings yang diusulkan mencabut gagasan bahwa metabox itu kontekstual.

Seperti yang kita semua sadari, sidebar bukan hanya keputusan desain yang bagus; mereka sering menyimpan konten relasional dengan cara yang membantu pengguna memahami prioritas kontennya dan hubungannya dengan konten utama. Menetapkan side metabox konteks yang berbeda karena hambatan teknis tampaknya agak salah arah.

Mempertimbangkan JS-ification progresif dari area admin, metabox "warisan" ini juga menyediakan plugin dan pengembang tema titik pemasangan alami untuk React / Vue / aplikasi lain yang berdiri sendiri untuk menyediakan fungsionalitas tambahan ke halaman edit.

Editornya tampak hebat, tapi tolong jangan lupakan sisa halamannya.

Saya memiliki kesempatan untuk memikirkan hal ini sedikit lebih banyak dan dengan beberapa konteks yang dibagikan oleh orang lain di sini, saya pikir masih ada masalah lain. Editor baru ini memaksa kita ke dalam satu tata letak dan alur kerja; mengapa kami menghapus penyesuaian? Kemampuan untuk memahat entri data pada setiap klien adalah apa yang membuat WordPress dan sebagian besar solusi lainnya benar-benar hebat. Semakin saya bermain dengan editor ini, semakin terasa seperti versi Customizer yang membengkak di mana area pratinjau telah diganti dengan editor dan sidebar hanya bertukar sisi.

Juga disebutkan bahwa kami dapat menggunakan ini untuk menulis posting, tetapi izinkan CPT untuk menambahkan dukungan untuk ini. Saya rasa itu juga tidak akan berhasil. Organisasi berita akan menyukai jenis editor ini tetapi juga memiliki persyaratan untuk alur kerja khusus seputar konten tambahan, penjadwalan, sematan, infografis, dan data lain yang diperlukan.

Bagaimana membuat editor ini berperilaku seperti editor layar penuh / bebas gangguan? Dengan cara ini kita bisa mendapatkan yang terbaik dari kedua dunia tanpa mengorbankan fungsionalitas dan kode "warisan". (BTW - Saya pikir konyol bahwa cara kami saat ini membangun kotak meta sekarang disebut sebagai "warisan ..." dalam proyek ini).

Terima kasih atas waktunya teman-teman, ini dihargai.

Bagaimana membuat editor ini berperilaku seperti editor layar penuh / bebas gangguan?

+1

Saya akan mengulangi perhatian utama saya: CPT sering tidak memerlukan 'editor' karena postingan dibuat dari metabox yang besar dan dikelompokkan secara dinamis dalam alur kerja pengguna yang dipandu (misalnya data Produk WooCommerce).

Metabox semacam itu tidak akan cocok dengan laci "setelan tambahan" yang diusulkan karena mereka membentuk elemen entri konten utama dan harus menonjol di editor pos, dengan lebar penuh dan terbuka. Dengan pemikiran tersebut, # 952 tampaknya konsesi yang terlalu kecil karena membuang entri data penting ke laci tertutup.

Jika kami pengembang diharapkan untuk _refactor_ semua solusi metabox lama kami ke dalam blok maka seseorang dari Automaticc perlu menyatakan itu dengan jelas dan publik sebelum palu jatuh di 5.0. Saya tidak melihat tanda apa pun bahwa tim telah mempertimbangkan bagian pasar ini dan implikasinya bagi bisnis.

Banyak pemikiran baik telah ditambahkan di sini, jadi saya hanya akan memberikan pemikiran sederhana ini:

Alih-alih memiliki expander "Pengaturan Diperpanjang" di bagian bawah untuk semua hal lama, mengapa tidak membuat expander untuk setiap metabox yang terletak di bagian bawah persis seperti itu, saat metabox berada dalam konteks normal dan lanjutan, lalu gunakan pengaturan samping untuk konteks samping?

Sepertinya kita tidak jauh dari solusi. Dan jika jenis posting tidak mendukung editor, maka sembunyikan saja editor tetapi semua yang lain muncul dengan cara yang sama. Itu tata letak yang masuk akal. Cukup berikan opsi seperti menyetel metabox diperluas default.

Saya tentu tidak keberatan dengan gagasan untuk mempertimbangkan metode saat ini untuk merender warisan metaboxes dan menyediakan metode baru yang digerakkan oleh js dan lebih disukai untuk membangun bidang. Kami kemudian dapat beralih secara bertahap tanpa harus panik tentang hal-hal yang langsung rusak di 5.0.

Semoga pikiran ini membantu. Jika orang lain telah mengatakan sesuatu tentang hal ini, anggap saja ini sebagai kesepakatan. 😄

Saya ingin menambahkan dua pengait berharga lainnya ke dalam diskusi: edit_form_after_title dan edit_form_after_editor yang saat ini memberikan kendali penuh atas UI pasca-edit. Jelas Gutenberg bukan hanya pengganti untuk "wp_editor", ini adalah tampilan berbeda dari UI (dan seperti yang terlihat saat ini, kemampuan pengembangan modularnya di masa mendatang).

Saya melihat bahwa masalah seperti ini mencoba untuk mengatasi masalah tetapi saya merasa ini bukan tentang "apa yang terjadi pada metabox kami", ini lebih tentang pertanyaan di mana WordPress mengarah sebagai "produk".

Sangat mudah untuk menemukan tujuan jangka menengah dari menetapkan solusi seperti itu: akan sangat mudah untuk memindahkan ini ke frontend (dan mungkin lebih dekat dengan beberapa pesaing).

Dari perspektif pengembang / bisnis / perencanaan, akan sangat membantu untuk memahami niat (masa depan) dari 'Gutenberg', atau dapatkah seseorang mengarahkan saya ke pernyataan misi semacam itu atau yang serupa?

Beberapa pendapat lagi dari saya ...

Saya perhatikan bahwa fitur 'dukungan' => yang ada (judul, editor, penulis, ...) memiliki nama yang sangat deskriptif, Gutenberg menonjol sebagai nama proyek di sini. Saya ingin tahu apakah nama fitur yang lebih deskriptif akan dipertimbangkan untuk penggunaan itu; mungkin "editor blok"? 'mendukung' => array ('block-editor')

Saya setuju - ini terdengar seperti detail yang dapat disortir setelah pendekatannya disetujui 😄

Tentu perlu ada strategi untuk menangkap kesalahan seperti 'support' => array ('title', 'editor', thumbnail ',' block-editor '). Saya berasumsi bahwa flag 'block-editor' hanya akan menimpa mode 'editor' yang lebih lama.

Saya akan melihat Gutenberg memperluas dukungan jenis posting saat ini - jadi jika tidak ada editor dukungan maka Gutenburg hanya akan menampilkan opsi judul / sidebar / diperpanjang. Jadi mungkin dukungan Gutenburg akan lebih baik ditangani sebagai argumen pendaftaran CPT terpisah, daripada menjadi bagian dari array pendukung?

Alih-alih memiliki expander "Pengaturan Diperpanjang" di bagian bawah untuk semua hal lama, mengapa tidak membuat expander untuk setiap metabox yang terletak di bagian bawah persis seperti itu, saat metabox berada dalam konteks normal dan lanjutan, lalu gunakan pengaturan samping untuk konteks samping?

Saya pribadi menyukai ide ini - Jika panel ini dapat diatur ulang, dan disembunyikan sebanyak mungkin saat ini, itu bisa menjadi solusi ide ...

Mungkin, harus ada cara untuk mengatur satu (atau lebih?) Atau ini sebagai terbuka saat pemuatan halaman - terutama jika jenis posting tidak mendukung editor utama.

Juga disebutkan bahwa kami dapat menggunakan ini untuk menulis posting, tetapi izinkan CPT untuk menambahkan dukungan untuk ini. Saya rasa itu juga tidak akan berhasil. Organisasi berita akan menyukai jenis editor ini tetapi juga memiliki persyaratan untuk alur kerja khusus seputar konten tambahan, penjadwalan, sematan, infografis, dan data lain yang diperlukan.

Jika layar berbasis react yang baru dapat dipasang seperti layar edit lama, maka tidak ada alasan mengapa alur kerja kustom ini tidak dapat ditambahkan ke bagian atas halaman / sidebar / di bawah editor atau di tempat lain pada halaman. (Penafian: Saya tidak memiliki pemahaman mendalam tentang React, jadi masih harus dilihat berapa banyak hook yang lebih kompleks di luar PHP). Juga # 1352

Saya pikir kebingungan di sini adalah karena ada perbedaan mendasar dalam cara Gutenberg membayangkan ulang editor untuk diblokir terlebih dahulu . Dengan kata lain, kita harus menjauh dari berpikir tentang menambahkan metabox dan sebaliknya berpikir tentang menambahkan blok. Bidang yang sebelumnya akan Anda masukkan ke dalam metabox, Anda sekarang akan bergerak maju, bukan dimasukkan ke dalam blok.

Saat Anda menentukan jenis posting kustom, ini kemungkinan akan mencakup blok yang diperlukan dan blok mana yang hanya diperbolehkan. Untuk jenis posting kustom yang tidak memiliki editor support akan tetap memiliki “editor” yang ditampilkan di Gutenberg, tetapi pada dasarnya dapat menonaktifkan _inserter_. Blok yang muncul di editor akan dikunci sesuai dengan kebutuhan jenis posting. Jika blok belum diisi maka mereka akan muncul sebagai _placeholder_. Perhatikan bahwa blok ini kemudian dapat menyimpan propertinya di postmeta seperti yang dilakukan metabox saat ini, tetapi mereka akan melakukannya dengan cara yang dinormalisasi alih-alih ad hoc melalui aksi save_post dan $_POST global.

Jadi saya pikir hasil akhirnya di sini sebagian besar akan sama. Pembuat plugin akan terus mendapatkan "kotak" untuk memasukkan bidang khusus. Hanya saja mereka akan muncul di blok, bukan di metabox.

Saya pikir kebingungan di sini adalah karena ada perbedaan mendasar dalam cara Gutenberg membayangkan ulang editor untuk diblokir terlebih dahulu. Dengan kata lain, kita harus menjauh dari berpikir tentang menambahkan metabox dan sebaliknya berpikir tentang menambahkan blok. Bidang yang sebelumnya akan Anda masukkan ke dalam metabox, Anda sekarang akan bergerak maju, bukan dimasukkan ke dalam blok.

@westonruter Ini tampaknya cukup masuk akal untuk metabox yang berisi konten, tetapi banyak meta kiriman khusus layanan metabox yang tidak masuk akal dalam konten kiriman.

Terima kasih @westonruter untuk klarifikasi, tetapi ini menimbulkan beberapa pertanyaan baru bagi saya.

Blok yang menyimpan datanya sebagai post_meta tampak seperti jenis blok yang secara fundamental berbeda dari yang saya lihat sejauh ini di demo. Apakah data ini juga akan disimpan secara berlebihan dalam aliran konten postingan?

Adakah yang menghentikan penulis untuk menambahkan lebih dari jumlah blok yang dapat diterima ke sebuah posting? (Menambahkan beberapa bidang post_meta jika hanya satu yang masuk akal)

Saya cenderung setuju dengan @westonruter tentang menjelajahi blok sebagai pintu gerbang ke metadata. Namun, yang saya sarankan adalah memisahkan gagasan blok dari post_content. Blok pada jenis posting kustom tidak harus menjadi anggota dari apa yang keluar dari post_content di front end. Berikut adalah contoh penggunaan plugin Kalender Acara (interpretasi saya) oleh suku modern.

Dalam situasi ini, konten utama adalah detail acara, bukan area konten bentuk bebas. Plugin akan menggunakan metadata dari jenis posting kustomnya untuk mengumpulkan markupnya sendiri dan post_content hanyalah teks deskriptif yang dicetak di bagian bawah halaman. Karena itu, blok detail acara tidak boleh dipindahkan, dihapus, atau benar-benar menjadi bagian dari keluaran konten sama sekali. Namun, itu harus muncul pertama kali, karena itu mewakili konten utama untuk jenis posting ini.

WooCommerce akan menjadi contoh lain di mana satu atau lebih blok informasi produk harus didahulukan daripada teks deskriptif pada jenis posting Produk, tetapi mereka tidak boleh menjadi blok opsional yang diharapkan pengguna untuk dimasukkan sendiri.

Saya pikir konsep dasar untuk blok harus merakit antarmuka pengguna yang tepat untuk posting dan tidak selalu menyiratkan di mana data itu akan disimpan atau diberikan di frontend.

... kita harus menjauh dari berpikir tentang menambahkan metabox dan sebaliknya berpikir tentang menambahkan blok.

Itu masuk akal untuk konten, tetapi banyak plugin menggunakan jenis posting khusus untuk non-konten seperti formulir atau pembayaran. Jenis posting ini sama sekali tidak menyerupai posting blog, dan meta field abstrak mereka juga tidak mendapat manfaat dari editor blok. Memaksa semua konfigurasi untuk dilakukan dengan blok akan menghapus kanvas terbuka yang diandalkan oleh pengembang plugin, kanvas terbuka yang sama yang telah membuat ekosistem plugin seperti sekarang ini.

Pendekatan saat ini tampaknya menjadi yang pertama blok dengan kotak meta terbatas pada peran pendukung. Sementara blok akan menguntungkan banyak plugin yang berfokus pada konten, kebutuhan untuk menentukan pengaturan abstrak masih akan mendapat manfaat dari label yang jelas dan input yang sudah dikenal yang disediakan oleh kotak meta. Dalam kasus tersebut, pengembang harus memiliki kebebasan untuk menggunakan seluruh kanvas.

@westonruter Bisakah Anda menjelaskan bahwa apa yang Anda katakan adalah bahwa jika jenis posting kustom saya memerlukan bidang tambahan tertentu, saya akan meminta data itu dimasukkan dalam satu blok?

Jika ya, saya punya beberapa pertanyaan lanjutan:

1) Apakah saya dapat menjadikan blok itu sebagai default? IE selalu ditampilkan pada jenis posting itu dan tidak dapat dihapus. Misalnya, jika plugin saya membuat acara dan setiap acara memiliki tanggal mulai dan berakhir, apakah pemblokiran untuk tanggal mulai dan akhir diperlukan dan di konten postingan saat mengedit jenis postingan kustom acara secara default?

2) Bagaimana data bisa disimpan dari blok itu? Seperti yang saya pahami, saat ini data dari blok disimpan sebagai komentar HTML di post_content. Bagaimana kami mendapatkan data dari blok ini untuk memposting meta? Misalnya, untuk plugin acara hipotetis saya, bagaimana saya bisa mendapatkan tanggal mulai dan tanggal akhir ke dalam meta posting sehingga saya dapat menanyakannya?

3) Apa alasan untuk semua ini berjalan ke arah editor konten utama dan menerapkannya pada jenis posting kustom? Apakah ada pengujian pengguna yang mendukung arah desain ini, terutama terkait jenis postingan kustom yang tidak mewakili postingan / artikel blog?

@kevinwhoffman Saya masih tidak melihat konflik mendasar untuk pemblokiran. Pengaturan abstrak masih dapat dianggap konten, tetapi jenis yang berbeda: itu semua data. Setiap blok tidak perlu memiliki representasi visual dalam "konten". Saya pikir mungkin ada "metablocks" juga, menyimpan data di postmeta daripada post_content . Blok yang sedang diedit dapat dengan gaya memiliki tajuk / label yang mirip dengan bagaimana metabox disajikan hari ini.

@ Shelob9 ya, jika jenis posting kustom Anda membutuhkan bidang tambahan maka saya pikir mereka akan disajikan dalam satu blok. Jika Anda memiliki jenis posting kustom "produk" maka mungkin ada blok product-details tunggal yang memiliki kolom untuk harga, variasi, dan seterusnya.

1. Bisakah saya menjadikan pemblokiran itu sebagai default? IE selalu ditampilkan pada jenis posting itu dan tidak dapat dihapus. Misalnya, jika plugin saya membuat acara dan setiap acara memiliki tanggal mulai dan berakhir, apakah pemblokiran untuk tanggal mulai dan akhir diperlukan dan di konten postingan saat mengedit jenis postingan kustom acara secara default?

Ya persis. Jenis posting kustom, format posting, dan template halaman semuanya dapat dengan mudah melibatkan konsep blok yang diperlukan yang "terkunci", tidak dapat dihapus atau disusun ulang. Salah satu contohnya adalah pemblokiran kutipan postingan: https://github.com/WordPress/gutenberg/issues/1288#issuecomment -310544967

1. Bagaimana data bisa disimpan dari blok itu? Seperti yang saya pahami, saat ini data dari blok disimpan sebagai komentar HTML di post_content. Bagaimana kami mendapatkan data dari blok ini untuk memposting meta? Misalnya, untuk plugin acara hipotetis saya, bagaimana saya bisa mendapatkan tanggal mulai dan tanggal akhir ke dalam meta posting sehingga saya dapat menanyakannya?

Kebanyakan blok saat ini menyimpan datanya dalam HTML di dalam post_content tetapi sebenarnya tidak perlu. Misalnya, di https://github.com/WordPress/gutenberg/issues/1288 Anda dapat melihat diskusi tentang blok Kutipan yang menyimpan kontennya dalam post_excerpt dan blok Gambar Unggulan yang menyimpan kontennya di postmeta. Jadi, Anda pasti bisa memiliki blok event-details yang memiliki tanggal mulai dan akhir yang disimpan di postmeta.

1. Apa alasan untuk semua ini berjalan ke arah editor konten utama dan menerapkannya pada jenis posting kustom? Apakah ada pengujian pengguna yang mendukung arah desain ini, terutama terkait jenis postingan kustom yang tidak mewakili postingan / artikel blog?

Sesuai di atas, data dapat bersumber dari dan disimpan ke post_content , postmeta, term, atau tempat lainnya. Gagasan menjadi "blokir dulu" adalah memiliki _block_ bangunan umum yang digunakan semua orang dan dengan demikian komponen blok dapat digunakan kembali secara maksimal di seluruh WordPress. Itulah pemahaman saya.

@westonruter - Terima kasih atas klarifikasinya. Ini sangat berguna karena tidak banyak informasi tentang bagaimana editor ini berhubungan dengan jenis posting yang bukan posting / artikel blog, dll.

Saya harap kita akan melihat dokumentasi tentang cara menulis "metablock" segera.

Kami harus mempertimbangkan apa yang kami ajarkan kepada pengguna melalui pengalaman pengeditan Posting dan bagaimana peta itu untuk jenis posting kustom.

Saat mengedit Post default di editor blok, pengguna mengetahui bahwa setiap blok mewakili konten. Pengaturan yang terkait dengan konten tersedia di panel / kotak meta yang berada di luar editor blok. Konten tinggal di blok. Pengaturan tinggal di panel. Dikatakan di tempat lain bahwa apa yang dilihat pengguna di editor blok haruslah pratinjau halaman saat diterbitkan.

Untuk kemudian menggabungkan pengaturan dan konten dalam editor blok untuk jenis posting kustom mematahkan gagasan bahwa editor blok adalah pratinjau. Saya pikir kita harus membiarkan editor blok melakukan yang terbaik, yaitu mengedit konten, dan memberdayakan pengembang untuk membangun antarmuka pengaturan yang tidak memiliki persyaratan yang sama dengan blok konten.

Saya telah mengerjakan plugin ekstensif yang menambahkan kotak meta seperti WooCommerce dan EDD. Sering kali, saya telah menghapus editor konten dari layar karena tidak diperlukan. Saya agak khawatir bahwa ini seharusnya tidak menjadi sesuatu yang harus kita gabungkan dengan Gutenberg.
Jika tidak, kemana perginya semua ini.

Saya setuju dengan @kevinwhoffman bahwa jika blok akan mewakili meta maka mereka memerlukan isyarat visual kepada pengguna bahwa ini entah bagaimana berbeda dari konten posting dan seharusnya tidak diharapkan dalam output. Salah satu cara untuk mengatasinya adalah dengan pembatas. Ini pada dasarnya hanyalah penafsiran ulang tentang cara konten dipisahkan dari metabox sekarang.

Ini tidak menyelesaikan setiap masalah untuk saya, tetapi saya pikir ini adalah cara yang menarik untuk memberikan metabox facelift dan mungkin bisa cukup kompatibel dengan plugin yang ada, tetapi itu tidak akan menjadi pengalaman kelas satu bagi pengguna.

Berikut salah satu upaya untuk memberi tahu pengguna ketika blok meta adalah konten utama, konten posting digunakan sebagai deskripsi, dan ada blok meta tambahan.

@brentjett Terima kasih atas

• Itu _not_ mewakili konten pada halaman, sehingga mematahkan gagasan bahwa editor blok adalah pratinjau konten pada halaman.
• Itu _not_ membutuhkan banyak contoh.
• Itu _not_ mendapat manfaat dari reposisi di tengah blok konten lainnya.
• Ini _harus_ ada di halaman secara default.

Masing-masing sifat ini berlawanan dengan perilaku default sebuah blok. Tentu ada berbagai diskusi untuk membuat blok sekali pakai yang dapat dikunci di posisinya dan hadir secara default. Tapi mengapa memelintir blok menjadi kotak meta ketika kita malah bisa fokus pada peningkatan implementasi kotak meta yang sudah melayani tujuan ini?

Saya tidak melihat manfaat dari meminta kotak pengaturan seperti Yoast untuk diblokir sejak awal.

Mari kita mundur sebentar. Dua hal. Salah satunya adalah dukungan untuk metabox lama yang ditulis dalam PHP, di mana kami memiliki laci "pengaturan yang diperluas" yang diolok-olok di posting ini.

Hal lainnya adalah menjawab pertanyaan: jika kita ingin mendesain ulang dari bawah ke atas, akan terlihat seperti apa hari ini?

Di sinilah kami mengusulkan _blocks_, sebagai antarmuka baru yang dapat menyatukan banyak antarmuka yang berbeda. Kami sudah menyarankan bahwa pemblokiran bisa lebih baik daripada kode pendek, HTML khusus, widget, dan kemampuan penyematan. Bergantung pada apa yang dilakukan metabox, tidak ada alasan ia juga tidak dapat memasukkan antarmuka ini.

Sepakat. Dan berbicara untuk Yoast sebentar, kami berencana untuk berintegrasi ke banyak tempat di sekitar editor baru, meningkatkan pengalaman yang dituju gutenberg alih-alih membangun satu blok besar untuk meniru metabox lama kami, tetapi ada contoh lain yang disebutkan di atas yang akan bekerja sebagai blok juga saya pikir. Ya, ini membutuhkan beberapa usaha, tetapi jika ternyata editor ini akan menggairahkan pengguna wordpress setelah mendapatkan daya tarik yang lebih banyak, itu adalah kesempatan yang menarik untuk memikirkan kembali bagaimana kita berintegrasi dengannya, dan saya pikir produk kita akan menjadi lebih baik sebagai hasilnya.

Jadi, kami memiliki dua kasus fungsional _legacy_:
MetaBoxes yang menangani meta-data (seperti Yoast), dan kami memiliki MetaBoxes yang digunakan untuk menyediakan antarmuka terstruktur untuk memasukkan konten (seperti WooCommerce).

Berkembang untuk masa depan
Jika kita mulai dari daftar kosong ("membatalkan hutang kita ke masa lalu") maka benar bahwa meletakkan meta-data di laci "lanjutan" yang diusulkan mungkin berhasil. Juga - entri konten terstruktur mungkin cocok dengan antarmuka perintah blok yang terkunci di dalam Gutenberg. Keduanya sepenuhnya hipotetis, tetapi berpotensi berfungsi sebagai implementasi untuk pengembangan WP CMS di masa mendatang.

masalah CMS bisnis lama
99% pekerjaan saya adalah memberikan solusi bisnis yang dipesan lebih dahulu langsung ke perusahaan klien saya. Jadi perhatian saya bukanlah pada hal-hal hebat yang mungkin saya bangun di masa depan, tetapi fakta-fakta keras yang dingin dari fungsionalitas situs klien saya, dan hubungan bisnis. Proposal apa yang ada untuk memigrasi bisnis berbasis solusi CMS yang ada ke Gutenberg? Dalam situasi saya, setiap klien memiliki solusi CMS khusus yang berbeda yang dibangun di atas kerangka WP yang sudah mapan. Bagi saya ungkapan "membatalkan hutang ke masa lalu" = "Membuang bayi dengan air mandi".

Kekhawatiran
Jika Gutenberg dikirim sebagai inti di WP5.0, saya mengantisipasi klien saya akan memiliki situs yang tidak berfungsi. Kemudian setiap situs perlu dibuat ulang dan setiap klien ditenangkan. Sekitar 40 klien mungkin ingin saya memperbaiki CMS mereka dalam minggu itu.

• situs yang bergantung pada kotak meta CMS lama dan basis penggunanya tampak tidak penting bagi tim Inti
• proposal undian "lanjutan" # 952 telah diturunkan prioritasnya, yang menunjukkan kurangnya minat di seluruh area.
• tidak ada metode yang diusulkan untuk menyelesaikan masalah "hutang masa lalu" / CMS

Di sinilah kami mengusulkan blok, sebagai antarmuka baru yang dapat menyatukan banyak blok yang berbeda. Kami sudah menyarankan bahwa pemblokiran bisa lebih baik daripada kode pendek, HTML khusus, widget, dan kemampuan penyematan.

Pemblokiran masuk akal untuk semua hal itu - kode pendek, HTML khusus, widget, sematan. Mereka semua adalah bentuk konten yang muncul di halaman. Saya setuju, blokir semuanya.

Pengaturan bukanlah hal-hal itu. Pengaturan memiliki persyaratan berbeda yang tidak tumpang tindih dengan perilaku dasar sebuah blok. Dalam banyak kasus, kotak pengaturan ini menyimpan meta posting yang tidak ada hubungannya dengan presentasi front-end dari sebuah posting. Untuk mengurai non-konten bersama konten setiap kali posting ditampilkan tampaknya tidak perlu.

Hal lain yang perlu dipertimbangkan adalah apa yang terjadi ketika pengguna beralih ke mode Teks. Apakah mereka akan melihat banyak komentar HTML yang mewakili kotak pengaturan di samping konten posting mereka? Akankah pengguna menghapus hal-hal asing ini?

Semua ini dapat disederhanakan dengan memperlakukan blok sebagai konten dan pengaturan sebagai komponen UI terpisah. Meskipun kami tidak perlu mempertimbangkan kotak meta lama (yang merupakan masalah besar yang @steveangstrom tunjukkan), pengalaman pengguna masih akan mendapat manfaat dari pemisahan yang jelas antara konten dan pengaturan.

Bagian Kekhawatiran @steveangstrom adalah

Ini adalah diskusi yang bagus tentang apa yang akan mungkin terjadi di masa depan dan kedengarannya bagus, WordPress karena memang membutuhkan ini. Bagi saya, sebagai pengembang plugin, bukan masalah besar, saya akan membuat satu atau dua blok dan menjadi baik. Tapi apa yang terjadi pada klien Steve dan jutaan situs web di luar sana yang dijual kepada klien dengan ekspektasi kompatibilitas ke belakang?

Saya memahami kekhawatiran ini karena saya juga memiliki banyak klien yang situs webnya mungkin akan rusak dengan pembaruan. Beberapa pemikiran dari saya:

Kami secara ekstensif menggunakan ACF untuk manajemen konten. Misalnya, kami mungkin memiliki beberapa editor tinymce per posting, atau di repeater. jika tujuannya adalah untuk mengganti tinymce, bagaimana kita akan menggunakan beberapa "wadah blok"? Saya mengerti benar saat ini hanya ada satu "wadah blok", bukan?

Fitur ACF lain yang tidak sesuai dengan alur pengeditan posting adalah halaman opsi. Saya benar-benar tidak melihat bagaimana ini akan bekerja pada halaman opsi.

Bagi mereka yang menginginkan kompatibilitas mundur - seseorang mungkin akan membuat plugin untuk memulihkan pengalaman pengeditan saat ini, jika tidak ada waktu / sumber daya untuk memperbarui ke gutenberg (ini adalah sesuatu yang saya rencanakan untuk digunakan). Selain itu, 5.0 akan menjadi tonjolan versi utama, yang berarti bahwa perubahan yang melanggar tidak masalah (setidaknya menurut standar semver ).

WordPress tidak mengikuti semver.

@westonruter Saya pikir ini masuk akal:

Bidang yang sebelumnya akan Anda masukkan ke dalam metabox, Anda sekarang akan bergerak maju, bukan dimasukkan ke dalam blok.

Tapi, bagaimana kita pergi dari sana (metabox) ke sini (blok)? Baik dalam hal backcompat untuk kode (plugin yang belum diperbarui untuk Gutenberg) dan backcompat untuk data (bagaimana kami menampilkan data metabox yang ada di blok konten baru, setelah plugin diperbarui untuk itu; apakah itu sebuah plugin- masalah ruang lingkup?).

Tapi, bagaimana kita pergi dari sana (metabox) ke sini (blok)? Baik dalam hal backcompat untuk kode (plugin yang belum diperbarui untuk Gutenberg) dan backcompat untuk data (bagaimana kami menampilkan data metabox yang ada di blok konten baru, setelah plugin diperbarui untuk itu; apakah itu sebuah plugin- masalah ruang lingkup?).

Ini adalah pertanyaan yang bagus. Kami akan mengeksplorasi jawabannya saat kami menerapkan fitur ini.

Jika saya harus menebak di mana kita akan berakhir di sini: metabox saat ini akan dipindahkan ke area "legacy" dan kami akan memberikan API, dokumentasi, dan contoh untuk mendaftarkan metabox-block-thingies "gaya baru".

@ nylen bagaimana dengan _rendering_ dari metabox saat ini?

Kabar baik bahwa kotak meta sedang diprioritaskan, tetapi kami perlu mempertimbangkan solusi yang lebih dari sekadar menempatkan kotak meta lama di laci atau membatasinya ke area "warisan".

Ada banyak situs yang ada saat ini yang terutama dibuat dengan kotak meta melalui plugin seperti Bidang Kustom Lanjutan. Kita berbicara tentang antarmuka layar penuh di sini, bukan hanya satu atau dua kotak di bagian bawah pos. Saya yakin ACF akan diperbarui untuk bekerja dengan Gutenberg, tetapi situs tersebut tidak akan dibuat ulang.

Jadi pertanyaannya tetap, apa yang terjadi pada antarmuka yang tidak memiliki editor dan seluruhnya terdiri dari kotak meta?

Jadi pertanyaannya tetap, apa yang terjadi pada antarmuka yang tidak memiliki editor dan seluruhnya terdiri dari kotak meta?

Idenya di sini, dan perbaiki saya jika saya salah @mtias , adalah Anda hanya menyembunyikan area konten dengan plugin Anda, dan yang Anda lihat adalah metabox di mana konten itu berada.

Bagaimana membuat editor ini berperilaku seperti editor layar penuh / bebas gangguan?

+1. Ini adalah ide yang bagus karena tidak mempengaruhi editor saat ini dengan kotak meta sama sekali. Sementara editor bebas gangguan ada di sana untuk waktu yang lama, itu tidak banyak digunakan. Editor Gutenberg dapat mengambil ini dan meningkatkan daripada menulis ulang layar editor.

Juga, akan lebih baik jika kita mendaftarkan dukungan untuk editor Gutenberg dengan parameter supports saat register_post_type .

Akhirnya, sebagai pengembang kotak meta, saya ingin melihat API baru untuk membuat kotak meta berfungsi untuk editor baru. Seperti yang Anda lihat di sini, banyak pengembang menggunakan kotak meta sebagai cara untuk menyediakan konten tambahan untuk kiriman. Konten tersebut dapat dikategorikan, dicari nanti. Ini bukan hanya blok konten sederhana sebagai konten posting. Jadi, jika ada pengganti baru untuk fungsi add_meta_box() , saya dengan senang hati memperbarui plugin Meta Box saya agar berfungsi dengan itu.

Setuju dengan semua yang telah dikatakan tentang: membuat metabox standar masih berfungsi / memiliki tempat. Sebagai pengembang utama CMB2, saya dapat menjamin akan ada protes yang cukup signifikan jika CMB2 entah bagaimana rusak ketika WordPress 5.0 dirilis. Saya tentu tidak bermaksud ini sebagai ancaman, tetapi hanya sebagai kenyataan.

Semakin banyak kita bisa mendapatkan ACF, Pod, dan CMB2 yang diperbarui untuk menggunakan model data yang diperkenalkan oleh Gutenberg, menurut saya akan semakin mudah transisi ini.

Saya pasti akan melakukan ini dalam jangka panjang, tetapi saya tidak yakin itu adalah harapan yang adil bahwa perpustakaan metabox akan memiliki ini pada saat gutenberg dirilis. (Memang, itu mungkin bukan harapan)

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

Dan bahkan jika diperbarui, instalasi lama akan rusak.

Harap perhatikan juga bahwa Grup Bidang di ACF tidak perlu dalam metabox, tetapi ada juga gaya 'Seamless (tidak ada metabox)' dengan opsi 'Sisi', 'normal - setelah konten' dan 'tinggi - antara judul dan editor (!!!) '. Yang terakhir penting untuk menciptakan alur pengeditan yang bermakna.

Harap diingat bahwa ada banyak perkembangan individu penting di luar sana, yang tidak akan pernah diperbarui karena tidak ada yang akan membayarnya. Melanggar implementasi tersebut akan menjadi pembunuh utama bagi WP di lingkungan perusahaan.

@ wsydney76 Harap perhatikan juga bahwa Grup Bidang di ACF tidak perlu dalam metabox, tetapi ada juga gaya 'Seamless (tidak ada metabox)' dengan opsi 'Sisi', 'normal - setelah konten' dan 'tinggi - di antara judul dan editor (!!!) '. Yang terakhir penting untuk menciptakan alur pengeditan yang bermakna.

Perlu dicatat bahwa ini bukan sesuatu yang "hanya berfungsi" di WordPress tetapi memerlukan kode plugin kustom untuk menghapus UI metabox biasa - jadi masuk akal untuk mengasumsikan bahwa ini akan memerlukan pekerjaan tambahan dari ACF untuk bekerja dengan Gutenburg.

Sederhanakan. Ketika jenis posting khusus tidak memiliki dukungan untuk editor (Gutenberg) dinyatakan, gunakan imajinasi Anda, keterampilan CSS, dan desainer inti paling berbakat Anda untuk mengubah seluruh editor menjadi sesuatu yang lain. Jadikan itu tampak sebagai bukan sesuatu yang dilihat oleh klien / Pengguna saat berada di layar pengeditan kiriman (asli). Ini hanya tentang penampilan. Klien tidak peduli apakah Gutenberg bekerja di latar belakang atau tidak, mereka tidak peduli bahkan jika mereka diberitahu oleh pengembang web. Mereka adalah tipe orang yang visual.

Mengenai kompatibilitas mundur, saya mengusulkan versi Dukungan Jangka Panjang WordPress pada bulan Februari, jauh sebelum pengumuman Gutenberg mencapai 5.0.

Pada titik itu sepertinya tugas yang mustahil, tetapi sekarang hal itu terjadi, bahkan lebih penting untuk mendiskusikan pembuatan 4.9 versi LTS, memotong dukungan sebelum 4.9 dan berfokus pada 5.0.

Postingan tersebut dapat ditemukan di sini:
https://khromov.se/wordpress-needs-another-long-term-support-version/

10 tahun + pengembang WordPress di sini. Seperti yang ditunjukkan banyak orang, perkembangan ini bagus untuk konten. Ini adalah solusi standar yang sangat dibutuhkan untuk blok konten dinamis dengan markup khusus. Karena itu, ini membatasi penggunaan jenis posting dengan cara yang mengarahkan dari konten dan membawa WordPress lebih dekat ke kerangka kerja.

Sebagai contoh: Saya membangun seperangkat plugin yang memungkinkan untuk tidak hanya membuat bidang untuk jenis posting (seperti banyak lainnya) tetapi juga untuk membuat hubungan di antara mereka (yaitu satu ke satu, satu ke banyak dan seterusnya). Ini (bersama dengan lebih banyak fitur) mengubah jenis posting menjadi sesuatu yang sangat dekat dengan model dalam kerangka kerja seperti Laravel atau Rails, dan saya kemudian menggunakan DSL untuk bekerja dengan posting tersebut, data dan hubungannya.

Jenis penggunaan ini jauh dari biasa, dan WordPress sendiri mendorong penggunaan kreatif jenis posting dengan memungkinkan pengembang untuk menyatakan jenis posting sebagai tidak publik. Bendera seperti 'publik', 'publik_querable' dan 'show_ui' semuanya dimaksudkan untuk memungkinkan pengembang menggunakan jenis posting untuk tujuan selain hubungan cermin sederhana 1: 1 dengan halaman publik di situs web

Bagaimana Gutenberg cocok dengan visi itu?

Saya tidak melihat solusi selain untuk membiarkan editor ini opsional, yaitu tetap harus menggantikan TinyMCE tetapi editor harus tetap opsional seperti TinyMCE opsional sekarang.

Jika kita dapat terus membuat jenis posting yang tidak mendukung editor dan kita dapat terus menggunakan metabox dalam jenis posting tersebut, saya yakin konsensus dapat dicapai lebih cepat.

Adopsi editor baru dari pengembang tema & plugin bisa menjadi lebih lambat dengan jenis pendekatan ini, tetapi sejujurnya saya tidak melihat jalan keluar lain dari ini yang tidak berarti menempuh jalan 4,9 LTS, yang akan memungkinkan proyek baru dimulai dengan WP 5.0 dan proyek lama untuk tetap menggunakan 4,9 LTS.

PEMBARUAN: ketika saya menulis komentar ini, judul utas berbeda dan kemungkinan penghentian metabox sedang dibahas (yaitu tim inti belum menjawab dengan jelas pertanyaan ini dengan tegas "tidak" seperti yang terjadi pada komentar di bawah). Di bawah skenario seperti itu, gutenberg hanya akan mendukung blok dinamis dan mengabaikan banyak kasus penggunaan lain untuk metabox, karenanya komentar saya di atas.

Setelah menghabiskan beberapa waktu membaca komentar semua orang, menurut saya kemungkinan hasil dari evolusi layar edit ini adalah menyediakan api metabox baru yang berfungsi dalam layar edit berbasis js ini. Yaitu kami tidak benar-benar kehilangan kemampuan menggunakan posting dengan cara kreatif seperti yang saya sebutkan di atas, tetapi kami hanya mendapatkan api baru untuk melakukannya dan UI akan berbasis js.

Kami berencana menggunakan Pod 2.7 untuk membangun aplikasi yang didukung React menggunakan WordPress REST API dan GatsbyJS .
Akankah Gutenberg kompatibel dengan Pod?

Saya melihat masalah penting ini telah dihapus dari pencapaian mana pun. Ini telah diprioritaskan _again_ sementara lonceng dan peluit untuk pengeditan blog mendapatkan banyak pekerjaan dan ditambahkan ke beta. Ini sangat mengkhawatirkan masa depan Wordpress sebagai CMS.

Saya membuat generator kode saya sendiri yang terinspirasi oleh GenerateWP. Untuk penggunaan pribadi dan pribadi saya di localhost, bukan untuk umum.
Bagaimanapun, saya bertanya-tanya bagaimana tampilannya di Gutenberg ketika peralihan dilakukan. Bidang ACF, banyak kode PHP khusus untuk Pratinjau.

Kami belum melupakan masalah ini. Sebaliknya, ini adalah masalah yang sangat rumit yang baru mulai kami perhatikan, bersama dengan banyak, banyak prioritas lain untuk membuat editor bekerja dengan baik.

Beberapa kesulitan yang akan kami temui saat memasang kabel metabox mungkin terlihat setelah membaca # 2251, yang juga memiliki beberapa info tentang langkah selanjutnya dari perspektif teknis.

Hal utama yang ingin saya tekankan tentang masalah ini, di sini, adalah kita membutuhkan bantuan dari masyarakat untuk merencanakan dan menguji implementasi ini.

Berikut adalah titik awal untuk melihat daftar plugin:

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

Plugin yang tidak muncul di atas, kemungkinan besar karena tidak ada di direktori plugin WP.org:

• Manajer lapangan

Jika Anda mengetahui plugin lain yang banyak digunakan yang melakukan tugas serupa, beri tahu kami di sini dalam masalah ini.

Jika Anda adalah pengembang salah satu plugin ini, dan / atau dapat memberikan detail tentang apa yang digunakan oleh WordPress hook dari plugin ini untuk menambahkan metabox mereka dan memasukkan skrip atau stylesheet terkait, beri tahu kami di sini dalam masalah ini atau buat yang baru masalah untuk setiap plugin tertentu pada daftar di atas. Informasi ini memakan waktu lama untuk dikumpulkan, dan akan sangat membantu upaya pengembangan lebih lanjut untuk memiliki semuanya di satu tempat. Sebagai contoh:

Advanced Custom Fields menambahkan metaboxnya dengan mendaftarkan hook terhadap admin_enqueue_scripts . Pengait ini memverifikasi bahwa pemuatan halaman saat ini adalah post.php atau post-new.php , dan jika demikian, menambahkan tindakan admin_head yang memanggil add_meta_box . Inti WP melakukan panggilan do_meta_boxes segera setelah tindakan itu, di edit-form-advanced.php .

Terakhir, jika Anda adalah seorang pengembang yang akrab dengan cara WordPress saat ini merender dan menyimpan metabox, masukan Anda di sini dan / atau di # 2251 sangat dihargai .

Hai kawan,
Elliot di sini - ACF dev.

ACF menggunakan tindakan admin_enqueue_scripts untuk melakukan "logika pencocokan grup bidang" dan kemudian tindakan admin_head untuk menambahkan metabox (melalui add_meta_box() ). Ini tidak menggunakan tindakan add_meta_boxes .

Dapatkah saya mengajukan pertanyaan yang jelas di sini? Mengapa kita membahas 'kesulitan' metabox? Ini adalah bagian integral dari setiap situs web WP. Tentunya logika metabox dapat tetap seperti itu dan hidup berdampingan dengan area editor Gutenberg yang baru.

Pastikan juga untuk memberi tag di @woocommerce . Mereka kemungkinan besar adalah plugin metabox terbesar.

Terima kasih
E

Hai kawan-

Saya masih merumuskan beberapa pemikiran dan gagasan tetapi saya ingin mengajukan pertanyaan singkat karena sepertinya pembahasan ini agak terlalu fokus.

Mengapa kita hanya berbicara tentang menambahkan bidang ke kotak meta? Sistem saat ini memungkinkan kita untuk menambahkan apapun. Data, javascript untuk mencapai API pihak ketiga untuk menggunakan alat mereka, tampilan cepat catatan atau informasi bantuan, dan bahkan gambar anak kucing kecil yang lucu memberi orang tos (ok, mungkin bukan yang ini, tapi siapa yang tahu kan ?!).

Poin yang ingin saya sampaikan di sini adalah bahwa kotak meta adalah wadah universal yang dapat menampung berbagai hal yang termasuk, tetapi tidak terbatas pada, bidang. Saat ini cukup mudah dengan PHP untuk melakukan ini, namun apakah saat ini kami meminta orang untuk mengetahui cara menulis Komponen React hanya untuk menambahkan, beberapa teks?

Seperti yang saya katakan, hanya mencoba menambah konteks percakapan.

Terima kasih,

Kevin - Pengembang Utama untuk Piklist

Pertanyaan ini telah disinggung dalam banyak komentar di atas namun belum terjawab sepengetahuan saya:

Apakah mungkin untuk mengganti editor posting TinyMCE yang ada dengan Gutenberg sambil membiarkan antarmuka lainnya, termasuk kotak meta dan kait yang ada, tidak berubah?

Cakupan yang dipersempit ini akan memungkinkan Gutenberg untuk disertakan atau dikecualikan dari jenis posting kustom dengan menentukan editor support saat mendaftarkan jenis posting.

• Jika editor support terdaftar, maka Gutenberg hadir di layar edit dengan kotak meta yang ada terus berfungsi seperti yang mereka lakukan hari ini di sekitar editor saat ini.
• Jika editor support tidak terdaftar, maka Gutenberg tidak dimuat dan kanvas kosong tersedia untuk meta box seperti sekarang ini.

Pendekatan ini tampaknya menghindari tantangan besar kompatibilitas mundur dengan implementasi meta box yang ada sambil membebaskan sumber daya untuk membuat editor terbaik.

Dapatkah saya mengajukan pertanyaan yang jelas di sini? Mengapa kita membahas 'kesulitan' metabox?

@elliotcondon - jika masalah dev sulit dipecahkan, satu-satunya cara untuk mendapatkan solusi adalah dengan mengatasi kesulitan tersebut. Saya sudah mulai melakukan ini di # 2251, tetapi seperti yang dijelaskan di sana, ini tidak akan menjadi tugas yang cepat atau perbaikan yang mudah.

Terima kasih telah mengonfirmasi informasi yang saya kumpulkan tentang cara ACF mendaftarkan metabox-nya. Untuk membuat lebih banyak kemajuan dalam penerapan ACF secara khusus, berikut adalah hal-hal berikutnya yang perlu diketahui:

• Skrip dan stylesheet apa yang diantrekan untuk mengontrol fungsionalitas metabox ACF
• Tindakan apa yang menyebabkan mereka mengantri
• Kondisi apa pun yang mengontrol apakah diantrekan atau tidak.

Mengapa kita hanya berbicara tentang menambahkan bidang ke kotak meta?

Saya ingin pergi ke tempat di mana kode Gutenberg tidak terlalu peduli dengan apa yang sebenarnya dilakukan oleh metabox.

Menuju tujuan itu, @kevinpmiller , berikut adalah hal-hal selanjutnya yang perlu diketahui Piklist:

• Tindakan apa yang bertanggung jawab untuk memanggil add_meta_box untuk mendaftarkan metabox
• Setiap kondisi yang mengontrol apakah mereka terdaftar atau tidak (misalnya layar saat ini adalah post.php atau post-new.php )

Dalam edisi ini, mari kita tetap fokus pada percakapan untuk membuat metabox PHP yang ada berfungsi bersama antarmuka Gutenberg.

Saat ini cukup mudah dengan PHP untuk melakukan ini, namun apakah saat ini kami meminta orang untuk mengetahui cara menulis Komponen React hanya untuk menambahkan, beberapa teks?

Ya, kita perlu mengerjakan satu set API untuk membuat metabox "gaya baru". Inilah yang kita miliki hari ini untuk blok - Saya berharap itu akan sangat mirip, dengan metabox terdaftar sebagai "blok" yang dapat menghemat tempat selain post_content : http://gutenberg-devdoc.surge.sh/

Diskusi tentang metabox gaya baru harus dilakukan di # 1684 atau masalah terpisah untuk mengusulkan API teknis.

Jika editor support tidak terdaftar, maka Gutenberg tidak dimuat dan kanvas kosong tersedia untuk meta box seperti sekarang ini.

@kevinwhoffman - Gutenberg seperti yang ditulis hari ini dimaksudkan untuk menjadi editor post_content . Jadi masuk akal jika editor support tidak diaktifkan, setidaknya untuk saat ini, kami menonaktifkannya. Ini juga merupakan tugas yang cukup mudah dari perspektif kode. Dapatkah Anda membuat terbitan baru untuk ini, dan saya akan menandainya dengan label Good First Task ?

Gutenberg seperti yang ditulis hari ini dimaksudkan untuk menjadi editor post_content .

@nylen Jika Gutenberg benar-benar dimaksudkan untuk menjadi editor post_content , maka kotak meta harus dibiarkan sendiri karena tidak terkait dengan post_content .

Selain itu, kebutuhan API untuk menerjemahkan kotak meta PHP ke dalam kotak meta React adalah masalah yang dibuat-buat. Ini tidak harus menjadi masalah, tetapi telah menjadi masalah karena di suatu tempat di sepanjang garis telah diputuskan bahwa menulis ulang editor post_content juga harus sepenuhnya mengubah cara kerja kotak meta.

Anda telah menjelaskan tantangan luar biasa dalam menulis API semacam itu di # 2251. Menerjemahkan kotak meta PHP ke dalam React untuk solusi bidang kustom populer seperti ACF cukup menantang, apalagi mencoba melakukannya untuk setiap implementasi kotak meta yang ada saat ini, populer atau tidak. Itu tidak berskala.

@kevinwhoffman -

Saya tidak ingin menarik masalah ini dari topik, tapi saya tidak mengerti mengapa perlu ada kesulitan 'metabox' saat memperkenalkan pembuat halaman JS baru. Inilah yang saya maksud ketika saya mengatakan:

Mengapa kita membahas 'kesulitan' metabox

Saya senang membacanya:

Jika dukungan editor tidak terdaftar, maka Gutenberg tidak dimuat dan kanvas kosong tersedia untuk kotak meta seperti sekarang ini.

Jika hal di atas benar, semua logika wp-admin (tindakan, fungsi, dll) harus tetap sama (ish) untuk layar edit posting. Oleh karena itu, seharusnya tidak ada alasan mengapa HTML metabox tidak dapat dirender seperti yang telah dilakukan selama bertahun-tahun.

@ ny
ACF mengantrekan beberapa file JS dan CSS untuk mengatur gaya dan berinteraksi dengan elemen HTML metabox ACF.
ACF menggunakan tindakan 'admin_enqueue_scripts' untuk menambahkan aset ini
Banyak plugin dan tema lain yang mengantre gaya / skrip - mengapa ini menjadi masalah?
ACF tidak menggunakan JS untuk menyimpan metadata. Ini menggunakan tindakan save_post untuk menyimpan data $_POST - hal yang cukup normal.

Selain itu, kebutuhan API untuk menerjemahkan kotak meta PHP ke dalam kotak meta React adalah masalah yang dibuat-buat.

Ini bukan yang kami lakukan. Ini lebih seperti: karena kita tidak lagi menggunakan proses pemuatan post.php tradisional, maka kita perlu memilih hal-hal yang kita butuhkan.

Jika dukungan editor tidak terdaftar, maka Gutenberg tidak dimuat dan kanvas kosong tersedia untuk kotak meta seperti sekarang ini.

Untuk memperjelas: Saat ini tidak demikian, tetapi akan menjadi hal yang wajar untuk dieksplorasi dalam PR. Jika Anda tertarik melihat ini berfungsi hari ini, tolong bantu, ini akan berjalan jauh lebih cepat.

@kevinwhoffman @elliotcondon @nylen Atau lebih baik lagi, bagaimana dengan:

• Jika block-editor dukungan terdaftar, gunakan Gutenberg.
• Jika editor support terdaftar, gunakan TinyMCE.
• Jika tidak ada dukungan yang tidak terdaftar, maka baik Gutenberg maupun TinyMCE tidak dimuat.

Saya tidak mendukung pemecahan pengalaman Admin WP berdasarkan ada atau tidaknya Gutenberg.

Jika Gutenberg = Kotak Meta React Baru dan Tidak Ada Gutenberg = Kotak Meta PHP Lama, maka admin yang retak adalah arah yang kita tuju.

Kotak meta harus berfungsi sama di mana pun terlepas dari apakah ada editor.

Contoh: Katakanlah saya memiliki plugin yang menambahkan kotak meta untuk menilai posting dari 5 bintang. Plugin ini dibuat agar semua jenis posting dapat dinilai. Mengapa internal meta box itu berubah berdasarkan apakah jenis posting menggunakan editor atau tidak?

@novitasari

Saya tidak mendukung pemecahan pengalaman Admin WP berdasarkan ada atau tidaknya Gutenberg.

Apakah itu tanggapan atas saran saya tentang block-editor , atau yang lainnya?

BTW, saya tidak melihat saran saya sebagai pemecahan pengalaman, saya melihatnya sebagai membangun atas saran Anda untuk menyertakan kotak meta yang ada jika ada di konfigurasi WordPress.

@mikeschinkel Kemampuan untuk mengaktifkan atau menonaktifkan Gutenberg diperlukan, tetapi gagasan tentang Gutenberg yang menentukan perilaku kotak meta adalah hal yang saya perdebatkan. Itu adalah masalah terpisah.

@kevinwhoffman Saya setuju dengan Anda, btw.

Dari Pod, kami melakukan hal-hal normal, terdokumentasi, dan standar menggunakan tindakan yang sama seperti ACF dan CMB2. Kita semua melakukannya dengan cara yang disarankan untuk dilakukan sekarang.

+1 tentang kemampuan untuk terus menggunakan kotak meta bersama Gutenberg, pada akhirnya orang-orang akan dapat menggunakan Gutenberg untuk hal-hal yang termasuk langsung dalam konten, dan untuk yang lainnya masih ada kotak meta yang mereka sukai untuk atribut dan informasi tambahan tentang "pos "(jenis apa pun).

-1 tentang keharusan menulis ulang semuanya di React, setidaknya dukung keduanya untuk waktu yang lama sampai semua orang memiliki waktu untuk merasa nyaman dengan metode React dan mendukung lebih banyak / mendapatkan kekusutan yang berhasil untuk implementasi meta box. Saya tidak berpikir ada waktu di mana kotak meta PHP harus dihapus, simpan untuk backcompat dan biarkan plugin bermigrasi saat dokumentasi kotak meta React dan keterampilan pengembang meningkat di area itu.

Setelah diskusi di tiket ini, serta percakapan publik dan pribadi yang mencakupnya, saya pikir ada satu pertanyaan kritis yang harus dijawab di sini:

Apakah WordPress bermaksud untuk menghentikan Metabox API secara resmi?

Jika jawabannya TIDAK maka keseluruhan “mari kita pindahkan dan kelumpuhkan mereka sedikit” adalah non-permulaan. Jika API tetap didukung dengan standar kompatibilitas mundur dari inti WordPress, maka harapan penuhnya adalah agar penerapan metabox yang ada hanya berfungsi. Seperti yang dilakukan di WordPress.

Jika jawabannya Ya maka ini adalah perubahan kebijakan kompatibilitas mundur yang sangat besar dan akhir era untuk pengembangan WordPress secara keseluruhan. Ini tidak hanya membutuhkan "pemecahan" metabox di Gutenberg. Ini akan membutuhkan pendidikan ulang yang sangat besar dan klarifikasi bahwa rentang bertahun-tahun pengembangan inti WordPress dilakukan dengan cara tertentu dan memberikan tingkat tertentu harapan kompatibilitas mundur sudah berakhir.

Sayangnya jawaban saat ini sepertinya tidak akan mengatakan Ya, tetapi bermaksud untuk merusak sesuatu, sambil berpura-pura bahwa itu adalah TIDAK . Secara pribadi saya merasa ini pendekatan yang sangat tidak biasa untuk fitur inti utama dan sangat mengerikan bahwa hal itu dilakukan dengan cara seperti itu.

Layar Post Edit adalah _ layar yang paling disesuaikan pada setiap proyek yang melampaui blog barebone.

Penyesuaian ini tidak terbatas pada pendaftaran metabox. Setiap pengait yang ditawarkan layar admin pengeditan sedang digunakan dalam proyek yang sama di luar sana. Dan untuk kasus-kasus yang tidak ada kaitannya, pengembang menggunakan jQuery untuk memasukkan elemen UI ke dalam halaman.

Jadi untuk kustomisasi tersebut, perlu ada jalan ke depan.

Untuk metabox, Manajer Lapangan adalah alat pilihan, karena itu disetujui VIP. Manajer lapangan sangat kuat, tetapi difokuskan pada serangkaian bidang terbatas. Basis kode lama seringkali tidak dapat dipasang kembali untuk menggunakan Fieldmanager, atau pustaka utilitas lainnya.

Jadi banyak metabox masih dibuat menggunakan kode khusus. Kode khusus berarti kombinasi PHP dan JavaScript, seringkali dengan interaksi yang didorong Ajax.

Saran untuk memasukkan semua metabox yang dibuat dengan hati-hati ini dari posisi yang diinginkan ke area di bawah editor tidak masuk akal.

Regresi apa pun dari opsi penyesuaian pada layar Edit Posting yang tersedia saat ini tidak akan dapat diterima.

Jika kode yang ada perlu diperbarui, Anda dapat menghitung 12-18 bulan sejak semua API baru diselesaikan agar pemutakhiran ini terjadi pada proyek klien. Artinya, perlu ada periode berjalan ganda, tempat API lama dan API baru hidup berdampingan.

Saya tidak mengerti mengapa Metabox harus melakukan sesuatu dengan Gutenberg sama sekali? Ini hanya satu halaman backend, layar. Bisa diatur dengan ratusan cara.
Anda mengatakan implementasi saat ini jeda React.

Biarkan pengembang memilih apakah mereka akan mengikat Metabox mereka ke Gutenberg, atau membiarkan mereka di luar.
Semua masalah ini karena Anda berasumsi bahwa setiap orang harus membuat blok Gutenberg, dengan satu atau lain cara. Bagaimana jika mereka tidak menginginkannya, tidak membutuhkannya.

Masalah besar kedua bagi saya pribadi. Saya selalu kesulitan dengan javascript, saya anti-bakat untuk bahasa ini.
Oke, tidak semuanya berputar di sekitarku, tapi hanya untuk mengatakan. Tidak akan lebih mudah untuk menambahkan Metabox daripada sebelumnya.

Saya pikir @Rarst menyimpulkan masalah ini dengan luar biasa. Komunitas membutuhkan jawaban yang jelas dan sepertinya tim pengembang cenderung mengikuti arahan deprecation tetapi tidak bisa menjelaskannya dengan jelas karena mencoba mencari solusi terlebih dahulu, yang saya hormati sepenuhnya. Kami tidak membutuhkan komunitas yang memasuki mode panik selama berbulan-bulan, tetapi pada saat yang sama komunitas yang sama perlu memiliki cukup kepala dan jalan yang jelas ke depan. Sejujurnya ini adalah kompromi yang sulit ditemukan.

@ fklein-lu Saya sangat tidak setuju Manajer lapangan harus menjadi "alat pilihan". Saya bahkan tidak melihatnya dalam daftar plugin 10 bidang teratas.
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

Seperti yang dikatakan banyak orang lain, sementara saya memahami keinginan untuk membuat metabox dan Gutenberg menjadi antarmuka yang koheren dan terhubung, mengubah cara kerja metabox memperkenalkan kerumitan luar biasa yang mungkin menjadi penghalang besar bagi orang. Sejarah telah menunjukkan kepada kita bahwa memasukkan ketidaksesuaian besar antar versi dapat sangat memecah komunitas.

Bagaimana cara menambahkan Metabox ke layar backend Dashboard?
Ini tidak ada hubungannya dengan Gutenberg.

@khromov Baca apa yang sebenarnya saya tulis, daripada salah mengutip kata-kata saya. Juga jika Anda membaca posting yang Anda referensikan, Anda akan tahu mengapa Fieldmanager tidak membuat daftar Sepuluh Teratas.

@ fklein-lu Tidak yakin mengapa menurut Anda saya salah mengutip Anda, berikut konteks lengkapnya: "Untuk metabox, Manajer Lapangan adalah alat pilihan, karena itu disetujui VIP.". Saya tidak tahu siapa pun yang menggunakan Manajer Lapangan, jadi saya kesulitan memahami kutipan itu.

Saya sadar bahwa Fieldmanager tidak ada di WPorg. Yang saya katakan adalah kami tidak memiliki data penggunaan darinya. Saya sangat meragukan itu akan menyaingi beberapa plugin teratas, dan itu juga memiliki dukungan komunitas yang sangat sedikit, selain yang menggunakannya untuk VIP, yang merupakan minoritas kecil yang menghilang dari jumlah total pengembang.

Di agensi kami, kami percaya, bahwa di 3.x WordPress melakukan langkah dari Sistem Blogging ke Sistem Manajemen Konten. Saat ini kami dapat membentuk konten sesuai kebutuhan proyek dan kami menggunakan jenis pos khusus dan kotak meta untuk membuat berbagai macam konten yang berbeda, bukan hanya teks.

Jika block-editor menjadi wajib di 5.0, kami sangat yakin bahwa ini akan menjadi langkah ideologis mundur dari CMS ke sistem blog. Ada banyak sekali aplikasi perusahaan, yang menjalankan WordPress sebagai Solusi Pemesanan Hotel, Platform Pekerjaan, CMS Tanpa Kepala untuk Aplikasi, Layanan Lokasi, dll, dan banyak dari kasus penggunaan itu bahkan editornya tidak diaktifkan.

Kompatibilitas mundur penuh dengan implementasi metabox saat ini adalah HARUS mutlak. Melanggar itu akan merusak kepercayaan dengan klien dan pengguna selama bertahun-tahun yang akan datang. Solusi favorit saya adalah sesuatu di baris ´theme_supports´ dan kegunaan bebas gangguan.

TL; DR: Jangan berharap klien perusahaan memperbarui kode mereka dalam 12 bulan ke depan untuk hal lain selain pemeliharaan. Tambahkan kebijakan / peringatan penghentian dengan garis waktu yang sesuai. Harapkan penurunan besar dalam kepercayaan di WordPress, ketika Anda memaksakan perubahan (bahkan menjadi lebih baik) dalam hal kegunaan backend dan kode.

Itu entah bagaimana menjadi politik, atau pemungutan suara / pemilihan, bukan pengkodean. Beberapa orang memutuskan Metabox tua itu "tua", "terbelakang", "membatasi", dan tidak ada lagi tempat untuk mereka. Tanpa argumen dan alasan yang nyata terhadap mereka. Saya belum melihatnya, kecuali bahwa React dan skrip lainnya adalah turbo-modern.

Saya masih mendukung Anda dalam menemukan solusi untuk membuang Metabox lama dan melakukannya seperti yang Anda bayangkan dengan cara Gutenberg. Tapi sepertinya Anda tidak tahu bagaimana mengatasinya.

Sulit untuk membahas semua ini ketika banyak yang masih lubang hitam bagi saya. Dan saya bukan satu-satunya.

Hanya untuk menyatakan seberapa objektif saya dalam hal ini, atau mencoba untuk:

• Saya masih berpikir TinyMce dan layar posting lama (dengan Metabox) adalah sesuatu yang paling indah yang pernah saya lihat di dunia CMS. Fungsi, filter, perluasan, dan desain cantik. Ya, keindahan dan kesenangan murni.
• Meski begitu, saya menerima Gutenberg sejak hari pertama. Ya, buang semua yang "tua" ini, ganti dan jangan pernah melihat ke belakang.

Mereka tahu sesuatu yang saya tidak tahu. Mereka memiliki kode. Tapi saya tidak yakin lagi.

Hal kedua, lupakan, dan sangat penting dalam konteks ini. Itu sudah disebutkan beberapa kali di sini.
Saya melakukan hal-hal sedikit berbeda dari yang lain. Alasan mengapa saya menerima Gutenberg (bagaimanapun juga salah satunya) sejak hari pertama adalah, saya pribadi tidak akan memiliki masalah apa pun untuk meyakinkan orang yang saya buat situs web untuk menggunakan Gutenberg. Ini adalah kesalahan besar ketika Anda memaksakan kepada mereka sesuatu yang sangat berbeda dari TinyMce.
Saya melakukan semua pembaruan inti plugin dan WP untuk semuanya gratis. Jadi dalam dilema ini ketika mereka harus memilih antara Gutenberg dan menghentikan pembaruan apa pun untuk sisa waktu ,. Saya pikir pilihan mereka sudah jelas,

Banyak pengembang lain, perusahaan, mengenakan biaya untuk pembaruan. Jadi dilema ini tidak akan semudah itu.

@ Khromov Saya bekerja untuk Alley, yang mengelola Fieldmanager. Kami secara aktif memantau utas sementara arah produk ditentukan. Akan adil untuk mengatakan bahwa basis pengguna WordPress.org umumnya tidak menggunakan Fieldmanager, tetapi plugin tersebut memiliki adopsi yang luas sebagai perpustakaan dan kerangka kerja khusus / perusahaan.

Saya juga ingin memberi +1 pada @Rarst dan @kevinwhoffman. Mempertahankan dukungan penuh untuk metabox yang ada masih dapat memungkinkan masa depan di mana kita mengganti metabox "warisan" dengan TBD Gutenberg yang setara. Tetapi ketidakpastian saat ini seputar kompatibilitas ke belakang harus dikurangi secepatnya.

Jumlah penginstalan plugin dari WordPress.org tidak bisa menjadi satu-satunya metrik untuk penyertaan atau pengecualian dari sebuah plugin atau pustaka. Saya mengetahui situs _single_ yang menggunakan Fieldmanager secara ekstensif, dan melayani hampir 24 juta pengunjung unik setiap bulan.

Jadi, meskipun hanya sejumlah kecil pengembang yang mungkin menggunakan plugin tertentu, mereka bertanggung jawab untuk mengembangkan dan memelihara situs yang mendapatkan jumlah lalu lintas yang tidak proporsional, dan banyak visibilitas.

Jadi mereka tidak bisa ditinggalkan dari diskusi ini. Saya menganggap bahwa tim Gutenberg di Automattic harus berkolaborasi dengan tim VIP untuk mendapatkan wawasan tentang kasus penggunaan ini.

Proyek perusahaan ini bergerak dengan kecepatan yang lebih lambat. Ada banyak pekerjaan yang dilakukan untuk mengupgrade metabox dan elemen UI lainnya yang bukan pekerjaan pengkodean yang sebenarnya. Bahkan tidak ada cukup pengembang perusahaan untuk meningkatkan semua situs ini dalam jangka waktu 5.0.

Seperti yang ditunjukkan oleh orang lain di utas ini, perlu ada jalur peningkatan yang memperhitungkan kecepatan ini. Seperti itu, perubahan dapat terjadi secara bertahap, sebagai bagian dari pekerjaan pemeliharaan proaktif.

@ fklein-lu lihat di atas, kami mendengarkan dan Anda selalu dapat menghubungi jika Anda ingin berkolaborasi dalam kode!

Mengenai VIP dan pasar perusahaan, saya berharap akan ada lebih dari beberapa percakapan tentang topik ini di WordCamp untuk Penerbit minggu depan di Denver . Karena itu, kami menghubungi Gutenberg devs & @m tetapi AFAIK tidak ada yang dapat hadir.

Mengenai timeline "5.0", pada titik ini para insinyur perusahaan yang saya wawancarai berasumsi akan ada jalur penyisihan yang cukup mudah untuk menggunakan editor dan metabox TinyMCE yang ada. Percayalah bahwa tim Gutenberg telah memberikan 👍 pada asumsi ini juga.

Dan saya memiliki satu situs web yang menggunakan Jetpack dan hanya memiliki 2 pengunjung unik per hari.
Berhentilah bersikap begitu mudah tersinggung. Ini WordPress, bukan diskusi tentang versi baru Joomla. :)

@ fklein-lu Sepenuhnya setuju dengan Anda. Tapi jika ada yang menjadi "alat pilihan" untuk bidang metabox, saya pikir itu akan menjadi API Bidang yang diusulkan.

@davhaver Saya pikir itu adalah hal yang bijaksana untuk dilakukan. Jika WordPress mencoba untuk memperkuat pendekatan deprecation tanpa kompatibilitas mundur, saya dapat dengan mudah melihat seseorang memindahkan potongan kode lama ke dalam sistem "paralel", posting alternatif & metabox berbasis lama dan mengemasnya sebagai plugin atau sesuatu seperti itu. Secara pribadi itu adalah hal terakhir mutlak yang saya harap bisa terjadi. Sekali lagi, ini pasti semua kerja keras untuk dilakukan, jadi saya berharap semoga sukses untuk semua orang yang terlibat dengan membawa komunitas WordPress ke negeri baru yang belum dijelajahi ini.

Terima kasih semuanya telah ikut serta dan mengungkapkan keprihatinan dan gagasan. Ini menjadi utas yang panjang, tetapi saya akan mencoba menjelaskan beberapa poin.

Apakah WordPress bermaksud untuk menghentikan Metabox API secara resmi?

Tidak.

Pertanyaan yang belum sepenuhnya terjawab adalah _bagaimana cara kerja kotak meta dalam konteks editor gutenberg_. Haruskah mereka tetap sama atau berkembang? Bagaimana kita bisa bergerak menuju tujuan desain dengan gangguan sesedikit mungkin?

Masalah ini tetap ada bukan karena kurangnya keinginan, tetapi karena kurangnya sumber daya. Fokus utama proyek ini adalah menawarkan antarmuka pengeditan konten lengkap yang mengoptimalkan manipulasi langsung konten pengguna melalui gagasan blok. (Setelah menggunakan meta-box secara ekstensif untuk berbagai proyek, saya percaya blok dapat menawarkan langkah maju yang lebih baik untuk banyak dari kebutuhan tersebut sambil memberikan pengalaman pengguna yang lebih baik.)

Namun, ada banyak cara di mana meta-box dan ekstensibilitas dapat ditangani:

• Jika kami mendeteksi meta-box terdaftar, kami dapat kembali ke antarmuka lama, tidak ada yang berubah.
• Kami dapat membagi pengeditan konten dan mengubah informasi meta menjadi dua layar atau tahapan.
• Kami dapat mencoba untuk melihat seberapa layak untuk merender ini sebagaimana adanya (PHP) di bawah konten: # 2251.
• Tema / plugin / CPT dapat membatalkan pendaftaran antarmuka baru sesuai kebutuhan.
• Berbagai item yang mengandalkan meta-box dapat diubah menjadi blok untuk UI (masih menyimpan data secara terpisah).
• Kita bisa mengimplementasikan ekstensibility meta-box berbasis API seperti Fields API.

Atau kombinasi dari semuanya.

Kami sangat menghargai bantuan apa pun dari komunitas dalam membangun solusi terbaik di sini karena, sekali lagi, kurangnya kepastian bukanlah kurangnya kemauan; hanya saja solusi yang mungkin perlu dieksplorasi dalam praktik dan pengorbanan — desain dan pengembangan bijaksana — ditulis dengan jelas.

Tidak.

Terima kasih , saya rasa banyak orang yang baru saja menghembuskan napas.

Pertanyaan yang belum sepenuhnya terjawab adalah bagaimana cara kerja meta-box dalam konteks editor gutenberg.

Mengapa _are_ kotak meta dalam konteks editor Gutenberg?

Jawabannya tampaknya Gutenberg bertujuan untuk mengganti seluruh editor pos _screen_ dengan implementasi yang digerakkan oleh JS. Saya tidak mengikuti perkembangan untuk menyadari alasan untuk itu.

Tapi saya masih berpikir itu adalah poin yang sangat valid yang diangkat - jika cakupan Gutenberg adalah menjadi komponen editor, maka mengganti cakupan _screen_ tampaknya terlalu ambisius. _Jika_ ruang lingkup Gutenberg adalah (setidaknya sebagian) pengganti WordPress _admin_ secara keseluruhan, itu _sangat luar biasa_ cakupannya lebih luas dan menuntut. Bukan berarti mengganti editor "hanya" itu mudah.

Namun, ada banyak cara di mana meta-box dan ekstensibilitas dapat ditangani

Gutenberg memiliki cakupan untuk mengganti komponen _editor_ utama dan UI admin yang ada terus berfungsi? Apakah _ini_ dipertimbangkan, jika tidak, mengapa demikian?

Saya hanya dapat berbicara untuk plugin manajer lapangan yang saya buat dan yang saat ini kami gunakan di lebih dari 60 proyek berbeda saat ini. Saya akan secara singkat menyebutkan apa arti perubahan ini untuk itu dengan harapan ini dapat membantu siapa pun memikirkan skenario mereka sendiri.

Karena saya mengalami kesulitan untuk membangun arsitektur yang sangat terpisah dengan kelas dan antarmuka abstrak yang umum, yang harus saya lakukan adalah menambahkan "lokasi" baru. Inilah komponen arsitektur yang relevan dengan poin saya:

• Lokasi: di mana grup bidang dilampirkan (misalnya, posting, halaman, istilah taksonomi, dll.), Dengan varian untuk setiap lokasi (misalnya, Lokasi Posting dan Pengaturan berfungsi dengan kotak meta). Kelas ini membuat instance semua bagian bergerak yang disebutkan di bawah ini
• Penyimpanan data lokasi: lapisan yang bertanggung jawab untuk mengambil dan menyimpan data, dengan varian untuk setiap lokasi (misalnya, posting DataStore berfungsi dengan meta posting, Pengaturan berfungsi dengan opsi, dll.)
• Tampilan lokasi: bila diperlukan, seperti halnya halaman pengaturan, ini adalah kelas View yang menyimpan template dan fungsi pembantu apa pun

Sekarang, dalam konteks Gutenberg, jika saya mendukung editor baru ini, yang harus saya lakukan secara pribadi adalah menambahkan lokasi baru, yang disebut Gutenberg, dan lokasi ini akan memiliki:

• Metode inisialisasi sendiri yang akan menghubungkannya ke editor Gutenberg. Saya membayangkan ini sebagian besar akan berbasis javascript, jadi perpustakaan saya akan mendaftar dan memuat skrip umum yang diperlukan untuk tujuan ini.

• View / template-nya sendiri: Saya harus membuat komponen react untuk setiap jenis bidang. Ini bukan masalah besar, lapisan tampilan cukup mudah dibuat ketika semua bagian lainnya disiapkan dengan benar. Komponen ini kemudian akan disarangkan ke dalam komponen reaksi metabox. Ini semua sangat mirip dengan apa yang sudah saya lakukan untuk metaboxes html berbasis php, yaitu bidang html> grup bidang html> lokasi (halaman pengaturan html, metabox dll.)

• Kelas penyimpanan datanya sendiri. Saya tidak membayangkan kelas ini akan sangat berbeda dari penyimpanan data lokasi posting, karena ini akan berbasis meta posting (saya membayangkan tidak ada yang berpikir untuk mencela meta posting dalam waktu dekat).

• Potongan baru: titik akhir. Komponen berbasis react baru ini harus dapat berbicara dengan penyimpanan data untuk mengambil dan mempertahankan nilai. Karena ini benar-benar hidup di sisi klien, mereka akan membutuhkan titik akhir sebagai jembatan untuk berbicara dengan penyimpanan data lokasi, dengan penyimpanan meta untuk mengambil komponen yang akan dimuat dalam konteks apa pun, dll.

Jika saya tidak melewatkan sesuatu yang besar (saya akui, saya belum punya waktu untuk memeriksa Gutenberg) ini kurang lebih adalah inti dari apa yang menurut saya harus saya lakukan untuk mendukung "lokasi" baru ini secara asli. Saya juga memiliki pemeriksaan bawaan untuk setiap lokasi dan filternya untuk memastikan apa yang diminta pengembang adalah mungkin, misalnya jika saya mencoba menambahkan grup bidang ke jenis posting "proyek" di mana format jika jenis posting adalah "video ", tetapi CPT itu tidak mendukung format posting, perpustakaan akan mengeluarkan pengecualian. Saya harap saya dapat memberikan tanggapan yang sama dengan lokasi baru ini, misalnya jika saya menambahkan grup lapangan ke lokasi Gutenberg di mana jenis posnya adalah "ulasan", saya harap saya dapat mengetahui jenis pos tersebut. terdaftar untuk mendukung Gutenberg.

Ini akhirnya menjadi sedikit lebih lama dari yang saya perkirakan, salah saya. Saya ingin mendengar kembali dari siapa pun yang terlibat dalam pengembangan Gutenberg atau penulis perpustakaan mana pun yang memiliki perhatian serupa yang memiliki umpan balik untuk dibagikan.

Terima kasih.

Gutenberg memiliki cakupan untuk menggantikan komponen editor utama dan UI admin yang ada terus berfungsi? Apakah ini sedang dipertimbangkan, jika tidak mengapa demikian?

Gutenberg memang memulai hanya dengan kotak editor. Tujuan awal adalah untuk menyatukan beberapa antarmuka yang berbeda di bawah satu antarmuka blok terpadu. Dengan cepat menjadi jelas bahwa untuk menciptakan pengalaman menarik yang berputar di sekitar antarmuka blok terpadu ini, kami harus mempertimbangkan alur penulisan lengkap, termasuk pengaturan dan penerbitan.

Jika kekuatan utama WordPress adalah memudahkan siapa saja membuat rich post, maka kita tidak bisa begitu saja mendesain untuk kita yang sudah tahu cara menggunakan editor. Kami harus mempertimbangkan pengguna yang belum pernah menggunakan WordPress sebelumnya, dan apa yang mereka harapkan dalam antarmuka penerbitan modern. Jika tidak, kami hanya akan menambahkan beban kognitif ke antarmuka yang sudah berat.

Kami belum selesai, dan itu tidak mudah, tetapi kami mengerjakannya setiap hari.

☝️ Saya telah memperbarui judul dan deskripsi tiket untuk mengatasi beberapa kesalahpahaman.

Editor Gutenberg baru dan masa depan ButterBean

Seperti yang diminta dalam komentar di atas , saya mencantumkan kerangka kotak meta ButterBean. Saya bisa membuat tiket baru jika perlu.

Repo: https://github.com/justintadlock/butterbean/tree/dev

Untuk tujuan pengujian, kerangka kerja disertakan dalam plugin ini: https://github.com/justintadlock/custom-content-portfolio

ButterBean adalah kerangka kerja drop-in yang dibangun dengan Backbone.js dan Underscore.js. Itu sangat dimodelkan dari penyesuai di inti WP.

Ini adalah kerangka kerja yang masih muda, tetapi ini adalah salah satu yang telah saya rencanakan untuk diterapkan ke beberapa plugin tahun ini. Saat ini, saya dan yang lainnya ragu-ragu untuk melakukan ini karena arahan Gutenberg. Dan, saya bahkan tidak yakin apakah saya seharusnya tidak memulai kembali dari awal di React atau kerangka kerja JS apa pun pada akhirnya diputuskan untuk ditambahkan ke inti WP berikutnya.

Pengait digunakan

Berikut ini adalah inti utama WP hook yang digunakan (cukup standar untuk kebanyakan kerangka meta box, saya bayangkan):

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

Dibuat # 2265 untuk mendokumentasikan kait yang relevan untuk CMB2.

Menambahkan label Desain untuk mendorong orang menambahkan mock-up tambahan.

Secara umum, saya merasa bahwa data yang bukan merupakan bagian dari konten yang ditampilkan seharusnya tidak menjadi bagian dari area editor utama. Tidak semuanya satu blok.

1) Mayoritas kotak meta kustom saya dibuat dengan Fieldmanager . Di mata saya, ini harus "Hanya Bekerja" tanpa pekerjaan tambahan yang diperlukan selain memperbarui. cc / @mboynes dan @bcampeau karena mereka mungkin dapat memberikan nilai pada diskusi ini.

2) Beberapa kotak meta kustom kami adalah campuran jQuery dan PHP. Misalnya, kami memiliki kotak meta "Satu atau tidak ada" yang merupakan radio dengan tombol "hapus". Dengan asumsi bahwa ini akan rusak, saya berharap akan ada contoh bagaimana saya membuat ini di Gutenberg dan akan ada banyak waktu bagi saya untuk meningkatkan ke versi WordPress yang mengamanatkan Gutenberg sebelum kode saya rusak.

3) Saya memiliki metabox lain yang menggabungkan beberapa kode jQuery dan PHP yang menonaktifkan tombol terbitkan hingga pilihan telah dibuat. Mirip dengan contoh kedua saya, dengan asumsi bahwa ini akan rusak, saya berharap akan ada contoh bagaimana saya membuat ini di Gutenberg dan akan ada banyak waktu bagi saya untuk meningkatkan ke versi WordPress yang mengamanatkan Gutenberg sebelumnya kode saya rusak.

4) Saya telah menghapus kotak meta kategori di masa lalu dan menggantinya dengan: 1) radio pilih 2) Versi A tanpa kemampuan untuk menambahkan kategori baru (ini bodoh).

5) Saya telah menggunakan post_submitbox_misc_actions untuk menambahkan opsi ke metabox terbitkan yang tidak perlu berada di metabox mereka sendiri.

Sejauh yang saya maksud dengan jumlah waktu yang signifikan, saya akan mengatakan ~ 2 tahun dari titik Gutenberg API dibekukan.

Sementara kita melakukannya, saya ingin mengingatkan semua orang di sini bahwa tidak semua orang hanya menggunakan metabox untuk memperluas layar posting. Beberapa dari kami juga menggunakan pengait berikut:

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

Saya hanya ingin menanyakan apa yang dikatakan edit_form_[POSITION] hooks. Piklist sering menggunakan meta-box, alur kerja, dan hal-hal lain.

Terima kasih sekali lagi untuk waktu kalian.

Pertanyaan apakah Gutenberg adalah pengganti editor atau pengganti layar penting untuk dijawab sesegera mungkin tidak hanya bagi mereka yang peduli dengan kompatibilitas ke belakang tetapi juga bagi mereka yang mengembangkan Gutenberg. Jawaban atas pertanyaan itu memengaruhi banyak keputusan yang dibuat setiap hari mengenai bagaimana Gutenberg bekerja dan di mana kendali berada.

Sudah jelas sejak beta pertama bahwa kami sudah berada di jalur penggantian layar, tetapi keputusan untuk merombak layar itu juga yang menciptakan masalah dukungan kotak meta dan kait yang hilang. Jika jawaban untuk masalah ini adalah "jangan mengganti seluruh layar" maka saya khawatir banyak pekerjaan yang telah dilakukan dengan asumsi penggantian layar sehingga akan sulit untuk kembali.

Pertama, senang melihat kemajuan nyata dalam hal ini.

Satu pengamatan adalah bahwa ekstensi layar edit jarang berfungsi secara terpisah. Misalnya, ACF mengubah bidang yang terlihat berdasarkan peristiwa perubahan JS pada kotak pilih induk pos.

Mengingat bahwa DOM akan berbeda dalam konteks Gutenburg, dan React kemungkinan kurang cocok untuk pendengar acara eksternal, bagaimana kami terus menyediakan data ini untuk metabox dan kode plugin lainnya. Salah satu kemungkinannya adalah toko Redux tersedia untuk metabox, tetapi saya tidak tahu apakah ini mungkin, diinginkan, atau memberikan cukup fleksibilitas.

Ini menjadi lebih bermasalah ketika metabox dimuat dalam iframe, atau ajax ke halaman.

Sudah jelas sejak beta pertama bahwa kami sudah berada di jalur penggantian layar, tetapi keputusan untuk merombak layar itu juga yang menciptakan masalah dukungan kotak meta dan kait yang hilang. Jika jawaban untuk masalah ini adalah "jangan mengganti seluruh layar" maka saya khawatir banyak pekerjaan yang telah dilakukan dengan asumsi penggantian layar sehingga akan sulit untuk kembali.

Saya benar-benar mengerti berapa banyak pekerjaan yang telah dilakukan untuk pendekatan penggantian "layar". Tetapi sebuah proyek yang dimulai dengan tujuan sebagai pengganti "editor konten posting", seharusnya tidak kembali ke komunitas sebelum memutuskan secara sepihak bahwa itu akan menggantikan seluruh layar editor?

Saya tidak bermaksud mengabaikan pekerjaan besar yang telah dilakukan (editornya benar-benar terlihat luar biasa), tetapi terlalu banyak WordPress bergantung pada bidang meta yang tidak sepenuhnya "konten", dan banyak di antaranya tidak muat sama sekali di dalam wadah Gutenberg yang sama (kecuali jika benar-benar dipaksa). Bagi saya, tampaknya lebih seperti "kami memiliki solusi dan perlu membuat masalah untuk itu" daripada sebaliknya, yang merupakan pernyataan asli Gutenberg (editor konten posting cukup berantakan, kode pendek adalah segalanya kecuali ramah untuk digunakan - meskipun pendekatan seperti Shortcake -, dll).

Maket @brentjett dari tanggal 4 Juli tampaknya menjadi sesuatu yang dapat berfungsi baik untuk "metabox yang dirubah" yang tidak sesuai dengan konten ("area pengaturan") dan kotak meta yang dapat dengan mudah diubah menjadi blok Gutenberg (informasi acara).

@rilwis Saya pikir Anda harus mampir dan menyebutkan penggunaan Metabox secara ekstensif di plugin Anda. Karena saya menggunakannya di sebagian besar produk saya, saya menganggapnya sebagai kerangka kerja yang ekstensif. Bagaimana bisa cocok dengan semua hal Gutenberg ini? - Wawasan dari seseorang yang bisnisnya menjual plugin untuk membuat metabox (yang akan paling terpengaruh) akan berguna di sini.

Untuk inspirasi desain, Anda dapat memeriksa tema Admin backend gratis dan komersial (tangkapan layar). Atau platform lainnya.

Dasbor, tapi bayangkan Gutenberg:

Mungkin Fields API yang diusulkan akan menyelesaikan beberapa masalah seputar mendukung metabox di editor baru

Skenario yang harus kita pertimbangkan adalah apa yang terjadi ketika WordPress diperbarui dengan Gutenberg dan plugin yang menerapkan kotak meta tidak .

Ini adalah "skenario kasus terburuk" yang menimbulkan ancaman terbesar bagi merusak pengalaman admin, tetapi bukan hal yang aneh mengingat jumlah situs yang didukung oleh plugin kotak meta termasuk pemain besar dan solusi khusus satu kali.

Mengandalkan plugin kotak meta ini untuk diperbarui tidak boleh menjadi bagian dari persamaan kecuali kami bersedia mengakui perubahan yang melanggar skala besar. Fields API adalah ide yang bagus, tetapi kita tidak boleh berasumsi bahwa memperbaiki cara penanganan bidang khusus di masa mendatang akan berdampak pada kode yang ditulis sebelum API semacam itu ada.

Jelas bahwa:

• Kami tidak akan merusak kompatibilitas mundur dalam skala besar.
• Kami tidak akan membagi dua halaman editor menggunakan beberapa mekanisme deteksi.
• Kami akan memiliki satu editor dan pengalaman mengedit.
• Ada banyak kasus penggunaan di atas yang tidak dapat diakomodasi oleh implementasi Gutenberg saat ini.

Karena itu:

Cara selanjutnya adalah memikirkan ulang layar edit posting dengan cara yang baru dan lama. Itu sangat mungkin berarti mundur dari implementasi Gutenberg saat ini dalam beberapa cara. Ini adalah tantangan desain, bukan akhir dunia.

@dmccan Tidak, pernyataan tersebut tidak "jelas" karena setiap solusi yang diusulkan sejauh ini juga:

• Membagi pengalaman admin antara baru / lama.
• Mengandalkan pembaruan plugin untuk memblokir kotak meta mereka.
• Mengandalkan Fields API yang tidak ada.
• Memerlukan antarmuka baru untuk dibatalkan pendaftarannya untuk menghindari masalah sama sekali, yang sekali lagi akan membagi pengalaman admin.

Saya tidak menekankan skenario terburuk menjadi melodramatis; Saya melakukannya untuk menentukan batasan di mana kita harus mendekati masalah.

Jadi sepertinya Gutenberg harus tetap menjadi plugin fitur untuk waktu yang lama, yang orang dapat memilih untuk memilih jika mereka suka atau memilih keluar jika tidak, bahkan mungkin untuk dimasukkan sebagai plugin dengan inti.

Memecahkan semua masalah yang perlu dipecahkan agar memiliki pengalaman editor tunggal akan memakan banyak waktu kalender. Lihat saja ASP.NET asli Microsoft dan seberapa buruknya memecahkan masalah web umum. Akhirnya AJAX muncul dan sisanya adalah sejarah.

Memaksakan perubahan terlalu cepat dapat mengakibatkan WordPress menjadi platform yang hanya dapat digunakan untuk warisan.

PS Persyaratan "editor tunggal" tampaknya tidak realistis. Jika pengguna memiliki pilihan untuk menggunakan yang lama atau yang baru, maka yang baru dapat diizinkan untuk berkembang seiring waktu sampai tidak ada lagi manfaat untuk menggunakan yang lama. Tetapi selama ada instalasi yang menggunakan hook yang ada _ (saya yakin) _ tidak bertanggung jawab untuk menggunakan solusi editor tunggal. #jmtcw

@kevinwhoffman - Saya pikir kami setuju, tapi mungkin saya tidak cukup bertele-tele.

Saya pikir poin-poin saya jelas dan solusi akhir akan merangkulnya. Misalnya, saya tidak percaya bahwa WordPress akan merusak kompatibilitas mundur dalam skala besar, terlepas dari apa yang mungkin diusulkan oleh orang-orang yang mencari solusi pada saat ini.

Solusi yang diusulkan sejauh ini kurang, di situlah kesimpulan saya, bahwa kita perlu memikirkan kembali implementasi Gutenberg saat ini untuk merangkul yang baru dan yang lama, masuk. Saya pikir melakukan itu adalah satu-satunya jalan ke depan.

@mikeschinkel - Saya tidak membayangkan bahwa Gutenberg akan menjadi satu-satunya opsi editor di Core pada tahun 2017. Bisa jadi ini dimulai sebagai pilihan pengguna dan berkembang ke titik yang mencakup semua basis penting, atau dibutuhkan waktu untuk melakukannya dengan benar.

Bagaimanapun, yang saya sarankan adalah kemunduran untuk memasukkan Gutenberg dalam beberapa versi yang ditingkatkan dari layar editor saat ini, daripada membuang semuanya dan kemudian bertanya-tanya bagaimana kami dapat menangani semua fungsi penting. Saya pikir itu bisa dilakukan dan mungkin bukan kemunduran yang besar, begitu orang menyadarinya. Kursus seperti itu kemungkinan besar akan lebih cepat dan memberikan pengalaman pengguna akhir yang lebih baik.

Mungkin mereka (pembuat kode inti) harus berbicara dengan Matt. Dia memulai semua ini dan sekarang mereka tidak punya jawaban.

@dmccan Satu hal yang saya percaya akan sangat penting adalah bahwa apa pun yang diterapkan memiliki model ekstensibilitas yang mudah. WordPress dikenal dengan model ekstensibilitasnya yang mudah dengan tindakan plugin dan kait filter dan tanpanya Gutenberg akan sama buruknya dengan WordPress seperti sistem manajemen media saat ini yang sangat sulit untuk diperluas.

Sebagai catatan tambahan, sementara saya tidak pernah menggunakan React atau Vue _ (Saya seorang pengembang PHP) _ diskusi tentang React membutuhkan sistem build dan banyak orang menganggap Vue lebih mudah digunakan daripada React yang menyebabkan saya menjadi sangat cemas. apakah Gutenburg akan memiliki model ekstensibilitas yang mudah dipelajari dan digunakan atau tidak, dan apakah itu berarti kita dapat terus menggunakan WordPress untuk proyek klien.

Sekadar tanggapan saya untuk mencatat perhatian saya, tidak perlu membalas langsung ini.

Saya rasa saya tahu tentang apa semua ini.
Ini tidak pernah tentang editor konten, tidak pernah tentang "alur penulisan", "melanggar dengan yang lama .... mundur" dll ...

Ini tentang editor tema visual front-end totok.

Maaf telah mengirim email kepada Anda semua. Komentar terakhir saya tentang masalah khusus ini.

@Rarst @kevinwhoffman : Saya sepenuhnya bersama Anda tentang apakah Gutenberg adalah pengganti editor atau pengganti layar . Itu adalah poin yang dipikirkan dengan baik. Dan saya berharap tim pengembang dapat kembali ke titik awal dan sifat Gutenberg - seorang editor, dan mempertahankan yang lainnya seperti sekarang. Mereka adalah 2 bagian yang berbeda dan dapat digunakan dengan atau tanpa satu sama lain. Jadi lebih baik menyimpannya sebagai hal yang terpisah.

Selain itu, saya membuat # 2308 untuk membuat daftar kait yang relevan dari plugin Meta Box.

@ahmadawais Terima kasih atas perhatiannya.

@nylen Akan sangat berguna untuk menambahkan Posting 2 Posting ke daftar plugin untuk dipertimbangkan. Meskipun tidak lagi didukung, saya berharap masih cukup banyak digunakan.

@nylen Saya memelihara plugin saya Bidang Kustom Pengembang tetapi tidak lagi dikembangkan secara aktif (saya menggunakan CMB2 hari ini). Hanya 1000+ pemasangan aktif tetapi mungkin layak ditambahkan ke daftar.

Saya setuju dengan komentar tentang Editor Gutenberg hanya itu, bagian pengeditan konten. Tidak yakin mengapa atau bagaimana itu dialihkan menjadi pengganti layar yang lengkap. Semua pembuat halaman populer di luar sana melakukannya dengan benar, cukup ganti TinyMCE dengan sesuatu yang lain yang membuatnya lebih mudah untuk menulis konten.

Selain itu, kotak meta biasanya bukan bagian dari konten, dan meskipun terkait konten, biasanya masih tidak masuk akal untuk dicekal.

Ambil direktori staf misalnya. Mengapa saya ingin bidang untuk informasi orang menjadi blok? Ini tidak seperti Anda ingin mereka menambahkan blok lain ketika mereka seharusnya memasukkan Nama Depan, Nama Belakang, dll ...

tldr; Gutenberg sebaiknya hanya mengganti editor TinyMCE untuk jenis posting yang membutuhkan komposisi konten.

Hanya menambahkan dua sen saya di sini.

Mengapa tidak membiarkannya seperti sekarang? Yang saya maksud adalah ini.

• Pertahankan dua opsi edit saat mengarahkan kursor ke judul posting seperti sekarang, tetapi ubah jadi secara default mengklik judul akan membawa Anda ke Gutenberg. Kemudian minta tautan Edit pergi ke Gutenberg dan dapatkan tautan tambahan ke layar edit kelas. Mungkin menyebutnya sesuatu seperti Classic Edit .
• Tambahkan beberapa jenis bendera dukungan untuk jenis posting Posting dan Halaman, sehingga Gutenberg dapat dinonaktifkan jika pengembang ingin melakukan itu. Jika Gutenberg tidak diaktifkan, arahkan tautan judul ke halaman edit "klasik", hapus tautan Edit ke Gutenberg dan teks tautan Classic Edit akan berubah menjadi Edit
• Kemudian dengan jenis posting kustom memiliki dukungan Gutenberg seperti untuk Editor, Gambar Unggulan, dll. Dengan cara itu CPT tidak harus mendukung Gutenberg.
• Kemudian perbarui gaya halaman edit klasik. Memperbarui kotak meta dan gaya bilah sisi agar sesuai dengan gaya Gutenberg. Bahkan pindahkan meta box kutipan dan komentar ke sidebar seperti di Gutenberg.

Saya pikir ini akan membuat semua orang bahagia. Gutenberg akan aktif secara default untuk jenis posting Posting dan Halaman. Jika pengembang perlu menggunakan kotak meta, bukan Gutengerg, mereka bisa. Ini akan memberi plugin dan pengembang tema waktu untuk mengonversi ke Gutenberg dan itu akan memberi pengguna akhir kemampuan untuk menyesuaikan diri dengan Gutenberg tanpa mengganggu alur kerja mereka oleh perubahan editor.

Dan itu akan memberi waktu kepada para pengembang untuk mulai menjual gagasan menggunakan Gutenberg kepada pengguna akhir. Orang cenderung tidak menyukai perubahan. Membiarkan mereka terbiasa dengan editor baru akan jauh lebih baik daripada sekadar perubahan yang sulit.

Ini juga akan memisahkan keduanya yang akan memungkinkan dua metode penyimpanan yang berbeda. Gutenberg bisa menggunakan JS dan klasik tetap bisa menggunakan PHP.

Saya akan menambahkan beberapa jenis peringatan seperti jika pengguna menyimpan posting dengan Gutenberg kemudian mencoba mengeditnya dengan klasik untuk memberi tahu mereka bahwa jika mereka menyimpan posting itu akan menimpa penyimpanan posting sebelumnya dari editor lain. Mungkin ada sesuatu seperti meta posting untuk menunjukkan editor mana yang terakhir digunakan.

Itu sebuah ide. Ini mungkin ide yang bodoh, tapi saya pikir itu akan mengurangi semua kekhawatiran yang dimiliki banyak developer.

Saya sangat setuju dengan poin-poin yang dikemukakan banyak orang tentang ruang lingkup Gutenberg hari ini. Proyek ini pertama kali dimulai sebagai peningkatan (yang sangat dibutuhkan) pada editor konten. Membaca utas ini, saya tidak bisa tidak merasa bahwa kami sedang menciptakan masalah yang tidak perlu ada . Jika kami tetap berpegang pada rencana awal untuk menambahkan Gutenberg ke editor (tidak mengganti layar penuh) maka ini menyelesaikan begitu banyak masalah, tidak hanya terkait Kotak Meta.

Dengan sepenuhnya mengubah layar, saya khawatir ini akan menyebabkan begitu banyak masalah bagi editor konten non-teknisi. Rata-rata blogger / penulis akan melihat layar dan kepanikan yang sama sekali berbeda. Jika pembaruan hanya menargetkan editor, pengalaman orientasi bisa lebih terkontrol.

Cara lain untuk mendekati ini mungkin menggunakan alur kerja yang sama seperti Beaver Builder . Yaitu menjaga halaman edit posting normal (dengan bagian Kotak Meta biasa dll) maka Gutenberg dapat diluncurkan melalui tombol. Ini kemudian dapat membawa Anda ke layar baru. Mirip dengan komentar tentang penargetan mode Penulisan Bebas Gangguan.

Saya juga setuju dengan orang yang menyarankan untuk mempertahankan UI kotak meta yang ada dan hanya mengubah editor konten.

Saya rasa sebagian besar dari kita menyadari bahwa faktor utama dalam mendorong platform ke depan adalah berinovasi. Jelas bahwa WordPress perlahan-lahan mencoba untuk bergerak menuju pendekatan berbasis JS untuk pengalaman yang lebih kaya yang dapat menyamai (dan melampaui!) Apa yang dilakukan orang lain. Jika kami jujur, seluruh sistem metaboxes dan UI layar edit saat ini dapat terasa agak kuno, tetapi sebagai pengembang kami sudah terbiasa dengannya sehingga itu adalah sifat kedua bagi kami dan kami gagal memperhitungkan seberapa banyak kurva pembelajaran di sana untuk itu.

Membaca seluruh utas ini menjelaskan dua hal bagi saya:

• Jelas bahwa tim inti memang ingin mendorong layar edit berbasis js sepenuhnya, dan imho tidak apa-apa
• Mungkin jika kita semua dapat menerima poin di atas, kita dapat mengarahkan percakapan ke arah dukungan warisan dan strategi migrasi

Segera setelah kami memahami bagaimana versi js dari metabox pada akhirnya akan berfungsi (apakah ada API yang diusulkan?), Kami akan dapat mulai memikirkan tentang cara membuat jembatan yang membuat teknologi kami yang ada (plugin, pengelola bidang, dll.) bekerja dengan pendekatan baru ini.

Jika diskusi terfokus API sudah terjadi, dapatkah seseorang mengarahkan saya dan siapa pun yang tidak tahu di mana itu terjadi ke arah yang benar? Terima kasih!

Apakah ada alasan untuk tidak membagi editor menjadi dua layar dengan navigasi tab?

Pandangan saya adalah bahwa Gutenberg adalah,

• Upaya untuk merapikan layar editor
• Upaya untuk menambahkan fungsionalitas pembuat halaman / tata letak ke inti
• Upaya untuk meminimalkan kebutuhan metabox dengan mempermudah pengembang membuat blok konten baru.

Masalahnya, seperti yang disorot di atas dan seperti yang dapat dirasakan dan diramalkan oleh sebagian besar dari kita, pengembang dan pengguna akhir, adalah Gutenberg,

• Menghapus pilihan format gaya editor dari penulis
• Memaksa penulis untuk menggunakan alur kerja yang tidak intuitif yang membutuhkan banyak klik mouse untuk menambahkan blok
• Merusak banyak plugin lama, beberapa di antaranya dipertahankan dan beberapa tidak.
• Mengubah WordPress menjadi platform yang terasa seperti Tweet.

Menggunakan Guttenberg untuk membuat konten memiliki kecanggungan yang sama seperti mendesain template email di Mautic atau MailChimp. UI Guttenberg akan bekerja dengan baik untuk desain template tetapi tidak untuk pembuatan posting berformat panjang.

Kita harus berkonsentrasi pada peningkatan fluiditas alur kerja, bukan pengenalan UI pembuatan konten stop-start.

UI untuk Guttenberg tampak hebat tetapi tidak realistis untuk mengharapkan pengguna akhir senang dengannya sementara itu mendekati bentuknya saat ini. Itu menghalangi pembuatan konten.

Blok teks di samping tidak berguna. Widget teks tidak boleh membatasi penulis untuk hanya menggunakan beberapa format font. Ini akan mengganggu banyak penulis.

Inilah saran saya:

• Perkenalkan Tabify Edit Screens ke editor halaman.
• Pindahkan metabox ke tab halaman mereka sendiri di dalam layar editor.
• Gunakan halaman berbasis non-React untuk metabox (halaman tersembunyi di balik tab editor)
• Gunakan kanvas berbasis TinyMCE default (atau editor kaya fitur yang serupa) yang berfungsi dengan baik untuk format panjang dan tidak memaksa penulis untuk menggunakan blok.
• Memperkenalkan Guttenberg Blocks sebagai tambahan untuk TinyMCE atau TinyMCE yang mirip.
• Perkenalkan Shortcake ke editor berbasis TinyMCE sehingga penulis dapat melihat konten blok secara visual sehingga penulis dapat mengedit konten secara langsung di alur halaman tanpa perlu mengklik tombol edit untuk setiap blok.
• Permudah pengembang untuk menambahkan blok baru ke Guttenberg dengan mengikat add_shortcode () ke dalam pembuatan blok misalnya add_shortcode ('tag', 'function', 'guttenberg true / false'). Sesuaikan add_shortcode sehingga secara otomatis membuat shortcode kompatibel dengan Guttenberg; ini akan memungkinkan pengembang untuk dengan mudah mengubah beberapa / banyak dari metabox mereka ke shortcode yang bekerja di dalam Guttenberg.

Apa yang sebenarnya saya katakan adalah bahwa Guttenberg perlu dibagi menjadi 3 tugas:

• Layar editor bersih
• UI editor yang ditingkatkan
• Kerangka ekstensi editor yang ditingkatkan.

Saya akan mengatakan kebanyakan orang menggunakan WordPress untuk membuat konten bentuk panjang dan tidak ingin dipaksa menggunakan blok untuk membuat konten mereka. Blok bagus untuk pembuatan tata letak halaman tetapi mengganggu saat digunakan setiap kali posting ditulis.

Saya memiliki pelanggan yang berusia 80-an. Dia hanya ingin membuat konten. Dia tidak mau dipaksa untuk mempelajari kembali cara menggunakan layar editor. Butuh waktu lebih dari setahun untuk membuatnya terbiasa dengan Visual Composer dan itu adalah pembuat halaman yang mudah digunakan.

Saya telah menyimpang dari topik utas asli tetapi ini perlu dikatakan: Guttenberg akan mematikan WordPress.

Jika Guttenberg diperkenalkan dalam bentuknya saat ini, WordPress akan bercabang dan versi Guttenberg akan mati.

Mungkin editor baru lebih masuk akal jika Anda menggunakan WordPress untuk situs blog dan membuat tema PHP untuknya, tetapi saat ini banyak orang menggunakan WordPress sebagai CMS untuk membangun aplikasi web menggunakan React, PODS / ACF dan WordPress REST API. Oleh karena itu, kebutuhan untuk mendukung metabox dan bidang Hubungan untuk menghubungkan lanjutan antara CPT.

Pertama, saya pikir Gutenberg akan menjadi luar biasa.

Karena itu, saya pikir kita semua bisa setuju bahwa melanggar situs web / fungsionalitas merusak kepercayaan, dan itu tidak keren. Kita semua ingin bisa mempercayai satu sama lain, dan klien / pelanggan kita ingin / perlu mempercayai kita.

Saya rasa hal terbaik yang dapat kita lakukan adalah menyertakan filter yang dapat digunakan pengembang untuk kembali ke layar editor "lama".

Dengan cara ini, kita dapat menerapkan logika kita sendiri untuk menentukan apakah kita siap untuk Gutenberg atau tidak. Jika pengguna menggunakan kotak meta yang akan rusak sepenuhnya di Gutenberg, kita dapat memilih untuk kembali ke mode lama.

Kemudian, kita dapat bekerja dengan kecepatan kita sendiri untuk memigrasi kotak meta atau ide kita agar sesuai dengan Gutenberg, sambil tetap mempertahankan pos lama yang bergantung pada kotak meta "warisan" kita berfungsi sebagaimana mestinya.

Mengapa metabox lama tidak dapat dirender di lokasi (konteks) tempat mereka terdaftar dan tetap berfungsi seperti saat ini?

Jadi, pertama-tama render bagian editor Gutenberg (opsional), diikuti oleh kotak meta konteks normal / lanjutan terdaftar (warisan) apa pun (dengan judul terdaftarnya), lalu bilah sisi dengan kolom Pengaturan Pos baru dan di bawah sisi mana pun yang terdaftar (warisan) kotak meta konteks (dengan judul terdaftar itu).

Tentu saja meta box legacy akan ditata seperti kotak Post Settings yang baru, semuanya akan terlihat terintegrasi dengan baik.

Mungkin itu akan membutuhkan skrip legacy-meta-box.php yang akan dimuat saat dibutuhkan, misalnya ketika add_meta_box dipanggil.

Jika kami hanya memikirkan solusi meta box saat ini sebagai "warisan" dan mengharuskan mereka untuk menggunakan editor lama tanpa pernah memikirkan alasan untuk menggunakannya sejak awal dan kemudian bekerja pada cara yang lebih baik untuk menyediakan fungsionalitas tersebut di editor baru, maka situs saat ini hanya akan tetap lama dan tidak pernah meningkatkan versi. Ini akan menjadi masalah besar bagi pengguna yang mengelola situs klien.

Alasan kami menggunakan bidang ACF di hampir semua proyek kami adalah untuk mengontrol data agar ditampilkan secara konsisten di situs web. Berikut adalah dua contoh yang sedang kami kerjakan; Situs acara besar dan festival dengan karya / instalasi yang perlu ditautkan ke seniman tetapi ditampilkan secara terpisah. Dalam kedua kasus ini, "konten", bagian yang Gutenberg gantikan hanya sekitar 10% dari konten di layar edit dan sebenarnya adalah bagian yang paling tidak penting. Untuk situs acara, data penting adalah Jenis acara, Kategori acara, tanggal, waktu, lokasi, penyelenggara, dll. Anda dapat menerbitkan entri acara yang bermakna tanpa memasukkan konten apa pun di editor sama sekali. Untuk situs festival, kami harus dapat memilih artis dan menautkannya ke sebuah karya, memilih lokasi karya di situs festival, dan mengunggah gambar unggulan, sekali lagi konten tambahan bukan keharusan. Untuk semua konten halaman "normal" di situs ini, Gutenberg tidak cukup fleksibel (dan tidak seharusnya secara default, saya tidak percaya) dan kami akan terus menggunakan pembuat halaman berfitur lengkap (Beaver Builder) untuk lebih baik pilihan desain.

Faktor kunci lainnya dalam semua ini adalah urutan konten di layar edit. Untuk acara, Anda perlu menetapkan judul tetapi kemudian dalam alur pengeditan yang ideal Anda menginginkan beberapa informasi penting seperti tanggal, waktu, dll. Dimasukkan SEBELUM Anda memasukkan "konten" apa pun ke "editor". Kami harus memiliki kemampuan untuk mengontrol di mana di halaman edit konten, sebelum atau sesudah "konten".

Ide untuk hanya membuat tab lain dengan semua kotak meta "warisan" di atasnya akan menjadi mengerikan. Ini akan merusak aliran pengeditan sepenuhnya untuk banyak penggunaan CPT, menyembunyikan konten dari pengguna dengan cara yang menurut saya akan sangat sulit ditemukan.

Proyek harus JAUH lebih pintar tentang itu. Proses tab mungkin berfungsi dengan baik jika Anda dapat memilih (dalam beberapa jenis templat halaman) bit mana yang ada di tab mana. Anda juga memerlukan mekanisme untuk mengarahkan pengguna melalui setiap tab. Namun, saya juga percaya bahwa untuk item CPT yang lebih pendek Anda HARUS memiliki kemampuan untuk menyimpan semuanya dalam satu halaman dengan elemen kunci tertentu di atas konten editor (blok diperlukan jika Anda mau).

Secara keseluruhan, sebagian besar solusi yang dibicarakan orang tampaknya tidak memiliki fleksibilitas apa pun dari layar edit saat ini.

Itu sebabnya saya takut dengan timeline 5.0 untuk ini, rasanya ini bisa menjadi waktu yang tepat tetapi jika itu terburu-buru, fragmentasi akan menghancurkan semua niat baik dari pengembang dan klien. WordPress memperdagangkan fleksibilitasnya, kompatibilitas mundur, dan keramahan pengguna secara umum. Kami tidak bisa mengorbankan itu untuk mainan baru yang mengilap. Lihatlah persyaratan PHP untuk WordPress, kita berbicara secara harfiah bertahun-tahun sebelum PHP 5.6 atau 7 menjadi persyaratan. Komunitas telah menyadari bahwa betapapun frustrasinya jangka waktu yang lama itu, penting untuk tidak merusak situs web. Bukankah ini masalah yang sama PERSIS?

Perubahan seperti ini, sementara pada akhirnya mereka akan bagus untuk platform harus dipikirkan dan dikelola dengan baik atau mereka mempertaruhkan fondasi yang dibangun di atas WordPress.

@avocadesign - Beberapa poin bagus. Kami akan dapat mendaftarkan kotak meta JavaScript ke depan, meskipun sepertinya pemikiran saat ini adalah memiliki dua lokasi ... yang tidak sefleksibel seperti yang Anda sebutkan.

@avocadesign - dijelaskan dengan baik. Post_content tidak selalu menjadi fokus postingan dan 'acara & artis' Anda adalah contoh yang bagus. Akan sangat bagus untuk melihat beberapa tangkapan layar yang menunjukkan ujung belakang & ujung depan dari jenis posting ini sehingga kami dapat membantu pengembang memvisualisasikan bagaimana WP digunakan sebagai CMS, dan bagaimana klien biasa bekerja melalui layar edit posting.

@detikcom

Jika kami hanya menganggap solusi meta box saat ini sebagai "warisan" dan mengharuskan mereka menggunakan editor lama

Dalam apa yang saya sarankan (di atas komentar Anda) kotak meta 'warisan' diposisikan baik di bawah editor Gutenberg (jika jenis posting membutuhkannya) atau di bawah blok Pengaturan Posting (tergantung pada konteks tempat mereka terdaftar). Saya tidak melihat adanya persyaratan untuk tetap menggunakan editor lama.

Saya setuju antarmuka tab tidak akan berfungsi. Apa pendapat Anda tentang saran saya. Seperti yang saya lihat, ini akan memberi Anda semua fleksibilitas yang biasa Anda gunakan dan akan memungkinkan Anda untuk pindah ke sistem baru saat siap.

Jika Gutenberg akan menjadi bagian dari inti, Anda akan dapat membuat UI yang lebih baik untuk sampel yang Anda sebutkan. Ini sebagian akan terdiri dari blok Festival kustom (semacam formulir WYSIWYG) dan pengaturan terkait di satu atau lebih bagian Pengaturan Posting (berbasis JS). Pengguna akan mendapatkan keuntungan dari antarmuka yang lebih cepat dengan umpan balik langsung.

WordPress memperdagangkan fleksibilitasnya, kompatibilitas mundur, dan keramahan pengguna secara umum. Kami tidak bisa mengorbankan itu untuk mainan baru yang mengilap.

Saya tidak setuju. Saya pikir Anda harus memberi Gutenberg sedikit lebih banyak pujian. Mereka bekerja keras untuk mendapatkan solusi yang cocok untuk semua orang. Mereka mendengarkan dan mencari kasus penggunaan (seperti yang Anda sebutkan) Belum ada yang ditetapkan, begitu pula rilis Gutenberg yang 'mungkin' menjadi bagian darinya.
Jika Gutenberg tidak menangani semua masalah yang saat ini sedang dibahas, Anda dapat percaya itu tidak akan menjadi bagian dari rilis 5.0. Kami telah melihat itu terjadi di masa lalu berkali-kali dengan fitur-fitur lain juga.

Berikut adalah contoh antarmuka yang saya buat dengan Bidang Kustom Lanjutan untuk klien yang mengelola properti hotel.

• Jenis posting kustom Properti menggunakan 18 kolom kustom di 10 tab.
• Tab menyimpan semua informasi terkait di satu layar dan dapat diakses oleh editor dengan mengklik tombol.
• Tipe bidang menyertakan teks sederhana dan bidang angka selain galeri ACF dan bidang hubungan.
• Dukungan untuk editor tidak dideklarasikan dalam registrasi tipe posting kustom, yang berarti seluruh UI bergantung pada kotak meta kustom.

Jenis UI ini mewakili banyak situs WordPress kustom tempat serangkaian kolom kustom berisi campuran konten di halaman dan data meta "tak terlihat" yang digunakan untuk mengatur postingan.

Komunitas perlu mengetahui apa yang terjadi pada jenis antarmuka ini setelah Gutenberg diperkenalkan, dan menurut saya meminta @elliotcondon untuk memindahkan semuanya ke React pada saat peluncuran adalah harapan yang realistis.

@novitasari

Komunitas perlu mengetahui apa yang terjadi pada jenis antarmuka ini setelah Gutenberg diperkenalkan

Anda benar, tetapi tujuan dari terbitan # 952 ini adalah untuk _menemukan_ jawaban itu dengan mendiskusikan dan menyarankan alternatif. Apa yang berhasil, apa yang tidak. Di beberapa titik di masa depan, ketika semua orang mengira kita semua datang ke sesuatu yang akan bekerja di semua kasus warisan dan masa depan, hanya dengan begitu hal itu dapat diterapkan dan komunitas (pengguna) dapat dijelaskan cara kerjanya. Saat ini terlalu dini untuk mengharapkan jawaban dari tim atas pertanyaan IMHO itu.

Saya pikir kasus penggunaan yang Anda berikan dan yang disediakan oleh

Berkenaan dengan contoh Anda, saran saya (lihat beberapa reaksi di atas) hanya akan menampilkan semua kotak seperti yang ditunjukkan pada tangkapan layar (tentu saja dengan gaya Gutenberg yang baru).

@novitasari

Gutenberg kemungkinan besar akan memilih CPT, sama seperti CPT Anda yang tidak menyatakan dukungan untuk editor saat ini. Saya tidak mengerti mengapa itu tidak akan pernah memilih untuk CPT karena kebanyakan hal di WordPress sangat fleksibel, Gutenberg tidak akan berbeda. Saat ini hanya berfungsi untuk posting.

Saya sangat meragukan Gutenberg akan mengubah apa pun untuk antarmuka seperti ini, juga bukan maksudnya. Karena itu, mungkin menarik untuk menjelajahi apa yang ditawarkan Gutenberg dan melihat apakah Anda dapat membuat pengalaman pengeditan yang lebih menarik untuk klien Anda dengan menggunakannya.

Misalnya, Anda dapat membuat blok properti / properti, yang dapat digunakan untuk mengizinkan klien Anda menyematkan informasi properti ke dalam posting lain, dll. Dengan cepat dan mudah. Kemudian saat mengedit di Gutenberg, mereka dapat mengubah informasi yang sama yang Anda lihat di ACF sambil melihat informasi properti yang ditampilkan di dalam Gutenberg. Gutenberg tidak menyalip antarmuka admin WordPress, ia menggantikan fungsionalitas editor, dan kemungkinan besar akan mengarah pada pemblokiran template konten berbasis.

Hal-hal baik datang dari Gutenberg, bukan sakit kepala!

Berikut layar edit Acara untuk situs yang disebutkan di atas dengan bidang ACF di atas post_content dan kemudian kotak meta standar Kalender Acara di bawah post_content.

Situs ini akan terbuka untuk banyak pengguna non teknis, kita tidak berbicara tentang tim editorial terlatih, kita berbicara tentang Joe rata-rata yang tidak pernah menggunakan WordPress sebelumnya atau pernah dilatih selain bantuan yang kami sediakan di situs.

Kami telah menetapkannya dengan cara ini untuk memastikan bahwa pengguna menemukan dan memasukkan jenis dan kategori acara serta tajuk dan gambar unggulan untuk setiap acara. Kami juga dapat menggunakan posisi kotak meta yang ada untuk memberikan dokumentasi bantuan yang relevan di layar untuk membantu mereka mengedit acara dan memberikan dukungan kepada pengguna baru dengan cara yang tidak mengganggu.

Juga harap diingat bahwa kami masuk sebagai admin, pengguna non-admin memiliki berbagai kotak meta bilah sisi yang disembunyikan untuk lebih mengurangi kekacauan visual yang mereka lihat.

"Konten" hampir tidak relevan seperti berbagai kotak meta untuk berhasil memasuki acara. Acara tidak akan ditampilkan di situs jika tanggal tidak dimasukkan dengan benar atau kategori dipilih. Hal yang membuat saya khawatir tentang keseluruhan diskusi ini adalah mock up seperti di edisi # 1352 di mana kotak meta diturunkan ke bagian bawah layar di bagian yang bisa diciutkan. Saya dapat menjamin Anda dari pengalaman kami, kami akan membuat pengguna yang tidak terlatih tidak pernah melihat kotak meta, cukup memasukkan tanggal dan lokasi langsung ke area konten sebagai teks biasa dan kemudian mengeluh bahwa acara mereka tidak muncul di sistem. Hanya saja tidak cukup dapat ditemukan untuk pengguna yang tidak terlatih dalam jenis posting yang membutuhkan informasi terstruktur.

Kami juga memiliki bidang wajib dalam antarmuka ini dan jika kotak meta diciutkan pengguna akan mendapatkan peringatan tetapi tidak dapat dengan mudah menemukan penyebab masalahnya.

Metabox atau iterasi berikutnya dari jenis fungsinya haruslah warga negara kelas satu dan kami membutuhkan kemampuan untuk menempatkannya di atas konten, di samping konten, atau di bawah konten untuk membuat antarmuka yang dapat digunakan untuk klien kami.

Gutenberg kemungkinan besar akan memilih CPT, sama seperti CPT Anda yang tidak menyatakan dukungan untuk editor saat ini.

Mendaftarkan dukungan untuk Gutenberg di CPT belum dikonfirmasi, dan sejujurnya rasanya lebih seperti menghindari masalah kotak meta daripada menyelesaikannya. Jika satu-satunya cara bagi situs yang ada untuk mengakses Gutenberg adalah dengan mendaftarkan dukungannya dengan kode, maka itu akan sangat membatasi calon audiens.

Kami juga tidak boleh berpura-pura bahwa kotak meta khusus hanya digunakan dalam jenis posting khusus. Mereka sama mungkinnya ada di posting dan halaman biasa.

Gutenberg tidak menyalip antarmuka admin WordPress, itu menggantikan fungsionalitas editor ...

Ini tidak akurat. Seperti yang ada saat ini, Gutenberg _is_ pengganti layar penuh untuk layar edit posting.

@ BE-Webdesign & @evinwhoffman

Juga mengapa CPT harus melewatkan aspek Gutenberg yang jelas lebih baik daripada layar edit saat ini?

Kontrol publikasi dipindahkan ke atas sehingga mereka tidak bingung dengan konten dan estetika keseluruhan yang lebih bersih jelas merupakan poin kuat dari arah proyek ini.

Dengan tidak memiliki rencana yang layak tentang cara membuat fungsionalitas yang setara dengan yang ada saat ini untuk CPT dengan kebutuhan kompleks (melalui kotak meta), kami mengabaikan sebagian besar basis pengguna dan menurunkannya ke kelas kedua, yang pada akhirnya tidak didukung oleh pengalaman.

IMHO yang sekadar menyebalkan.

Saya bahkan tidak memperdebatkan bahwa metabox perlu bekerja di luar kotak karena mereka saat ini ada. Mungkin ada cara baru dan lebih baik untuk mengimplementasikan fleksibilitas antarmuka semacam ini.

Yang saya khawatirkan adalah bahwa tim pengembang tampaknya tidak benar-benar memahami masalah untuk banyak pengembang dengan menerapkan pendekatan pertama "post_content" di sini. Kami menggunakan pembuat Beaver di SEMUA situs kami, kecuali untuk CPT di mana kami membutuhkan keluaran data terstruktur. Alat pembuat halaman, yang merupakan Gutenberg, sangat bagus untuk posting dan halaman dengan kebutuhan konten individual. Sangat buruk untuk data terstruktur. Untuk data terstruktur, konsistensi antarmuka, bidang wajib, dan prioritas tata letak lainnya selalu mengalahkan konten bentuk bebas.

@novitasari

Kami juga tidak boleh berpura-pura bahwa kotak meta khusus hanya digunakan dalam jenis posting khusus. Mereka sama mungkinnya ada di posting dan halaman biasa. Ini tidak akurat. Seperti yang ada saat ini, Gutenberg adalah pengganti layar penuh untuk layar edit posting.

Ya, tetapi itu tidak menggantikan seluruh antarmuka admin, yang saya maksudkan. Anda membandingkan proyek yang belum selesai dengan pengalaman saat ini. # 2251, setelah selesai, akan memperkenalkan kembali kotak meta yang maha kuasa, jadi tidak akan terlalu berbeda, dan akan jauh lebih baik. Mungkin akan ada beberapa hal yang mungkin harus diubah oleh pembuat plugin tertentu, tetapi sebagian besar saya yakin bahwa semuanya akan berjalan lancar.

@detikcom

Juga mengapa CPT harus kehilangan aspek Gutenberg yang jelas lebih baik daripada layar edit saat ini?

Tidak ada yang mengatakan mereka sepengetahuan saya? Tidak terlalu banyak perbedaan antara menambahkan dukungan editor untuk CPT, dan menambahkan dukungan untuk editor blok.

Dengan tidak memiliki rencana yang layak tentang cara membuat fungsionalitas yang setara dengan yang ada saat ini untuk CPT dengan kebutuhan kompleks (melalui kotak meta), kami mengabaikan sebagian besar basis pengguna dan menurunkannya ke kelas kedua, yang pada akhirnya tidak didukung oleh pengalaman.

Saya pikir ada rencana yang layak, mungkin tidak jelas, tetapi saya sangat yakin bahwa Gutenberg akan memenuhi kebutuhan sebagian besar dari semua jenis pengguna, bahkan melebihi mereka, ketika semua dikatakan dan dilakukan.

Tidak ada yang mengatakan mereka sepengetahuan saya? Tidak terlalu banyak perbedaan antara menambahkan dukungan editor untuk CPT, dan menambahkan dukungan untuk editor blok.

Saya khawatir bahwa langkah yang dibicarakan oleh banyak orang di utas ini untuk membuat Gutenberg ikut serta untuk CPT akan mengakibatkan banyak kasus penggunaan kompleks saat ini diabaikan di Gutenberg dalam jangka pendek hingga menengah dan secara efektif memaksa kasus penggunaan seperti acara yang diilustrasikan di atas untuk menggunakan sistem yang ada karena Gutenberg tidak cukup fleksibel. Hal ini secara efektif memaksa kasus penggunaan kompleks saat ini untuk kehilangan keuntungan lain dari proyek tersebut.

Kami sering diberi tahu "jangan khawatir, ini akan baik-baik saja" tetapi Anda benar @ BE-Webdesign ketika Anda menyarankan bahwa rencana tidak disajikan dengan jelas sama sekali untuk sebagian dari kita, saya tidak bisa melihat di semua bagaimana ini akan diselesaikan secara memuaskan dalam jangka pendek - jika kemudian silakan tunjukkan diskusi atau masalah untuk mencerahkan saya.

Edit:
Yang saya maksud dengan "jangka pendek" adalah dengan meluncurkan 5.0 ke publik, awal 2018 sepertinya menjadi tujuan di sini. Jangka panjang dalam waktu 2 atau 3 tahun saya dapat melihat ini jauh lebih berhasil diselesaikan.

@BennyVL & @dmccan Fleksibilitas adalah masalah utama di sini. Koreksi saya jika saya salah tetapi tidak satu pun dari apa yang saya lihat disarankan oleh para pengembang yang mengerjakan ini sefleksibel yang kami miliki saat ini.

Dengan ACF dan plugin lain, saya dapat dengan mudah mendaftarkan metabox di atas konten (di bawah judul), di bawah konten, dan di sidebar. Desain antarmuka terserah saya. Itu tidak memaksakan bahwa editor adalah yang pertama, itu tidak mengamanatkan bahwa editor bahkan ada. Saya dapat mendaftarkan metabox baru, saya dapat membatalkan pendaftaran atau memindahkan orang lain.

Yang saya inginkan adalah solusi yang tetap fleksibel dalam jangka panjang. Apakah metabox perlu diperbarui ke format JS baru yang mengkilap, menjadi blok yang tepat atau beberapa perubahan lain yang perlu dilakukan untuk memungkinkan hal ini tidak terlalu mengganggu saya. Saya ingin fleksibilitas yang saat ini kami nikmati disertakan di Gutenberg terlepas dari metode yang digunakan untuk mencapainya.

Yang saya inginkan adalah solusi yang tetap fleksibel dalam jangka panjang. Apakah metabox perlu diperbarui ke format JS baru yang mengkilap, menjadi blok yang tepat atau beberapa perubahan lain yang perlu dilakukan untuk memungkinkan hal ini tidak terlalu mengganggu saya. Saya ingin fleksibilitas yang saat ini kami nikmati disertakan di Gutenberg terlepas dari metode yang digunakan untuk mencapainya.

Itulah tujuan dan keinginan kebanyakan orang.

Saya telah mendengarkan banyak obrolan tentang masalah kotak meta dan apa yang akan terjadi pada mereka dengan editor baru ini. Pandangan pribadi saya adalah bahwa Gutenberg harus fokus hanya pada editor dan bukan layar edit seluruh halaman. Tapi sepertinya keputusan itu sudah dibuat.

Hai kawan,

Saya adalah pengembang utama Carbon Fields dan ingin menambahkan daftar tindakan / filter yang kami gunakan yang mungkin terpengaruh:

Filter:

• postbox_classes_{$page}_{$id}

Tindakan:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (gula posisi - tidak kritis)

Pertanyaan saya:

• Jika kita akan menyimpan kotak meta lama, bagaimana mereka berinteraksi dengan perubahan data?
• Jenis peristiwa apa (jQuery? Beberapa implementasi emitor yang terekspos?) Dan peristiwa apa sebenarnya yang dapat kita harapkan dari editor baru (misalnya pada keberhasilan pengiriman, kegagalan, dll.)?
• Akankah acara ini tersedia untuk kotak meta lama atau hanya untuk implementasi React?

PS:
Saya hanya ingin berterima kasih kepada tim Gutenberg atas semua kerja keras dan upaya dan itu membuat saya bersemangat bahwa WordPress bergerak menuju alat dan solusi modern (bahkan jika perjalanannya tampak menakutkan)!

Mendukung kotak meta sangat penting ...

... untuk ribuan pengembang dan pengguna wordpress.

WordPress tidak dapat mengabaikan pemutar plugin besar ...

... seperti Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622), WooCommerce atau Yoast SEO.

Saya bertanggung jawab atas proyek Toolset , yang banyak menggunakan jenis kustom, bidang, dan taksonomi.

Kami ingin membuat plugin kami kompatibel dengan Gutenberg.

Inilah yang saya mengerti:

• Kami perlu menggunakan API baru untuk menampilkan bidang khusus dan taksonomi pada halaman dan posting, ketika mereka menggunakan Gutenberg.
• Kami tidak perlu melakukan apa pun tentang Gutenberg untuk CPT, karena mereka akan menggunakan editor WordPress biasa dan bukan Gutenberg.

Apakah ini benar? Jika demikian, dapatkah Anda merujuk saya ke dokumentasi API untuk menampilkan kotak kustom di Gutenberg?

Saya pikir dokumennya masih berkembang. Ada beberapa dokumen di https://github.com/WordPress/gutenberg/tree/master/docs - http://gutenberg-devdoc.surge.sh/

Saya mendengar apa yang dikatakan @ BE-Webdesign dan yang lainnya tentang niat untuk meminimalkan gangguan - terima kasih, itu meyakinkan - tetapi hanya ingin menambahkan nilai 5p saya (ok, ok, nilai 105p saya yang biasa.)

Siapa pun yang telah mengembangkan untuk sementara waktu akan mengingat rasa sakit membuat antarmuka web secara manual untuk database yang dipesan lebih dahulu - membosankan, memakan waktu, rawan kesalahan, dan sangat mahal dalam hal waktu pengembang.

WordPress plus Advanced Custom Fields (Pro) adalah alat yang hebat untuk secara efisien membuat situs web berbasis database yang dipesan lebih dahulu (dan bahkan alat manajemen data intranet) dengan ujung depan yang menarik, pemeriksaan entri data yang ketat, antarmuka pengguna yang intuitif dan konsisten, dll. Sistem ini mungkin tidak dapat diskalakan untuk volume data relasional yang sangat besar, tetapi dalam banyak kasus, data tersebut tidak perlu; ini adalah sistem sederhana yang dapat dibuat dengan biaya yang efektif untuk klien. Inilah yang membuat WordPress menjadi CMS yang sangat berguna (dan, efeknya, RDBMS yang ringan), bukan hanya platform blogging.

Saya (dan saya yakin banyak lainnya) bisnis kecil menggunakan WP + ACF (atau plugin data khusus serupa) untuk membuat situs dan sistem yang dipesan lebih dahulu untuk organisasi klien dan individu yang tidak memiliki anggaran TI yang besar. Jika pengenalan Gutenberg dilakukan tanpa pertimbangan untuk mendukung aliran pengeditan / entri data, metabox, dll., Saya memiliki dua masalah "non-teknis" namun tetap signifikan:

1 / Pengguna akhir saya akan memerlukan pelatihan ulang (mudah bagi kami, sebagai teknisi, untuk melupakan betapa bingungnya pengguna non-teknis yang sangat besar dengan perubahan antarmuka - Saya menulis plugin Clarify Password Reset karena saya kehilangan begitu banyak waktu untuk memilah-milah pengguna yang benar-benar terhalang oleh proses pengaturan ulang kata sandi baru yang diperkenalkan di 4.3).

2 / Selain meningkatkan plugin saya sendiri untuk pendekatan metabox yang berbeda, saya harus meluangkan waktu untuk meningkatkan dan menguji semua situs klien saya dengan tingkat ketekunan profesional, memastikan bahwa setiap dan semua plugin pihak ketiga saya menggunakan juga telah berhasil memperbarui basis kode mereka dengan benar. (Dan ini dalam situasi di mana saya tidak memiliki kendali atas seberapa cepat plugin pihak ketiga diperbarui, baik sebelum atau (bahkan lebih buruk) beberapa saat setelah rilis 5.0 - jadi perencanaan beban kerja menjadi sangat sulit.)

Tidak satu pun dari kasus di atas yang menurut saya adalah benar untuk membebankan biaya lebih lanjut kepada klien saya untuk pekerjaan tambahan itu; lagipula, saya memilih platform untuk membangun situs dan sistem mereka, dan bukannya mereka meminta perubahan atau peningkatan. Mungkin saya "terlalu baik" atau naif dalam hal itu, tetapi seperti yang telah disebutkan orang di atas, ini adalah masalah kepercayaan; kami percaya WordPress untuk tidak menjatuhkan kami ke dalam kotoran dengan melanggar kompatibilitas mundur, sehingga klien kami dapat mempercayai kami untuk tidak menyengat mereka untuk biaya tambahan yang tidak terduga. Hasil akhirnya adalah bahwa saya tiba-tiba memiliki sejumlah besar pekerjaan ekstra yang belum dibayar untuk menyesuaikan - mungkin mendesak, jika situs secara aktif rusak oleh peningkatan segera - sambil terus melakukan pekerjaan berbayar yang cukup untuk tetap bertahan.

Saya sangat suka menggunakan WordPress, dan telah menginvestasikan banyak waktu untuk mempelajari seluk-beluknya, mengembangkan kerangka kerja proyek saya sendiri, dll. - ke titik di mana saya sekarang memanfaatkan sebagian besar hidup saya (dan memberi makan keluarga saya dll) melalui proyek pengembangan berbasis WordPress. Saya juga mencoba memberikan sesuatu kembali dengan meluangkan waktu untuk secara resmi merilis plugin kecil yang bermanfaat yang telah saya kembangkan ke WordPress.com, karena saya menghargai OSS, pengembangan berbasis komunitas, dll. Saya kira ini sebagian besar adalah permohonan untuk mengambil masalah disebutkan dalam masalah ini utas sebanyak mungkin; jika tidak, saya setuju bahwa ada bahaya nyata bahwa basis kode mungkin bercabang. Sebagai penggemar WordPress dan kontributor plugin, menurut saya ini hasil yang SANGAT buruk; Namun, sebagai pengembang tunggal yang mengandalkan WP untuk mencari nafkah, saya mungkin harus menggunakan versi bercabang (yaitu kompatibel dengan mundur) karena kebutuhan ekonomi. Tolong jangan biarkan ini terjadi!

@konamac membuat beberapa poin bagus, beberapa di antaranya telah saya posting di utas lain.

Untuk mendukung ini, sama sekali tidak dapat diterima untuk tidak memberi kami jawaban yang meyakinkan tentang masa depan metabox.

1. Tidak ada jawaban langsung untuk dukungan masa depan dari metabox yang ada. Ini adalah langkah yang sangat membuat frustrasi dan berat terhadap agen pengembangan dan pembuat tema / plugin. "Gutenberg adalah open source, jadi cari tahu sendiri" tidak bertanggung jawab.

2. Gutenberg luar biasa. Saya suka antarmuka, desain visual, dan menurut saya inilah cara masa depan dalam hal mengedit konten. Tapi itu jauh di belakang yang dibutuhkan untuk mempertimbangkannya untuk rilis 4.9 atau 5.0.

3. Semua yang harus saya lakukan dalam warisan adalah semua yang harus saya lakukan di Gutenberg.

4. Opsi layar
5. Kotak Meta (ACF, Yoast, dll)
6. Permalinks ?! Saya bahkan tidak dapat mulai memahami mengapa ini belum dapat diedit di 1.0
7. Blok konten klasik TIDAK dimuat dengan benar di lingkungan localhost
8. Dokumentasi HARUS menjadi kunci untuk membuat blok gaya yang berbeda. Berikan beberapa contoh, beberapa kasus penggunaan. Tidak semua pengembang tema adalah backend, jadi jangan berasumsi. Bersikaplah jernih
9. Pengaturan blok perlu bekerja. Sangat sulit untuk mengetahui pengaturan apa yang tersedia per blok. Sepertinya acak. Kapan saya perlu mengedit pengaturan blok vs kapan saya tidak?
10. Seluruh tag komentar di sekitar editor teks Gutenberg ... menyedihkan untuk dilihat.

Beberapa dari kita menjadi sangat frustrasi dengan proses ini. Ini harus menjadi jawaban sederhana yang mati.

Akankah Gutenberg melindungi penggunaan metabox / ACF saat ini, dan adakah rencana untuk memastikan dukungan semacam itu tanpa batas waktu?

Kami tidak perlu tahu apa solusinya saat ini - kami tahu Anda sedang mencari tahu. Tapi kami masih belum memiliki jawaban yang JELAS untuk ini. ACF khususnya perlu bekerja dengan cara yang persis sama seperti selalu mendukung klien lama yang TIDAK akan setuju untuk dikenai biaya pembaruan - terutama ketika membahas penghapusan editor lama di beberapa titik (bagaimana Anda bahkan bisa mulai melakukan percakapan itu sekarang ?! )

Cintai Gutenberg. Tetapi saya harus bergabung dengan paduan suara - ini semakin konyol. Cara tim proyek mengkomunikasikan harapan ini tidaklah sederhana. Ya atau tidak adalah semua yang kita cari.

@ BE-Webdesign

setelah selesai, akan memperkenalkan kotak meta yang maha kuasa kembali

Oleh karena itu, bisakah saya menyarankan agar Anda menulis keseluruhan posting tentang masalah ini, yang sebenarnya Anda TELAH menunjukkan, bahwa kotak meta, seperti sekarang, akan tetap ada. Ini akan mencegah banyak pengembang khawatir di masyarakat yang khawatir dengan bisnis mereka.

Selain itu, saya akan mendorong tim untuk menjadikan ini sebagai prioritas untuk menambahkan ini sekarang. Ini akan mencegah banyak hal negatif seputar proyek saya yakin.

Seperti yang dinyatakan dalam # 2308, saya menyalin pengait yang digunakan plugin Meta Box saat membuat / menyimpan bidang khusus:

• Skrip, gaya diantrekan menggunakan admin_enqueue_scripts . Kami memeriksa layar saat ini (melalui get_current_screen ) untuk memastikan skrip dan gaya hanya diantrekan untuk halaman itu. Untuk plugin inti, ia memeriksa berdasarkan jenis posting. Untuk ekstensi (istilah meta, meta pengguna, halaman pengaturan), ia memeriksa lebih banyak untuk taksonomi, halaman profil pengguna atau halaman pengaturan.
• Kami juga menggunakan print_media_templates untuk mencetak template Underscore.
• Skrip yang kami gunakan di plugin meliputi: pemilih warna, garis bawah, tulang punggung, skrip media, tinymce (untuk bidang editor)
• Kami menggunakan init untuk menginisialisasi semua pengait untuk plugin.
• Kotak meta didaftarkan menggunakan hook add_meta_boxes .
• Kotak meta tersembunyi menggunakan default_hidden_meta_boxes .
• Kami juga mengaitkan ke post_edit_form_tag untuk memungkinkan mengunggah file.
• Kami menggunakan save_post_{$post_type} dan edit_attachment , add_attachment untuk menyimpan nilai meta untuk posting dan lampiran.

Apa yang salah dengan membangun kait untuk menampilkan metabox di atas / bawah / sidebar Gutenberg?

Saya pikir saya mungkin juga melakukan apa yang terbaik yang dilakukan oleh pengembang pihak ketiga, dan melemparkan kunci pas besar lainnya dalam pengerjaan.

Mattias memberi tahu kita bahwa metabox dapat dirancang ulang sebagai blok yang menyimpan ke post_meta. Jika itu adalah tujuan penggabungan, maka ada beberapa masalah yang harus diselesaikan:

Banyak metabox mendaftarkan the_editor($custom_id); untuk ini untuk didukung dalam konteks Gutenberg, baik antarmuka dan api untuk membuat blok bersarang diperlukan sejak hari pertama, atau kami mengatakan bahwa metabox hanya dapat memiliki antarmuka editor kelas dua , tanpa manfaat apa pun dari pemblokiran. Ini akan menjadi masalah terutama bagi sejumlah besar agensi yang saat ini merancang menggunakan Tata Letak Fleksibel ACF, karena mereka akan memerlukan cara untuk membuat blok Gutenberg terpisah untuk berbagai konteks dan area. Bahkan "berpikir dalam blok" Saya tidak melihat cara yang baik untuk menyelesaikan masalah "area konten diikuti oleh bagian template diikuti oleh area konten" tanpa mendukung penumpukan di "metablocks" sejak hari pertama.

Berasal dari itu, adalah masalah teknis bersarang sehubungan dengan blok yang tidak disimpan di post_content. Mattias mengatakan blok akan dapat disimpan ke postmeta, tetapi jika sebuah blok dapat menentukan di mana ia disimpan, bagaimana pekerjaan bersarang, ketika blok induk disimpan ke postmeta, dan pengguna menambahkan anak yang menyimpan ke post_meta yang berbeda ... (Atau dalam kasus patologis, blok bertingkat yang disimpan Tha ke postmeta berisi blok yang menyimpan ke bidang postmeta yang sama.

Ini mengarah pada kekhawatiran metabox ketiga. Jika Gutenberg adalah pengganti halaman edit penuh, bukan pengganti the_editor() , bagaimana orang bisa mengantrekan dan menggunakan blokir di halaman lain dan dalam konteks lain, seperti metabox atau panel admin khusus yang menggunakan the_editor() . Sekilas tampak bahwa jawabannya adalah "mereka tidak bisa". Yang mengarah ke beberapa masalah serius, apakah Gutenberg menambahkan fleksibilitas pada implementasi CMS kustom, atau menghapusnya.

Jika pengguna diberi opsi Gutenberg, dan itu sama revolusionernya bagi mereka seperti yang diklaim, tidak dapat menyediakan antarmuka baru itu dalam hal ini dapat menjadi bencana bagi agensi.

Tidak ada jawaban langsung untuk dukungan masa depan dari metabox yang ada.

Saya sudah mengatakan berulang kali kami akan memperhitungkan meta-box. Satu-satunya ketidakpastian adalah apa yang secara teknis layak dan bagaimana itu akan ditampilkan di UI baru.

Kami tidak mencoba merusak apa pun — shortcode, custom field, dll — semua masih bisa bekerja. UI untuk berinteraksi dengan mereka mungkin berubah (kecuali Anda menonaktifkan Gutenberg sepenuhnya), dan kasus penggunaan tertentu untuk meta-box akan lebih cocok untuk blok yang akan datang.

Gutenberg luar biasa. Saya suka antarmuka, desain visual, dan menurut saya inilah cara masa depan dalam hal mengedit konten.

Saya senang mendengarnya!

Permalinks ?! Saya bahkan tidak dapat mulai memahami mengapa ini belum dapat diedit di 1.0

Karena REST API belum mendukung ini. Bantuan apa pun diterima: https://github.com/WordPress/gutenberg/issues/1285

Saya sudah mengatakan berulang kali kami akan memperhitungkan meta-box.

@mtias Saya rasa kebingungan terkait dukungan kotak meta hasil dari @m menunjukkan bahwa plugin lama akan tersedia untuk memulihkan fungsionalitas yang ada. Akan sangat membantu untuk mengklarifikasi aspek apa dari antarmuka yang ada (kotak meta, posisi kotak meta, kait, dll.) Yang akan terus berfungsi dengan Gutenberg versus aspek mana yang memerlukan plugin lama untuk terus berfungsi.

Saya sudah mengatakan berulang kali kami akan memperhitungkan meta-box.

@mtias permintaan maaf saya, saya pasti melewatkan klarifikasi Anda di tempat lain. Senang mendengar! Buat iterasi saat ini secara visual lebih menarik dan terarah dan itu akan menjadi sukses besar.

Saya mengerti apa yang Anda katakan tentang dukungan REST API, saya akan melihat utas untuk pembaruan.

Terima kasih telah mengklarifikasi. Sekarang setelah saya memiliki wawasan ini, saya sangat cepat untuk Gutenberg - semua ketakutan saya dikesampingkan.

@kevinwhoffman benar, saya pikir inti masalahnya adalah bahwa "fungsionalitas yang ada" juga menyertakan presentasi — dan karena Gutenberg secara signifikan mengubah UI, kembali ke yang sebelumnya akan memerlukan plugin untuk dinonaktifkan. Bagaimana meta-box sesuai dengan UI baru dan bagaimana meta-box lama dapat didukung tanpa campur tangan pengembang adalah hal-hal yang sedang dikerjakan. Saya tidak tahu persis bagaimana itu akan berhasil, jadi saya belum bisa menjanjikan hasil yang spesifik. Saya juga berpikir ini bisa berakhir dengan presentasi fitur meta-box yang lebih jelas.

@brograhamer tidak perlu meminta maaf, ini adalah utas yang besar! Kami tidak ingin terburu-buru, dan ini adalah proyek yang cukup besar dengan banyak bagian yang bergerak. Terkadang beberapa hal mungkin tampak diabaikan, tetapi itu tidak berarti kami tidak berencana untuk menyelesaikannya.

Saat ini saya sedang membangun aplikasi web menggunakan ACF dengan 10 jenis posting khusus yang tidak menggunakan editor tinymce. Saya menggunakan fitur Judul dan rata-rata sekitar 15 bidang ACF untuk setiap CPT.
Saat ini Anda dapat mendeklarasikan fitur mana (mis. Editor, thumbnail, kutipan, dll) yang didukung CPT.
Apakah mungkin untuk menyembunyikan / menghapus blok paragraf "Tulis cerita Anda" serta ikon "Sisipkan blok" dari layar edit?

@ cr101 Saya pikir kami jika Anda melepaskan "editor" dari dukungan CPT Anda, kami mungkin harus melepaskan penyisip blok dan blok dari Gutenberg, tampaknya logis bagi saya.

Di sisi lain, dengan v1 dari metabox, panel metaboxes dapat diperluas dari bawah, jika kita menyimpannya, kita harus memastikan bahwa itu selalu "terbuka" untuk CPT tanpa dukungan "editor". Mungkin tidak perlu jika metabox selalu ditampilkan di bawah editor (seperti beberapa saran desain di atas)

Saya tidak yakin apakah ini tempat yang tepat untuk ini, tetapi bagaimana dengan bidang meta khusus inti? Ada banyak pembicaraan tentang plugin pihak ketiga tetapi bagaimana dengan bidang meta kustom inti. Saya tahu itu tidak terlalu populer tetapi saya dapat memikirkan beberapa situs tempat saya bekerja yang menggunakannya.

Apakah ada rencana untuk mengintegrasikan bidang meta kustom inti ke Gutenberg?

Hai @jawittdesign ,

Saya cukup yakin metabox inti (setidaknya sebagian besar) telah diimplementasikan kembali di Gutenberg! Mereka menampilkan beberapa alur kerja yang lebih baik di sekitar penanganan taksonomi, dll.

Tidak semua orang menggunakan WordPress untuk blogging. Banyak dari kita menggunakan WordPress sebagai CMS. Kami sedang membangun aplikasi web menggunakan WordPress REST API dan ACF. Kami memiliki 10 jenis posting kustom dan setiap CPT memiliki 20 kolom kustom dan semua CPT ditautkan satu sama lain melalui hubungan dua arah menggunakan kolom Hubungan ACF dan Objek Posting dan plugin ACF Post-2-Post.

Gutenberg tidak berguna bagi kami dalam bentuknya saat ini karena kami bahkan tidak menggunakan editor saat ini. Kami hanya menggunakan kotak teks Judul untuk CPT kami dan sisanya adalah bidang khusus yang disimpan di tabel post_meta.

Saya sangat yakin bahwa editor Gutenberg tidak boleh menjadi bagian inti dalam 'keadaannya saat ini. Saya menyadari bahwa WordPress sebagai sebuah proyek perlu bermain-main dengan para pembuat situs yang tidak bekerja dengan tema khusus mereka sendiri ... namun editor Gutenberg tampaknya menjadi serangan langsung terhadap kita yang menggunakan Bidang Kustom Lanjutan untuk membuat entri konten yang kompleks cukup "bukti bodoh" bagi pemilik situs dengan memberi mereka cara yang sangat spesifik untuk memasukkan konten mereka. Editor Gutenberg dalam 'keadaan saat ini tampaknya menyerang langsung kita yang menggunakan ACF.
Dengan plugin Gutenberg, tautan edit di tajuk mengirim pengguna langsung ke antarmuka Gutenberg yang tidak menampilkan kotak meta ACF APA PUN, dan tidak memiliki tab opsi layar di bagian atas layar untuk mengaktifkannya. Ya, pengguna dapat kembali ke array halaman / posting dan memilih opsi "editor klasik" dan kemudian melihat meta-box tetapi ini berarti bahwa langkah tambahan perlu diambil oleh editor situs untuk masuk ke kolom ACF. Tidak terlalu optimal mengingat tujuan penggunaan ACF dalam banyak kasus adalah untuk membuat pengeditan tata letak yang kompleks menjadi lebih lancar dan langsung untuk editor non-teknis.

Masalah yang sudah berlangsung lama ini!

Dengan penggabungan # 3345 dan # 3554, dukungan kotak meta berada pada keadaan yang dengan senang hati kami sebut _feature complete_. Perhatikan bahwa ini berbeda dari _complete_, karena jelas masih ada pekerjaan yang harus dilakukan untuk menyempurnakan pengalaman kotak meta, terutama seputar gaya, penanganan JavaScript yang lebih kompleks, dan menentukan aturan untuk kembali ke editor klasik.

Terima kasih kepada setiap orang yang telah berpartisipasi secara konstruktif dalam masalah ini, saya mengerti bahwa ini adalah proses yang sulit, dan terkadang kontroversial. Untuk dokumentasi tentang bagaimana Gutenberg menangani kotak meta, dan bagaimana Anda (jika Anda lebih suka) dapat menandai kotak meta sebagai tidak kompatibel dengan Gutenberg, silakan lihat buku pegangan .

Jika Anda mengalami bug yang terkait dengan plugin atau kotak meta tertentu, silakan buka masalah baru, sehingga dapat dilacak dengan benar, dan diperbaiki.

Sehubungan dengan itu, ini harus jauh dari fitur lengkap.

@coffeeneed Jika Anda ingin menjadi konstruktif, buka masalah baru dengan detail yang memadai untuk kami bantu. Terima kasih