Gutenberg: Tambahkan Blok: Bagian

Saya sangat suka ide ini! Saya juga suka fakta itu memiliki pengaturan latar belakang untuk itu.

Bagus! Bagaimana jika pemblokiran mengizinkan tiga setelan 'lanjutan' berikut:

• Tentukan nama kelas yang akan diserialkan ke anak-anak .child_class, .child_class_1
• Tambahkan kelas anak pertama opsional .child_class, .child_class_1, .child_class_first
• Tambahkan kelas anak terakhir opsional .child_class, .child_class_n, .child_class_last

:nth-child penyeleksi mungkin dapat mengkompensasi dua yang terakhir, tapi menurut saya menambahkan kelas untuk semua anak dapat berguna dalam konteks tertentu.

Suka ide ini. Jika warna latar belakang dan teks dapat diubah, mungkin masuk akal untuk menambahkan warna tautan juga.

Ide Luar Biasa. Ini benar-benar akan menambah banyak nilai bagi Editor Gutenberg.

Jauh lebih baik daripada hanya blok Kolom, yang memiliki banyak masalah. Keren!

Ini adalah hal pertama yang saya buat ketika saya melihat bahwa sarang tersedia. Versi saya serupa kecuali saya membayangkan bahwa Anda akan menambahkan blok kolom ke dalamnya.

Apakah Anda memiliki kode untuk ini tersedia?

Jika blok ini memiliki "kolom", kita harus memperbarui blok "kolom". Tetapi masih mungkin untuk menggunakan blok kolom di dalam blok bagian dan menjaga blok bagian tanpa kolom.

Selama Anda tidak bisa meletakkan blok kolom di dalam blok kolom 😉

Banyak halaman situs yang dipecah menjadi beberapa bagian yang memiliki konten campuran dengan beberapa baris kolom dan seringkali kolom bersarang di dalam kolom yang lebih besar. Ini adalah contoh singkatnya:

Blok bagian yang berfungsi seperti bungkus kosong menurut saya akan menjadi yang paling fleksibel. (seperti mampu membuat blok kolom bersarang!)

Kami telah memulai proyek situs baru minggu ini. Biasanya itu akan dibangun dengan tata letak konten fleksibel Bidang Kustom Lanjutan tetapi saya akan melihat seberapa jauh kita bisa menggunakan Gutenberg saja.

Ya, menurut saya bagian multi-kolom seperti contoh @jvisick di atas tidak jarang. Sebuah wadah dengan opsi latar belakang / teks yang blok sarang akan menjadi pendekatan yang paling fleksibel. Karena kami sekarang memiliki blok kolom yang berfungsi, kami bahkan dapat mempertimbangkan untuk mengambil opsi kolom dari ini.

Akan lebih bagus jika ada wadah dalam (div) di blok ini yang kemudian berisi semua blok anak. Penampung ini kemudian dapat diberi gaya dengan lebar-maksimal dan margin-kiri / kanan: otomatis untuk menengahkan blok anak dan memiliki latar belakang lebar penuh.

Memiliki bagian lebar penuh dengan konten yang dimuat ke tata letak yang lebih sempit adalah pola desain yang umum. Saya bertanya-tanya apakah itu akan lebih baik dikendalikan oleh blok bersarang daripada dimasukkan ke dalam blok bagian induk?

Saya pikir blok bagian akan sangat berguna untuk ... yah, bagian pada halaman, dan saya setuju bahwa kolom harus menjadi blok terpisah (seperti yang ada sekarang) yang dapat disarangkan di blok bagian. Saya pikir ini adalah sesuatu yang, bersama dengan blok Kolom, harus disertakan dalam versi Gutenberg yang digabungkan menjadi WordPress 5.0. Jika Anda melihat plugin pembuat halaman yang ada, bagian banyak digunakan, begitu juga kolom (jelas), jadi memasukkannya ke dalam rilis inti awal sangat penting menurut saya.

(Saya juga berpikir penting bahwa blok kolom mendapatkan fitur seperti kolom lebar-variabel dan kolom responsif, baik demi pengalaman inti serta memudahkan pembuat halaman yang ada untuk mendasarkan kembali diri mereka dari Gutenberg, tetapi itu adalah masalah terpisah.)

Setelah memikirkannya lagi, saya pikir akan lebih masuk akal jika blok Bagian dan Kolom menjadi hal yang sama. Tambahkan saja kemampuan untuk hanya memiliki satu kolom di blok Kolom daripada minimal dua. Kemudian tambahkan pengaturan latar belakang dari blok Bagian yang diusulkan ini ke blok Kolom.

Saya pikir memiliki satu blok Bagian / Kolom akan mengurangi jumlah bersarang yang harus Anda lakukan. Saat ini blok Bagian yang diusulkan tidak lebih dari sebuah area dengan opsi latar belakang dan lebar. Keduanya dapat ditambahkan ke blok Kolom, dan jika blok Kolom diizinkan karena hanya memiliki satu kolom, blok Bagian tidak diperlukan.

Selain itu, jika Anda menginginkan bagian lebar penuh dengan konten lebar standar, ini dapat dilakukan dengan menumpuk blok Bagian / Kolom lain ke blok lain yang disetel ke lebar penuh. Ini bisa dilakukan dengan pengaturan di inspektur untuk mengubah lebar konten blok secara independen dari lebar seluruh blok; ini juga dapat ditambahkan sebagai tuas pengubah ukuran yang terlihat, mirip dengan cara kerja baris / kolom Beaver Builder, atau cara kerja blok Gambar di Gutenberg.

Adapun apa yang Anda sebut blok gabungan ini, saya pikir hanya menjaga nama "Kolom" berfungsi, karena itu adalah fungsi paling jelas yang akan dicari orang. Seharusnya tidak sulit untuk menemukan pengaturan latar belakang di inspektur (dan saya membayangkan itu akan menjadi tempat beberapa orang akan melihat di tempat pertama jika ada blok Bagian terpisah dan mereka tidak menyadarinya), dan menggunakan Kolom blok sebagai wadah kolom tunggal seharusnya tidak sulit untuk ditemukan karena penggeser untuk mengubah jumlah kolom harus membuatnya cukup jelas bagaimana melakukannya ... cukup seret ke kiri.

Saya telah berubah pikiran tentang menggabungkan blok Bagian dan Kolom. Untuk mendapatkan fleksibilitas maksimal dengan kolom, akan lebih masuk akal jika setiap kolom menjadi bloknya sendiri: blok Kolom. Ini akan memungkinkan untuk dengan mudah mengontrol pengaturan kolom individu, serta menyeret kolom dari satu baris ke baris lainnya. Tentu saja, karena kolom bergerak dari kiri-ke-kanan (dan membungkus di sebagian besar sistem tata letak), Anda akan memerlukan blok induknya menjadi salah satu yang memasukkan konten ke arah horizontal dan memiliki pembungkusan (bukan arah vertikal standar) dan ini blok induk kemungkinan hanya akan mengizinkan blok Kolom dimasukkan ke dalamnya. Blok ini akan menjadi Row. 2 blok ini akan menggantikan blok Kolom. Tetapi mereka tidak mencakup situasi di mana Anda ingin beberapa baris (seringkali dengan jumlah kolom yang berbeda di dalamnya) berada di latar belakang / wadah yang sama, yang akan dilakukan blok Bagian. Tentu saja, blok Bagian tidak lebih dari sebuah wadah dengan opsi latar belakang, bantalan, dan lebar, dan blok apa pun dapat disisipkan ke dalamnya. Dan untuk tata letak yang lebih kompleks, blok Bagian dapat dimasukkan ke dalam blok Kolom.

Lihat # 6461.

Sebenarnya menurut saya ide minimal 1 kolom bukanlah solusi yang buruk. Faktanya, jika Anda menggunakan inspektur Anda untuk mengubah atribut "min" dari penggeser ke 1, dan memilih salah satu, ini berfungsi seperti yang Anda harapkan.

Namun, secara semantik blok bagian lebih masuk akal. Konten bagian dalam (yaitu bagian dengan lebar maksimal dalam bagian penuh dengan) dapat dicapai dengan menumpuk dua bagian - lebar konten di dalam lebar penuh.

Ide warna latar belakang bagus, tapi ... mungkin sedikit dua spesifik. Saya pikir pendekatan yang lebih umum akan menggunakan kelas kustom di bagian tersebut. CSS front-end dapat menangkapnya dan semua turunannya secara langsung.

Setelah beberapa diskusi di # 6461, saya telah memutuskan bahwa blok Baris + Ide blok kolom bukanlah cara yang tepat untuk melakukannya. Blok Tata Letak yang mirip dengan yang ada di # 5351 (komentar) mungkin akan jauh lebih tidak membingungkan dan jauh lebih fleksibel. Apapun masalahnya, pasti harus ada blok Bagian, dan saya pikir itu harus ditambahkan sebelum rilis WordPress 5.0.

Sedangkan untuk opsi warna latar belakang, menurut saya masuk akal untuk memiliki opsi latar belakang pada Bagian. Hanya memiliki opsi kelas tampaknya agak membatasi. Seringkali, inti dari bersarang di blok Bagian adalah memiliki beberapa hal yang berbagi latar belakang. Selain itu, saya lebih suka jika opsi latar belakang lain seperti gambar latar belakang dan latar belakang gradien diterapkan, karena itu lebih sering diinginkan daripada latar belakang warna solid polos. Blok Bagian Bersarang bahkan akan memungkinkan warna latar belakang diterapkan ke satu blok, yang berarti bahwa opsi warna latar belakang di blok Paragraf mungkin tidak lagi diperlukan.

Adapun blok Bagian bersarang alih-alih memiliki 2 pengaturan lebar terpisah, saya pikir itu bisa berfungsi. Kekhawatiran terbesar yang akan saya miliki adalah jumlah padding tambahan yang akan ditambahkan dengan menyusun blok Bagian, yang mengarah ke opsi padding.

Saya pikir itu penting bahwa blok Bagian memiliki kemampuan untuk menyesuaikan jumlah padding yang digunakannya, atau setidaknya menghapus padding default. Tentu saja, ini menimbulkan pertanyaan tentang bagaimana Anda akan memilih blok Bagian ketika blok lain bersarang di dalamnya. Saya pikir masalah ini akan diselesaikan dengan perbaikan seperti # 6471 dan hal-hal yang sedang dikerjakan di cabang try/alternate-hover-approach .

: +1:

Kami sangat membutuhkan blok baris / kontainer umum, terutama dengan pengaturan lebar.

Idealnya saya pikir pengaturan lain seperti "Warna latar belakang" dan "Warna teks" harus berada di bawah beberapa tab pengaturan "ekstra" pada setiap blok (selain beberapa pengaturan CSS yang berlaku umum lainnya).

Mengenai daya tanggap, saya pikir kita harus menambahkan blok "Responsif" .

Masalah dengan warna latar belakang dan warna teks sederhana: di mana ini berakhir? Di utas ini saja Anda sudah memiliki seseorang yang menyarankan warna tautan. Mengapa tidak warna bingkai, ketebalan, dan gaya? Jujur saja, padding, dan margin paling masuk akal. Bagaimana dengan drop-shadow, gambar latar belakang, opsi pemosisian, dan mode tampilan? Gaya dan ukuran font, tinggi garis dan tinggi minimum? Ada ratusan properti CSS dan mana yang Anda butuhkan akan bervariasi sesuai desain Anda.

Ini harus berupa kelas, yang kemudian dapat Anda gunakan untuk memberi gaya apa pun termasuk elemen turunan, atau daftar properti CSS yang dapat difilter sehingga div tema dapat menghubungkan dan menambahkan yang dia inginkan.

@tmdesigned Ini berakhir pada kontrol WYSYWIG yang lengkap fitur dan intuitif atas gaya, pemformatan, dan tata letak halaman web. Bukankah ini tujuan Gutenberg?

Gutenberg menyediakan konten web WYSYWIG yang segar, terencana dengan baik, canggih, dapat dicetak, dan dapat diperpanjang kepada dunia ... kita harus mencari tahu seberapa besar kita ingin memanfaatkannya sekarang atau kita akan ketinggalan perahu.

Idenya pada akhirnya adalah untuk mengurangi jumlah pekerjaan yang kita lakukan sekarang, apakah itu menulis CSS, menulis penggantian CSS yang diretas, atau melakukan tugas konten berulang.

Tidak semua kelas dapat atau harus ditentukan dengan kelas, terutama jika kelas tersebut ditargetkan dengan buruk atau atribut yang tidak dapat diganti.

Ambil pengaturan numerik yang ditentukan pengguna misalnya. Sulit untuk menentukan kelas untuk setiap nilai dan pengembang blok mungkin tergoda untuk hanya memasukkan nilai langsung ke atribut style .

Jika itu ada sebagai blok dan dapat memiliki gaya CSS yang ditentukan pengguna yang diterapkan padanya, maka idealnya harus ada cara terpadu dan terstandarisasi untuk melakukannya, bahkan jika itu adalah panel kotak teks pasangan kunci / nilai.

Jika Anda mau, Anda dapat membaca metode yang saya sarankan untuk melakukan ini dengan cara yang dapat mengatasi masalah Anda.

Saya membaca saran Anda untuk API dan itu tidak jauh dari apa yang saya katakan tentang pengait tambahan untuk memungkinkan pasangan nilai kunci ditambahkan.

Namun saya pikir poin asli saya masih berlaku. Seperti yang saya katakan, ada ratusan properti dan sementara beberapa lebih umum, daftar seperti itu akan berkembang pesat. Kita bisa pergi ke rute itu, dan mencoba menemukan "kompromi yang baik" seperti dengan fitur TinyMCE yang disertakan vs dihapus di Klasik. Tetapi ada lebih banyak properti yang dimainkan di sini, jadi ini akan menjadi tantangan.

Tetapi yang lebih penting, gagasan untuk menambahkan gaya tingkat blok langsung rusak ketika Anda memperkecil sedikit dan tidak hanya mempertimbangkan satu blok. Saat Anda memiliki beberapa blok yang serupa, di satu halaman atau di seluruh halaman, Anda tidak ingin memasukkan kembali semua nilai itu. Anda akan menginginkan abstraksi ... seperti kelas CSS.

Mengizinkan - atau mendorong - penataan gaya tingkat blok tidak ideal karena tidak dapat digunakan kembali. Anda benar untuk mengatakan bahwa tidak semuanya harus diabstraksi menjadi kelas, tetapi CSS dikembangkan karena suatu alasan dan tidak boleh dibuang begitu cepat.

@tmdesigned Saya menghargai tanggapan Anda. Saya rasa saya memahami kebingungannya, jadi saya akan mencoba menjelaskan.

Tujuannya bukan untuk menghilangkan atau bahkan mengurangi jumlah kelas CSS.

Sasarannya adalah, secara khusus, untuk menyatukan setelan gaya blok yang ditentukan pengguna ke dalam satu UI atau setidaknya satu API.

Pengembang web, pengembang blok, pengembang tema semua masih akan menulis kode CSS ke blok gaya dan blok akan tetap memiliki kelas, atribut, dan ID sehingga pengembang dapat menatanya.

Mereka akan memiliki kelas yang sama persis dengan yang mereka lakukan sekarang dan mereka akan memiliki tata letak yang sama persis seperti yang mereka lakukan sekarang.

TAPI

Saat pengembang blok menyadari bahwa mereka memiliki properti CSS yang dapat / harus dikonfigurasi oleh pengguna ... saat itulah Gutenberg mengambil alih dan memutuskan bagaimana gaya tersebut dimasukkan (dan berpotensi dikendalikan).

Ini akan menghasilkan satu antarmuka umum (untuk pengembang dan pengguna) dalam hal mengontrol secara non-programatik konfigurasi umum berbasis gaya konten halaman web.

Ini memberi pengguna dan pengembang satu cara yang konsisten untuk melihat, menambahkan, menghapus, memodifikasi, dan mengganti gaya blok yang, pada akhirnya, semuanya mengarah ke properti CSS sederhana.

Maaf telah menimbulkan begitu banyak kebisingan di utas ini. Kami mungkin harus melanjutkan diskusi lebih lanjut ke masalah terkait.

Edit Catatan:

Saya lupa membahas poin tentang abstraksi.

Menit saat pengguna perlu menerapkan gaya yang sama persis ke blok yang sama persis dua kali adalah saat yang tepat saat setelan gaya yang ditentukan pengguna harus ditinggalkan untuk kelas CSS (untuk blok itu).

Dengan kata lain, pengaturan gaya yang ditentukan pengguna menyediakan mekanisme yang konsisten bagi pengguna untuk menyesuaikan blok sesuai keinginan mereka, apakah itu hal unik satu kali (sebagaimana mestinya) atau 100 kali pada setiap halaman, dan bagaimana Anda memilih untuk menyusun itu masih sepenuhnya terserah Anda.

Saya pikir kami sangat setuju. Saran saya di posting pertama adalah memiliki kait untuk menambah / menghapus kontrol. Saya tidak menentang penyesuaian gaya pengguna tingkat blok, hanya sulit untuk memilih "gaya yang layak dimiliki secara default pada blok bagian umum" tanpa daftar yang bertambah secara eksponensial. Memiliki sedikit kontrol boleh-boleh saja, terutama jika memungkinkan penambahan kontrol lain. Bagaimanapun, saya terkejut margin dan padding tidak akan lebih membantu secara universal daripada warna latar belakang untuk blok bagian.

FWIW, saya suka ide Anda membuat class menjadi output, sehingga masih dapat ditimpa tanpa harus menggunakan! Penting.

@rchipka @tmdesigned Saya tahu ini sudah berakhir dua minggu yang lalu, tetapi apakah Anda tertarik untuk membahas lebih banyak detail tersebut di edisi lain? Saya pikir akan bermanfaat untuk lebih memperhatikan percakapan ini.

Melihat lagi blok ini berdasarkan percakapan sebelumnya.

Cara termudah untuk berbagi ide saya adalah melalui prototipe: https://wp.invisionapp.com/share/PQJPPAX4JZW

Beberapa catatan:

• Berdasarkan jajak pendapat singkat: https://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343 Saya telah mengubah nama dari _Section_ menjadi _Container_.
• Saya telah menghapus pengaturan kolom, karena wajar jika orang-orang ingin mencampur-dan-mencocokkan tata letak kolom dalam bagian tertentu, seperti yang diilustrasikan oleh @jvisick.
• Selain warna latar belakang, saya telah menambahkan dukungan gambar latar belakang. Pengaturan didasarkan pada fitur Gambar Latar Belakang inti yang ada.
• Haruskah kita membiarkan orang menyarangkan blok kontainer di blok kontainer?

@melchoyce Tampak hebat!

Salah satu fitur bagus yang ingin saya lihat adalah pilihan pada inspektur untuk mengganti elemen HTML blok antara <aside> , <div> , dan <section> .

Kemampuan untuk membuat wadah bersarang harus diizinkan, menurut pendapat saya. Tidak hanya akan berguna dalam konteks memiliki area berwarna berbeda dalam satu bagian semantik menggunakan saran elemen HTML yang disarankan di atas, tetapi juga akan berguna dalam situasi di mana Anda ingin memberi satu blok latar belakang ketika tidak ada pilihan warna latar belakang itu sendiri.

Fitur bagus lainnya adalah latar belakang gradien, karena itu tampaknya cukup populer di beberapa desain.

@melchoyce +1 karena dapat menyarangkan wadah.

@SuperGeniusZeb dapat mengubah elemen HTML telah ada di pikiran saya juga. Mungkin dropdown untuk pilihan elemen semantik?

@jvisick Ya, itulah yang saya pikirkan. Beaver Builder dan Elementor keduanya memiliki pengaturan seperti itu untuk baris / bagiannya.

@ Melchoyce Saya pikir kontainer harus dapat

Tidak ada alasan untuk menambahkan batasan bersarang ke blok penampung generik.

Saya memahami nilai elemen HTML semantik, tetapi saya juga bertanya-tanya apakah ada cara untuk mendelegasikan fungsionalitas itu ke plugin, entah bagaimana caranya sehingga tersedia sebagai opsi untuk pengguna tingkat lanjut, tetapi pengguna rata-rata tidak perlu memikirkannya. Karena begitu Anda menambahkannya, Anda tidak hanya bertanggung jawab untuk menyediakan fungsionalitas, tetapi juga bertanggung jawab untuk mendidik pengguna tentang implikasi semantik… yang seringkali sangat situasional.

@kmkmds Poin yang bagus. Saya pikir ini adalah tempat yang salah untuk menyetel tag penampung.

Blok container harus berfungsi sebagai container umum tanpa arti semantik.

Arti semantik harus disediakan oleh fungsionalitas templat blok (masa depan), sehingga <aside> konten bisa menjadi satu bagian dari templat dan <section> lainnya.

Dengan cara ini, pengguna dapat mengatur konten dalam penampung sesuka mereka (pada tingkat kedalaman apa pun), tanpa memengaruhi makna semantik.

Saya setuju bahwa kemampuan untuk menukar elemen HTML tampaknya sedikit lebih maju bagi kebanyakan orang, dan mungkin tidak termasuk dalam pengaturan dasar Gutenberg.

Arti semantik harus disediakan oleh fungsionalitas templat blok (masa depan), sehingga <aside> konten bisa menjadi satu bagian dari templat dan <section> lainnya.

Ini pasti akan bagus untuk dijelajahi.

Saya tidak setuju dengan poin yang dibuat untuk menjaga dasar UX tetap sederhana tetapi saya kemudian akan bertanya di mana Anda akan menambahkan <section> , <nav> , <header> , dll .. elemen pembungkus? Blok penampung generik, yang pada dasarnya adalah elemen pembungkus tampaknya merupakan pilihan yang wajar. Itu mungkin lebih disukai daripada blok duplikat untuk masing-masing kasus ini. Standarnya bisa <div> dan pengguna tidak perlu menyentuh pengaturan kecuali diperlukan.

Bagaimana jika opsi untuk elemen HTML berfungsi mirip dengan pengaturan alignwide / full di mana array elemen yang didukung dapat diatur dari tema atau plugin?

@jvisick Idealnya, elemen pembungkus ini akan dibuat dengan "template tata letak blok" halaman / posting.

Dengan menggunakan template tata letak blok, Anda dapat menyiapkan sekumpulan blok penampung default dan memberikan pengaturan (dalam kode) untuk nama tag yang dihasilkan dari blok penampung tersebut.

@rchipka Saya melihat dari mana Anda berasal dalam menggunakan template tata letak yang memberi pengguna area yang telah ditentukan sebelumnya untuk mengelola konten. Saya melihat ini lebih dari perspektif menggunakan Gutenberg sebagai pembuat halaman untuk halaman yang tidak ditentukan dan di mana dapat mengatur jenis elemen HTML apa yang digunakan dari editor akan sangat membantu. Saya pikir kedua skenario itu penting.

Yang mengatakan, saya setuju dengan @melchoyce bahwa pengaturan elemen HTML tidak diperlukan untuk menjalankan awal blok penampung tetapi saya pikir itu adalah sesuatu yang perlu dijelajahi dalam fase 'pembuat halaman' berikutnya.

Bagian pada dasarnya adalah 1-kolom .. yah, kolom.

Saya memperhatikan blok Kolom 3.0.0 (beta) tidak mengizinkan 1-kolom pada slidernya.

Tidak yakin apakah akan lebih baik untuk tetap menggunakan blok Kolom saja dan menggabungkan implementasi ini. Apa sisi negatifnya?

Satu hal yang baik untuk ditambahkan adalah toggle apakah wadah (bagian) harus memiliki lebar penuh atau berisi. Jika berisi itu harus menghormati content_width set dalam tema (# 5650), jika tidak, itu harus lebar penuh. Saya pikir sebagian besar pembuat halaman di luar sana memiliki fitur ini.

Yup, itu sudah termasuk dalam Bilah Alat Cepat di maket terakhir saya.

@melchoyce Ingatlah akan ada situasi di mana bagian / blok kontainer itu sendiri harus lebar penuh, tetapi konten di dalam blok bagian / kontainer tidak boleh. Bagaimana ini ditangani?

Saya pikir secara default, wadah itu sendiri bisa menjadi lebar penuh, tetapi konten apa pun di dalamnya yang tidak mendukung lebar penuh (seperti gambar / blok sampul) akan tetap dibatasi ke lebar editor.

@ Melchoyce Dengan asumsi saya memahami Anda dengan benar, itu berarti kontrol lebar pada blok Kontainer hanya akan mempengaruhi latar belakang kontainer, dan tidak pernah isinya? Itu masuk akal. Terima kasih telah menjelaskan. : +1:

Yup, itulah yang saya pikirkan!

Tidak yakin apakah itu dibahas, tetapi suatu bagian bisa menjadi elemen HTML "bagian" dan juga menjadi "artikel", "div", atau yang lainnya, bukan? Akan menyenangkan jika itu bisa dipilih
Ini juga mungkin membuat blok "baris" tidak perlu, saya kira

Menerapkan ini di plugin

var el = wp.element.createElement,
    registerBlockType = wp.blocks.registerBlockType,
    InnerBlocks = wp.editor.InnerBlocks;

registerBlockType( 'nbrummerstedt/section', {
    title: 'Section',
    icon: 'universal-access-alt',
    category: 'layout',
    attributes: {},
    edit: function( props ) {   
        return el( 'section', {className: props.className},
            el( InnerBlocks )
        );
    },
    save: function( props ) {
        return el( 'section', {className: props.className }, 
            el( InnerBlocks.Content )
        );
    }
} );

@eddr Ini telah dibahas: https://github.com/WordPress/gutenberg/issues/4900#issuecomment -392925877

Saya masih berpikir dropdown untuk memilih tag HTML yang digunakan adalah ide yang bagus. Ini terasa seperti cara termudah untuk mengintegrasikan elemen HTML semantik seperti <aside> dan <section> tanpa membuat banyak blok yang terlalu mirip.

@nbrummerstedt Implementasi dasar awal yang bagus, tetapi blok tersebut sekarang disebut blok Container dan harus menggunakan <div> sebagai elemennya, meskipun idealnya (seperti yang disebutkan di atas dan dalam komentar sebelumnya), Anda akan dapat mengubah HTML elemen yang digunakan dari <div> hingga <section> , <aside> , dan bahkan mungkin <article> .

Berikut adalah versi revisi dari implementasi Anda:

( ( blocks, editor, element ) => {
    const el = element.createElement,
        { registerBlockType } = blocks,
        { InnerBlocks } = editor;

    registerBlockType( 'nbrummerstedt/container', {
        title: 'Container',
        icon: 'universal-access-alt',
        category: 'layout',
        attributes: {},
        edit: ( props ) => {    
            return el( 'div', {className: props.className},
                el( InnerBlocks )
            );
        },
        save: ( props ) => {
            return el( 'div', {className: props.className }, 
                el( InnerBlocks.Content )
            );
        }
    } );
} )( window.wp.blocks, window.wp.editor, window.wp.element );

Mengapa ini dihapus dari pencapaian WordPress 5.0, @mtias? Ini sepertinya sesuatu yang mungkin harus dibuat menjadi rilis awal, hanya karena betapa bermanfaat dan sederhananya itu. Banyak blok tidak memiliki pengaturan latar belakang karena diasumsikan bahwa Anda akan menggunakan blok Container untuk itu. Bahkan tidak sulit untuk menerapkan blok ini, bukan? Saya tidak mengerti mengapa ini harus didorong kembali ke rilis pasca-WordPress 5.0.

Pada catatan lain, saya baru-baru ini memeriksa Oxygen dan terkesan dengan sistem tata letak berbasis flexbox. Bagaimana jika blok Penampung menerapkan beberapa fitur ini? Saya yakin ini bisa sangat kuat dan memberikan cara alternatif untuk memiliki tata letak selain blok Kolom ... mungkin itu bahkan bisa membuat blok Kolom tidak perlu?

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

Saya sangat merekomendasikan untuk memeriksanya. Sebenarnya, saya sarankan untuk melihat Oxygen sepenuhnya. Ini sangat berbeda dari semua plugin pembuat halaman lainnya, dan saya pikir ada banyak ide bagus di sana yang dapat digunakan Gutenberg.

Saya sangat setuju, ini harus dalam rilis 5.0, Anda memerlukan wadah untuk menghindari solusi hacky menggunakan blok kolom.

Saya juga berpikir bahwa blok ini harus segera tersedia daripada nanti. Banyak agensi pengembangan WordPress menunggu blok ini sebelum membangun dengan Gutenberg.

@ dingo-d dan @ericvalois Ya, saya menahan diri untuk tidak menggunakan Gutenberg untuk apa pun kecuali posting blog justru karena kurangnya 3 hal: kolom responsif, kolom dengan lebar tidak sama, dan blok Container.

Untuk menguraikan apa yang saya katakan sebelumnya tentang blok Kontainer yang mengadopsi hal-hal yang dilakukan Oxygen, saya pikir blok Kontainer dapat memiliki opsi untuk mengubah arah aliran blok bersarangnya dari vertikal default ke horizontal. Mungkin juga ada opsi perataan vertikal dan horizontal seperti yang dimiliki Oxygen. Ini akan sangat kuat - terutama jika dikombinasikan dengan kemampuan untuk mengubah opsi ini secara responsif seperti yang diizinkan oleh kebanyakan plugin pembuat halaman.

Tentu saja, ada masalah penting bahwa blok Container yang menggunakan perataan / tata letak berbasis Flexbox tidak akan mengizinkan blok yang diselaraskan dengan float untuk disarangkan langsung di dalamnya. Tapi saya pikir ada solusi sederhana untuk itu: tambahkan kemampuan agar Container menggunakan layout standar CSS display: block atau layout Flexbox. Mode standar display: block akan menjadi default, karena itulah yang akan digunakan oleh dokumen root. Mengaktifkan mode tampilan flexbox akan membuat semua opsi perataan rapi muncul di inspektur. Selain itu, Anda jelas ingin memberi 2 mode tata letak nama yang berbeda di inspektur agar lebih ramah pengguna. Saya tidak yakin Anda akan menyebutnya apa. Mungkin "Standar" dan "Fleksibel"?

Mengizinkan blok Container untuk menggunakan mode yang mendukung float atau mode dengan opsi penyelarasan / tata letak yang lebih baik akan sangat berguna. Anda dapat menyusun blok Container untuk menggunakan kedua jenis tata letak jika diperlukan. Tambahkan ini ke kemampuan lain yang dapat dimiliki blok Penampung (opsi latar belakang, kemampuan untuk memilih tag HTML untuk menambahkan makna semantik tanpa harus menggunakan blok HTML Khusus, dll.) Dan blok Penampung akan menjadi salah satu yang paling penting dan blok berguna di inti WordPress.

Khususnya, jika blok Kontainer yang memiliki dua mode tata letak terdengar seperti terlalu banyak fitur (dan menurut saya itu tidak akan menjadi masalah), maka mungkin ada dua blok terpisah:

• blok Container standar yang mendukung float tetapi tidak memiliki semua opsi perataan / tata letak lanjutan
• blok Advanced Container (atau Advanced Layout atau Flexible Layout atau apa pun yang Anda sebut itu) yang menggunakan tata letak Flexbox dan menyediakan semua opsi yang rapi

Saya sarankan untuk melihat video dokumentasi Oxygen ini untuk melihat bagaimana sistem tata letaknya bekerja. Ini sangat mengesankan:

https://www.youtube.com/watch?v=NnSfR-YFcQI

Saya pikir ada banyak potensi di sini untuk membuat Gutenberg sangat kuat . Tentu saja, untuk implementasi awal saya hanya mengharapkan blok Container memiliki opsi latar belakang, kemampuan untuk mengubah elemen HTML yang digunakan, dan opsi untuk membuat Container menjadi lebar penuh (tetapi bukan konten di dalamnya). Bahkan mungkin hanya opsi latar belakang.

Sebenarnya, hanya memiliki satu blok Penampung yang bahkan tidak memiliki opsi apa pun masih berguna, karena mempermudah gaya sekelompok blok melalui CSS.

Penting untuk memikirkan Gutenberg tidak hanya berhenti setelah 5.0. Ini adalah blok yang sangat berguna dan akan dieksplorasi, tetapi untuk tahap pertama, fokus pada pengeditan tidak terlalu diperlukan. Ketika proyek berkembang melampaui pengeditan sederhana ke tata letak, tidak diragukan lagi solusi diperlukan di sana. Tidak ada yang mengatakan ini tidak akan dibuat, ini masalah memprioritaskan apa itu editor dan apa yang kemudian dimasukkan ke tahap dua.

Tapi masalahnya, mayoritas orang menggunakan Gutenberg untuk tujuan tata letak, bukan untuk menulis posting.

Orang-orang terbiasa menulis postingan seperti dokumen word, jadi mereka menonaktifkan Gutenberg di halaman Post.

Tapi masalahnya, mayoritas orang menggunakan Gutenberg untuk tujuan tata letak, bukan untuk menulis posting.

Sumber data manakah yang Anda dasarkan pada asumsi ini?

Saya telah berbicara dengan beberapa orang selama WCEU di Beograd, mereka semua setuju bahwa mereka merasa aneh menulis posting dengan Gutenberg dan oleh karena itu mereka menonaktifkannya di Postingan.

Berbeda dengan apa yang telah dilihat @ dingo-d, saya hanya menggunakan Gutenberg untuk posting. Saya benar-benar menemukan pengalaman untuk pasca-pembuatan jauh lebih bagus di Gutenberg daripada di Editor Klasik. Sebagian karena sifatnya yang lebih modular dan kontrol kontekstual, dan sebagian lagi karena tidak ada lagi tag <p> yang tidak terlihat yang disisipkan di mana-mana. Itu selalu membuatku kesal.

Saya membutuhkan blok Kontainer (bahkan satu tanpa opsi apa pun) dan blok Kolom yang layak (atau blok tata letak lainnya) untuk menggunakan Gutenberg untuk pembuatan halaman genap. Sepertinya blok Kolom akan mendapatkan semacam responsivitas dasar (lihat # 6048), jadi itu berarti kurangnya blok Container yang menghalangi saya untuk menggunakan Gutenberg dalam lebih banyak konteks.

Saya tahu blok Container jelas akan ditambahkan di beberapa titik (mungkin tidak lebih dari WordPress 5.1), tetapi saya sangat percaya bahwa itu harus ditambahkan sebelum WordPress 5.0 keluar. Bahkan dalam konteks menulis posting, Container dapat berguna untuk sesuatu seperti <aside> (jika memiliki fitur dropdown pemilihan elemen HTML) untuk semantik tambahan. Saat ini, jika Anda ingin membungkus apa pun di elemen HTML lain untuk semantik tambahan, Anda harus menggunakan blok HTML Kustom, yang berarti Anda tidak dapat memanfaatkan fitur blok Paragraf untuk paragraf apa pun di blok HTML Kustom tersebut, atau fitur apa pun dari blok Gambar untuk gambar apa pun di blok HTML Khusus itu, dan lain-lain.

@tokopedia

Tidak ada yang mengatakan ini tidak akan dibuat, ini masalah memprioritaskan apa itu editor dan apa yang kemudian dimasukkan ke tahap dua.

Menurut pendapat saya, blok Kontainer benar-benar sesuatu yang termasuk dalam fase satu.

Yang menurut saya agak aneh adalah blok Kolom sepertinya akan membuatnya menjadi WordPress 5.0 (mungkin masih dengan label "(Beta)", namun blok Container mungkin tidak? Jika fokus saat ini adalah pada penulisan posting, lalu mengapa blok Kolom ditambahkan tetapi tidak ada blok Container? Blok Container menurut saya jauh lebih berguna dalam konteks posting daripada blok Kolom. Dan tentu saja, itu juga memiliki banyak manfaat di konteks pembuatan halaman juga.

Jika blok Container tidak membuatnya menjadi WordPress 5.0, itu berarti itu tidak akan keluar sampai 5.1, yang membuatnya tidak dapat digunakan oleh kebanyakan orang selama berbulan-bulan. Saya ingin Gutenberg berhasil, dan saya merasa tidak ada alasan untuk menahan rilis sesuatu yang mendasar seperti blok Container hingga WordPress 5.1. Demi kesan pertama yang baik, saya bahkan akan merekomendasikannya untuk ditambahkan sebelum callout WordPress 4.9.8.

Saya tidak mengharapkannya memiliki semua fitur yang disarankan orang; keberadaannya saja sudah cukup untuk menyelesaikan banyak kasus penggunaan umum yang saat ini tidak tercakup kecuali melalui solusi yang agak rumit menggunakan blok Kolom dengan penggeser Kolom yang diatur secara manual ke 1. Dan kemudian, hanya memiliki satu opsi seperti opsi warna latar belakang akan membuatnya jauh lebih berguna.

Saya setuju ini adalah blok yang keren dan berguna, tetapi ini selalu lebih tentang fase 2 proyek dan kami benar-benar perlu fokus atau kami tidak akan pernah mengirim. Kami membangun infrastruktur blok bersarang karena penting untuk mendapatkan abstraksi yang benar, dan untuk memungkinkan orang membuat blok tata letak kustom mereka sehingga blok inti yang sebenarnya seperti ini tidak terlalu penting. Fokusnya adalah mendapatkan UI bersarang dan anak secara umum (menggunakan _Columns_ sebagai kelinci percobaan).

Masalah ini juga telah terbuka untuk diperebutkan selama lima bulan sekarang dan belum ada proposal implementasi yang solid yang mencakup hal-hal seperti warna, lebar, arah blok vs kolom bersarang, tumpang tindih dengan gambar sampul, dll. Seperti berdiri, kita bisa Tidak memprioritaskannya di atas pekerjaan tujuan umum lain yang perlu kita lakukan, dan pemberitahuan "coba" yang akan datang di WordPress. Itu tidak berarti bahwa itu tidak akan berhasil, terutama jika seseorang ingin mengajukan saran dalam kode.

Selain itu, masalah terbesar bagi saya adalah tidak jelas - hanya terlihat dari percakapan di sini - pengalaman pengguna yang ideal untuk berkomitmen pada implementasi. Hal-hal seperti mengekspos tag html tampaknya terlalu rumit dan tidak intuitif bagi pengguna biasa. Pengertian container adalah sesuatu yang membutuhkan pengujian yang lebih luas untuk melihat apakah itu abstraksi tata letak terbaik, yang, sekali lagi, seharusnya menjadi sesuatu yang harus dipikirkan dalam fase fokus berikutnya. Ada juga beberapa yang tidak diketahui tentang bagaimana blok semacam itu akan menurunkan gaya ke blok sembarang di dalamnya - relatif mudah untuk memperhitungkan blok inti, tetapi bukan blok sembarang.

Pada saat yang sama, pengembang yang ingin menawarkan blok khusus harus memiliki waktu yang mudah untuk menggabungkannya (seperti cuplikan yang ditunjukkan di atas) dengan tag apa pun yang mereka inginkan dengan menggunakan InnerBlocks dan mengumpulkan umpan balik pengguna. Jadi ada sedikit tekanan pada inti yang memiliki blok seperti itu (dan harus mempertahankannya). Semua yang dikatakan, siapa pun harus merasa bebas untuk memberikan saran melalui PR dan membantu pengguna mengujinya. Saya akan baik-baik saja dengan menambahkannya ke plugin sebagai "eksperimental" dengan gagasan bahwa itu mungkin ditarik untuk 5.0.

@SuperGeniusZeb Oxygen cukup keren! Pasti harus dilihat untuk beberapa eksplorasi ini.

Karena penasaran, apa yang terjadi jika tema dan plugin menambahkan blok Bagian mereka sendiri, dan pengguna menonaktifkan plugin atau mengubah tema? Apakah ada semacam penggantian? Atau apakah pengguna kehilangan kontennya?

@tomusborne Ada masalah tentang situasi seperti itu: # 7811.

Ah! Saya tidak tahu ini dibahas di sini. Jadi saya juga membuat plugin karena saya membutuhkan ini.

https://github.com/marcusig/gutenberg-section-block

Saya telah mengamati utas ini dan menghargai semua pemikiran yang masuk ke dalamnya. Saya baru-baru ini merilis blok kontainer di plugin Blok Atom yang memiliki margin, paddings, lebar kontainer, dan gambar latar belakang serta opsi warna. Saya harap ini membantu dan dapat menahan kita sampai blok inti tiba di kemudian hari!

Setelah masalah ini .. Saya telah membuat blok "Container" yang memungkinkan untuk memilih struktur kolom, dan opsi lainnya.
Jika itu dapat membantu meningkatkan blok "Kolom", atau membuat yang baru pada intinya, ada di sini: https://github.com/MarieComet/WP-container-block/

@MarieComet Itu bagus, tapi menurut saya blok Anda harus dibagi menjadi 2 blok yang berbeda. Yang pertama harus berupa blok Kolom dengan semua opsi tata letak struktur berbasis kolom. Yang kedua adalah blok Penampung yang memiliki opsi latar belakang dan opsi tata letak yang tidak berbasis kolom, seperti kemampuan untuk menggunakan flex untuk menata letak anak secara horizontal daripada secara vertikal dan menyelaraskan dan membenarkan mereka menggunakan opsi yang sesuai dengan properti CSS Flex.

Anda mungkin juga dapat menggunakan blok Kontainer untuk mengganti blok Kolom individu, meskipun mungkin ada beberapa opsi yang Anda inginkan pada Kolom yang tidak masuk akal pada suatu Bagian.

Saya telah menyadari bahwa masa depan membuat tata letak dengan HTML dan CSS tidak selalu menggunakan kolom seperti kebanyakan pembuat halaman, tetapi juga menggunakan CSS Flex dan Grid untuk menampilkan konten menggunakan lebih sedikit <div> s di markup dan memiliki gaya yang lebih fleksibel dan lebih bersih. Saya terutama terinspirasi oleh apa yang dilakukan Oxygen. Saya berbicara tentang Oksigen dalam komentar ini .

Masalah ini bukan tentang mengganti blok kolom sekarang. Penting untuk tetap fokus pada apa masalah ini, blok bagian.

@karmatosed @melchoyce Ngomong-ngomong, bukankah masalah ini harus diganti namanya? Kami berhenti menyebutnya "Bagian" dan beralih ke "Penampung" untuk menghindari kebingungan dengan elemen <section> .

Namanya belum diputuskan, jadi kita semua baik-baik saja pergi apa adanya.

Saat ini saya mencoba menerapkan tema bersama dengan editor Gutenberg.

Tata letak situs web memiliki area berbeda dengan latar belakang berbeda, yang berisi beberapa item seperti paragraf atau daftar. Ini untuk tujuan tata letak dan untuk tujuan navigasi. Blok bagian / penampung harus berfungsi sebagai jangkar / harus memiliki ID CSS yang unik.

Saya tidak dapat menyelesaikan tema ini tanpa "meretas Gutenberg" dengan membuat blok sendiri. Itu bisa dilakukan dengan yang satu ini sebagai blok inti. Saya tidak akan menggunakan editor Gutenberg hanya untuk teks biasa dan tata letak sederhana - tata letak / desain masa depan saya harus dilakukan bersama dengan tema dan sistem blok Gutenberg.

Saya sangat berharap, topik ini mendapat prioritas yang lebih tinggi.

Saya menggunakan blok kontainer pihak ketiga di semua tempat (misalnya Blok Atom), dalam kombinasi dengan blok Kolom. Mereka sangat berguna dan blokir saya yang paling populer. Saya merasa aneh bahwa itu akan dianggap nanti di masa depan atau sebagai tambahan; perlu menjadi inti.

Jika tidak, saya hanya akan secara manual membangun wadah dalam tampilan HTML, namun itu mengganggu / tidak efisien karena tampilan HTML adalah menu tambahan yang diklik. Ada pintasan keyboard untuk tampilan HTML ... shift + option + cmd + M ... yeesh. Dan itu bahkan tidak bolak-balik. Menekan pintasan lagi tidak akan menghasilkan apa-apa. Untuk kembali ke tampilan WYSIWYG, Anda harus melalui menu. Sakelar sakelar besar dan tebal di toolbar utama akan sangat bagus.

Adakah yang membuat katalog / sedang mempertahankan daftar implementasi yang saat ini di alam liar? Saya pikir itu juga membutuhkan semacam matriks parameter "sesuatu dilakukan dengan benar, dan salah". Misalnya menentukan unit hardcode (px) untuk paddings / margin terkait (salah), ketika unit mungkin harus menjadi pilihan kiri ke pengguna (kanan), dll.

https://editorblockswp.com/library/ memiliki beberapa di katalog, tetapi untuk mendorong masalah ini ke depan, sepertinya sesuatu yang spesifik untuk Bagian / Kontainer perlu terjadi.

Menurut pendapat saya, blok Kontainer dasar setidaknya memiliki opsi berikut:

• gambar latar belakang
• warna latar belakang
• kemampuan untuk melapisi warna latar belakang pada gambar dan mengontrol opasitas
• opsi padding dan margin untuk semua 4 arah, dengan kemampuan untuk mengganti unit yang digunakan secara individual untuk setiap nilai
• dukungan untuk float left, float right, wide, dan full alignment
• kemampuan untuk mengontrol lebar maksimum blok yang ditampung entah bagaimana
• kemampuan untuk memilih elemen html yang digunakan oleh penampung

Selain itu, saya lebih suka memiliki yang berikut ini:

• Opsi tata letak fleksibel CSS: kemampuan untuk mengatur arah aliran konten dari atas-bawah ke kiri-kanan, kanan-kiri, dan bawah-atas; dan kemampuan untuk mengatur kesejajaran konten secara vertikal dan horizontal
• tentu saja, menggunakan opsi fleksibel tidak kompatibel dengan perataan float, jadi blok harus memiliki setidaknya 2 mode tata letak: standar dan fleksibel, atau harus ada blok Kontainer Flex yang terpisah
• ukuran font dan opsi warna untuk menyetel default untuk konten dalam wadah dan menghindari harus mengaturnya untuk setiap blok yang ada secara individual

Felix Arntz baru saja menerbitkan postingan blog tentang penerapan blok bagiannya.
Saya suka gambar latar yang responsif.
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

Dalam beberapa minggu terakhir saya telah bereksperimen dengan penerapan Marc Lacroix, yang berfungsi dengan baik, tetapi tampaknya rusak di gutenberg 3.9.0 https://github.com/marcusig/gutenberg-section-block

Saya telah memikirkan hal ini selama beberapa waktu. Fakta bahwa begitu banyak implementasi telah muncul untuk itu berarti itu cukup berharga dan mungkin lebih baik bagi inti untuk menawarkan mekanisme yang konsisten untuk menghindari fragmentasi. Kekhawatiran utama saya adalah sekitar kompleksitas blok "bagian" bagi pengguna.

Saya mengusulkan memulai dengan sangat sederhana, hanya dengan sebuah wadah (satu area InnerBlocks), keselarasan lebar dan penuh, dan pengaturan untuk warna latar belakang (tidak ada gambar, dll - kami memiliki "Cover" untuk itu).

Kami tidak punya banyak waktu untuk melakukannya jika kami menginginkannya di 5.0.

@mtias Jika mengekspos sebuah blok Container ke pengguna akhir merupakan suatu kekhawatiran, maka mungkin setiap blok seharusnya hanya memiliki Container atau Pengaturan Container secara default.

Kemudian kita tidak perlu khawatir tentang mengajari pengguna akhir bahwa mereka perlu membungkus sesuatu dalam wadah agar memiliki hal-hal tertentu seperti gambar latar belakang.

Saya pikir ini sebenarnya ide yang bagus karena orang yang ingin memperluas atau membungkus blok sewenang-wenang akan memiliki tempat yang jelas untuk melakukannya, dan pengguna akhir akan terbiasa dengannya karena ada di setiap blok.

Mungkin "Pengaturan Penampung" bisa menjadi tab di samping "Pengaturan Blokir". Ini akan menjadi tempat (yang dapat diperluas) bagi pengembang untuk mampir (atau menyaring) hal-hal seperti pengaturan gambar latar belakang, pengaturan lebar, dll.

Ini juga akan memberi pengembang tempat untuk meletakkan pengaturan yang lebih kompleks yang dapat diterapkan ke hampir semua blok, seperti kontrol responsif / breakpoint.

@rchipka Secara teknis sebagian besar blok dibungkus dengan div induk dan jenis pengaturan tingkat blok yang Anda gambarkan adalah kemampuan blok apa sekarang.

Kekuatan penampung tidak persis terletak pada satu blok, melainkan memungkinkan Anda untuk menambahkan blok lain di dalam penampung, membuat tata letak, bagian, dan struktur halaman yang lebih kompleks.

@mikemcalister Poin yang bagus, pengguna akhir masih memerlukan cara untuk mengelompokkan / mengatur pohon blok secara visual.

Saya pikir filosofinya tetap sama. Jika editor memiliki mekanisme pengelompokan blok gaya pohon (yaitu tanpa antarmuka "Blok Penampung"), maka "Pengaturan Penampung" untuk setiap blok anak akan mencerminkan pengaturan dari kelompok itu (yaitu tingkat di pohon).

Sekali lagi, satu-satunya poin dari ide ini adalah untuk mengurangi jumlah langkah yang terlibat untuk pengguna akhir, dan karena itu juga mengurangi kurva pembelajaran dan meningkatkan kemampuan untuk dapat ditemukan.

Saya pikir masalah utamanya adalah saat ini Gutenberg sangat terbatas pada konten posting / halaman standar. Tanpa blok Bagian / Kontainer, kami tidak memiliki cara untuk mengizinkan pengguna membangun halaman depan dengan bagian lebar penuh (dengan latar belakang warna solid / gradien atau gambar latar lebar penuh) dengan semua jenis konten di dalamnya (semoga melalui blok bersarang).

Bagian / blok kontainer akan sempurna di sini. Bahkan yang dasar yang dapat diperpanjang dengan lebih banyak kontrol oleh tema / plugin. Saya ingin mendapatkan beberapa pengaturan penyelarasan di sana juga. Kami sudah melakukan sesuatu dengan CMB untuk memiliki pembuat halaman semu tepat di halaman, tetapi sangat berharap Gutenberg dapat membuat ini semua lebih fleksibel untuk semua orang.

@JiveDig Saya tidak berpikir siapa pun, termasuk tim Gutenberg, menentang semacam mekanisme wadah blok.

Keraguan utama dari tim Gutenberg (dalam kasus ini dan banyak lainnya) adalah untuk menjaga antarmuka inti tetap pada tingkat kompleksitas Squarespace dari sudut pandang UI / UX.

Untuk menerapkannya pada inti, tampaknya masalah utama adalah menemukan cara agar hal ini dapat direpresentasikan tanpa membebani pengguna akhir.

Meskipun, menurut pendapat saya, ini bukan masalah besar, "Blok Kontainer" memang memberikan beban kecil pada pengguna akhir dengan membutuhkan pengetahuan tentang tujuan dan penggunaannya.

Itulah mengapa saya mengusulkan konsep "pengelompokan" sebagai analogi yang lebih mudah didekati dengan "wadah" untuk pengguna akhir.

Pengguna akhir tidak akan berpikir dalam hal membungkus blok dalam wadah dan sebaliknya akan berpikir dalam hal mengelompokkan blok bersama-sama, yang tampaknya lebih intuitif.

Dengan cara ini, pengguna akhir tidak perlu mengetahui apa pun sebelumnya untuk mengelompokkan blok dan menerapkan pengaturan ke grup itu.

Tentu saja, "grup" ini akan berfungsi persis seperti blok Container secara internal, itu hanya antarmuka ujung depan yang lebih terintegrasi dan intuitif.

@rchipka Cara yang sangat mudah untuk mendekatinya adalah dengan memilih satu atau lebih blok dan mengklik opsi "Pindahkan blok yang dipilih ke dalam blok Penampung" di menu "lainnya". Dengan cara ini pemblokiran tidak memerlukan panel setelan _additional_.

Ya, blok bagian harus menjadi inti. Merender div sederhana dalam HTML sudah cukup. Tetapi karena ada ratusan atribut yang dapat ditawarkan, saya sangat menyarankan bahwa dua atribut yang harus ditawarkan adalah KELAS dan ID (dengan ID menjadi yang paling tidak kritis). Dengan cara itu elemen-elemen dapat diatur dalam CSS di tempat yang seharusnya.

-
Mode Wes
Sejarah Rahasia Orang American River
http://peoplesriverhistory.us

Dikirim dari Apple saya] [e

Pada 12 Okt 2018, pada 8:09 AM, Matias Ventura [email protected] menulis:

Saya telah memikirkan hal ini selama beberapa waktu. Fakta bahwa begitu banyak implementasi telah muncul untuk itu berarti itu cukup berharga dan mungkin lebih baik bagi inti untuk menawarkan mekanisme yang konsisten untuk menghindari fragmentasi. Kekhawatiran utama saya adalah sekitar kompleksitas blok "bagian" bagi pengguna.

Saya mengusulkan memulai dengan sangat sederhana, hanya dengan wadah dan pengaturan untuk warna latar belakang (tidak ada gambar, dll - kami memiliki "Sampul" untuk itu).

Kami tidak punya banyak waktu untuk melakukannya jika kami menginginkannya di 5.0.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Sekali lagi, setiap blok harus memiliki kemampuan untuk mengatur atribut kelasnya. Terlepas dari jenisnya.

-
Mode Wes
Sejarah Rahasia Orang American River
http://peoplesriverhistory.us

Dikirim dari Apple saya] [e

Pada 12 Oktober 2018, pukul 8:40, Robbie Chipka [email protected] menulis:

@mtias Jika mengekspos sebuah blok Container ke pengguna akhir merupakan suatu kekhawatiran, maka mungkin setiap blok seharusnya hanya memiliki Container atau Pengaturan Container secara default.

Kemudian kita tidak perlu khawatir tentang mengajar pengguna akhir bahwa mereka perlu membungkus sesuatu dalam wadah agar memiliki hal-hal tertentu seperti gambar latar belakang.

Saya pikir ini sebenarnya ide yang bagus karena orang yang ingin memperluas atau membungkus blok sewenang-wenang akan memiliki tempat yang jelas untuk melakukannya, dan pengguna akhir akan terbiasa dengannya karena ada di setiap blok.

Mungkin "Pengaturan Penampung" bisa menjadi tab di samping "Pengaturan Blokir". Ini akan menjadi tempat (yang dapat diperluas) bagi pengembang untuk mampir (atau menyaring) hal-hal seperti pengaturan gambar latar belakang, pengaturan lebar, dll.

Ini juga akan memberi pengembang tempat untuk meletakkan pengaturan yang lebih kompleks yang dapat diterapkan ke hampir semua blok, seperti kontrol responsif / breakpoint.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Saya tidak menentang metode pengelompokan (selama saya dapat menetapkan atribut kelas), meskipun akan menyenangkan jika ada JUGA blok penampung jika Anda ingin membangun seperti itu.

-
Mode Wes
Sejarah Rahasia Orang American River
http://peoplesriverhistory.us

Dikirim dari Apple saya] [e

Pada 12 Oktober 2018, pukul 10.50, Chris Van Patten [email protected] menulis:

@rchipka Cara yang sangat mudah untuk mendekatinya adalah dengan memilih satu atau lebih blok dan mengklik opsi "Pindahkan blok yang dipilih ke dalam blok Penampung" di menu "lainnya". Dengan cara ini pemblokiran tidak memerlukan panel pengaturan tambahan.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

@chrisvanpatten Saya setuju, namun solusi ini tidak secara memadai mengatasi masalah asli

Masalahnya, seperti yang dikemukakan oleh @mtias , bukanlah tentang logistik penempatan blok ke dalam wadah, melainkan secara intuitif menyajikan antarmuka itu kepada pengguna akhir (tanpa memperlihatkan jenis blok tambahan).

Diskusi "bagaimana kita memasukkan blok ke dalam wadah" diperlukan. Namun, saya tidak selalu melihatnya terlalu rumit bagi pengguna. Banyak pengguna tidak akan menggunakannya, atau setidaknya tidak akan menggunakannya di luar beranda mereka. Banyak klien dan pelanggan tema kami mengungkapkan keinginan / kebutuhan situs web mereka dalam istilah visual yang sesuai untuk blok Bagian. Mereka mengatakan hal-hal seperti, "Saya ingin lebar penuh besar {bar / area / section / block / panel / span} dengan gambar cantik" diikuti oleh ", dan {masukkan permintaan konten di sini} di bagian itu". Mereka secara visual memahami bagian itu sendiri (wadah) terpisah dari konten di dalamnya.

Memang, bagaimana melakukannya melalui UI perlu dikerjakan, tetapi semoga poin saya di atas masuk akal.

@chrisvanpatten Pernyataan saya sebelumnya hanya didasarkan pada semantik dari jenis blok.

Satu-satunya alasan saya memperdebatkan semantik di sini adalah atas nama @mtias , karena ada masalah yang diangkat dengan kompleksitas mengekspos semantik ini di tempat pertama.

Saya suka saran Anda, tetapi jika saya mengikuti analogi saya, mungkin saya akan mengubah semantik "Blok yang dipilih grup".

@rchipka bukan itu cara saya menafsirkan komentarnya - saya mengartikan bahwa blok yang diusulkan harus sederhana, tetapi masih perlu menjadi blok itu sendiri (jika itu adalah area InnerBlocks, itu harus diapit satu blok). Mungkin ada cara untuk menyembunyikannya dari inserter dan hanya memiliki blok kontainer yang dibuat dengan memilih beberapa blok dan menyediakan opsi “tempat dalam kontainer” tetapi berdasarkan pemahaman saya tentang sistem yang masih berarti blok khusus.

Yang mengatakan saya lebih dari senang untuk salah :)

@JiveDig Saya sangat setuju ....

Namun, tim Gutenberg tampaknya sangat sensitif untuk mengungkap hal-hal ini kepada pengguna akhir di inti Gutenberg.

Ini adalah satu-satunya dasar saya untuk mengangkat argumen ini dan menyampaikan ide-ide ini.

Sekali lagi, jika itu saya, kami hanya akan memiliki blok kontainer sialan itu.

Saya rasa blok kontainer tidak benar-benar masuk akal, karena akan mengacaukan UI. Saya lebih suka melihat sesuatu seperti penanda "Section Break" yang Anda lihat sebaris di Microsoft Word. Menambahkan pemisah bagian akan menawarkan beberapa opsi gaya di inspektur seperti nama kelas untuk bagian tersebut, warna latar belakang, warna teks, bayangan, apa pun yang secara gaya mendefinisikan bagian Anda. Itu bisa dimasukkan seperti blok apa pun dan dipindahkan seperti blok apa pun.

@rwrobe Ide itu tidak bekerja untuk kontainer bersarang.

Saat ini saya sedang membangun situs dengan Gutenberg dan telah banyak menggunakan versi modifikasi dari blok bagian marcusig . Inilah yang saya pelajari berdasarkan pengalaman:

• "Bagian" adalah nama terbaik untuk blok tersebut. Artinya jelas bagi pengembang dan pengguna akhir, dan ini menghindari penyulit markup / opsi dengan secara logis menggunakan blok <section>.

• Opsi menu konteks yang diperlukan hanyalah alignnormal / wide / full (dan sebenarnya saya hanya menggunakan alignfull). Penjajaran tidak memengaruhi blok dalam, yang tetap dalam perataan normal kecuali mereka memiliki opsi perataan sendiri. Kasus penggunaan utama telah membuat warna latar belakang rata yang berisi blok teks rata-normal - pola desain yang sangat umum yang saat ini tidak memungkinkan.

• Satu-satunya pengaturan blok bilah sisi yang diperlukan adalah Warna Latar Belakang dan Gambar Latar Belakang (dengan opsi tetap / opasitas terkait). Penyesuaian tambahan apa pun dapat ditangani dengan kelas CSS khusus. (Menyertakan opsi Gambar Latar Belakang juga memiliki efek samping mengubahnya menjadi versi Blok Sampul yang jauh lebih berguna.) (Tetapi: jika @mtias benar bahwa menghindari percakapan itu hanya dengan menyertakan opsi Warna Latar Belakang akan mengeluarkan ini pintu lebih cepat, maka aku setuju.)

• Kegunaannya sederhana. Lebih mudah dari Kolom, yang telah ada beberapa lama sekarang. Satu-satunya masalah potensial adalah saat bagian tersebut pertama kali ditambahkan, fokus dialihkan ke paragraf di dalam bagian, sehingga sulit untuk mengatakan bahwa bagian tersebut baru saja ditambahkan sampai Anda mengarahkan mouse ke atasnya. Salah satu solusi yang mungkin untuk itu adalah default ke warna latar belakang abu-abu terang.

@ZebulanStanphill Apakah Anda berbicara tentang kolom? Saya dapat melihat blok "bagian" melakukan pekerjaan untuk konten yang dipisahkan secara vertikal-- bahkan mungkin ada tombol untuk mewarisi gaya dari bagian sebelumnya, yang memungkinkan Anda untuk "menumpuk" variasi gaya di dalam bagian.

Komposisi horizontal, seperti dalam kolom, tampaknya lebih sulit karena cara Gutenberg menyusun halaman dari atas ke bawah dalam balok dengan lebar penuh.

@mikedance Saya pikir itulah yang dibutuhkan. Pilihan gambar latar belakang akan menjadi penting meskipun IMO. Mungkin blok ini dapat menggantikan Blok Sampul, meskipun penamaan tersebut mungkin tidak kondusif bagi orang yang _hanya_ menginginkan gambar latar belakang dengan teks dasar di atasnya. Meskipun ada beberapa fungsi yang tumpang tindih, tetapi itu akan menghilangkan sebagian besar kasus penggunaan untuk blok Bagian tanpa menambahkan dukungan gambar bg.

@rwrobe Perlu dicatat bahwa Anda dapat memiliki blok yang diletakkan secara horizontal. Kolom (perhatikan kurangnya "s") blok hanya itu. Blok Kolom meletakkannya secara horizontal. UI mungkin dapat ditingkatkan di beberapa area, tetapi blok tidak terbatas pada lebar penuh atau ditata secara vertikal.

@mikedance

"Bagian" adalah nama terbaik untuk blok tersebut. Artinya jelas bagi pengembang dan pengguna akhir, dan menghindari penyulit markup / opsi dengan menggunakan ekstensi

blok.

Karena elemen <section> memiliki semantik yang dilampirkan padanya, akan lebih baik jika Anda dapat memilih untuk menggunakan <div> daripada <section> , karena dalam banyak kasus Anda ingin membungkusnya beberapa blok, tetapi secara semantik bukan bagian dari suatu bagian. Faktanya, akan lebih baik jika Anda juga dapat memilih untuk menggunakan elemen seperti <aside> atau <header> , yang terakhir ini sangat berguna untuk menambahkan semantik ke judul dengan latar belakang dalam pembuatan halaman.

Pada catatan lain, saya pikir memiliki opsi gambar latar belakang yang tersedia untuk blok Container akan sangat berguna. Tentu saja, tumpang tindih dengan konsep blok penutup menjadi sangat jelas. Jika Anda membuat blok Penutup lebih fleksibel, pada dasarnya blok tersebut berubah menjadi blok Kontainer, jadi mungkin konsep blok Penutup tidak perlu ada? Blok kontainer dapat melakukan hampir semua hal yang dilakukannya. Konsep Sampul bisa saja berupa template Blok yang Dapat Digunakan Kembali.

@ZebulanStanphill Saya setuju. Bahwa konfigurasi lanjutan yang memungkinkan Anda memilih apakah itu bagian, header, samping, atau div (default) akan berguna. Ya, sebagian besar pengguna mungkin tidak menggunakan opsi itu, tetapi ini adalah opsi yang mendukung pengembang web yang baik.

Bagaimana cara mengintegrasikan tema? Dapatkah tema menambahkan "variasi" ke blok, dalam kasus ini
blok bagian dan pengguna dapat langsung memilih satu dari ilst dan melihat gaya yang dihasilkan diterapkan?
Juga mungkin sangat membantu untuk menambahkan filter atau kait ke blok bagian untuk membiarkan
tema menambahkan pembungkus dan elemen lain yang terkadang diperlukan untuk gaya.

@ZebulanStanphill @wmodes Saya ragu termasuk opsi untuk memilih elemen yang mengandung akan pernah melewati devs inti. Itu terlalu rumit. Dari sudut pandang tertentu, elemen <section> semantik mungkin karena pengguna sudah mendefinisikannya sebagai "Bagian" berdasarkan pembuatan blok. Terserah mereka untuk menggunakannya secara bertanggung jawab, seperti heading. Tetapi jika itu akan menghindari argumen semantik, saya tidak memiliki masalah dengan menggunakan <div>.

@mikedance Setuju, kita mungkin sebaiknya menggunakan <div> . Jika tata letak semantik menjadi perhatian maka akan lebih baik jika ditangani sebagai ekstensi ke blok penampung.

@strarsis Themes dapat menggunakan API gaya blok yang ada untuk menambahkan gaya ke blok. (Tombol inti dan blok Kutipan menyertakan beberapa varian gaya secara default.) Sayangnya, saya tidak dapat menemukan dokumentasi apa pun tentang fungsi ini. (Ada beberapa masalah yang melacak kurangnya dokumen saat ini: https://github.com/WordPress/gutenberg/milestone/500)

@mikedance

Dari sudut pandang tertentu

elemen semantik mungkin karena pengguna sudah mendefinisikannya sebagai "Bagian" berdasarkan pembuatan blok.

Saya rasa saya mengerti apa yang Anda katakan, tetapi saya tidak setuju. Dalam banyak kasus, blok Penampung akan digunakan hanya untuk menambahkan warna latar belakang ke beberapa atau bahkan hanya satu blok yang tidak memiliki opsi latar belakang (atau gaya lain) sendiri. Blok Daftar yang dibungkus dalam Penampung untuk memberinya warna latar belakang dan menyorotnya tidak berarti Daftar ada di bagiannya sendiri.

Tapi ya, <div> adalah pilihan paling netral karena tidak memiliki arti semantik. Jika tidak akan pernah ada opsi di inti untuk mengubah elemen HTML, maka <div> adalah pilihan terbaik.

Alasan utama saya menginginkan kemampuan untuk memilih tag HTML adalah karena ini memungkinkan Anda untuk lebih mudah membuat halaman dan posting semantik tanpa harus menggunakan blok HTML Kustom atau plugin yang menambahkan blok kustom. Jika Anda ingin menggunakan tag <section> di Gutenberg sekarang, Anda harus meletakkan semua yang ada di bagian itu dalam blok HTML Khusus, kehilangan kemampuan pengeditan visual untuk hal-hal seperti Paragraf, Daftar, dll. Yang Anda akan sebaliknya. Mungkin pengalih tag dapat ditampilkan di bawah grup Lanjutan di inspektur?

@strarsis @ZebulanStanphill

Anda dapat menemukan dokumen untuk menambahkan Block Styles dalam buku pegangan di bawah ekstensibilitas https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style -variasi

@ajitbohra Terima kasih! Saya memeriksa halaman itu beberapa kali tetapi saya terus melewatkan bagian itu. :tertawa:

@ajitbohra : Terima kasih! Apakah ada demo untuk variasi gaya blok Gutenberg btw.?

@tokopedia

Ya, periksa inti button dan quote blok

https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/button
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/quote

@strarsis Blok pullquote , table , dan separator juga memiliki variasi gaya:
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/pullquote
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/separator
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/table

Saya sangat ingin melihat beberapa blok organisasi dibuat. Masalah saat ini dengan Kolom adalah bahwa membuat satu blok berkolom untuk mengelompokkan konten (katakanlah, untuk tujuan berbagi warna latar belakang, video atau gambar) tidak intuitif. Idealnya, saya ingin melihat editor mencapai tahap di mana ia mampu membuat konten seperti ini hampir secara ketat di dalam editor.

Memindahkan ini secara tentatif untuk rilis 5.1 sehingga kami memiliki lebih banyak waktu dalam menentukan bagaimana blok ini harus disajikan.

Sementara saya memikirkannya ... karena ada tumpang tindih antara ini dan blok Penutup, bagaimana jika blok Penutup lebih merupakan "konfigurasi" di mana ketika Anda menambahkan blok itu benar-benar menambahkan bock Bagian yang telah dikonfigurasi sebelumnya dengan Heading atau blok Teks / Paragraf bersarang di dalamnya?

@Tokopedia

bagaimana jika blok Cover lebih merupakan "konfigurasi" yang ketika Anda menambahkan blok itu benar-benar menambahkan blok Bagian yang telah dikonfigurasi sebelumnya dengan blok Heading atau Teks / Paragraf yang bersarang di dalamnya?

Kedengarannya sangat mirip dengan blok yang dapat digunakan kembali yang dimasukkan sebagai blok mandiri bagi saya. Mungkin inti dapat menyertakan beberapa templat blok yang dapat digunakan kembali secara default seperti itu. UI harus ditingkatkan untuk membuat penyisipan blok yang Dapat Digunakan Kembali sebagai mandiri lebih mudah. Lihat # 8403.

Apakah akan ada percabangan untuk menguji bagian baru / blok kontainer? Saya tertarik untuk memainkannya dan membantu mengujinya.

Sebuah wadah / blok bagian sangat berguna, saya harus menggunakan
Blok Kontainer Blok Gutenberg Tingkat Lanjut untuk saat ini.
Dan penting untuk membuat blok bagian / kontainer mudah terlihat dan dapat dipilih.

Sebagian berkomentar untuk diperhatikan bahwa blok bagian akan sangat berguna untuk pengembangan template.

Kami baru saja membuat blok bagian khusus sebagai pengganti ini menjadi inti dan telah melihat masalah di mana atribut blok tidak diperbarui jika blok tetap sama tetapi atribut berubah.

Ini telah diselesaikan dalam PR # 12406 (di atas)

Apakah blok ruas masih dipertimbangkan untuk 5,1 (ditargetkan 21 Februari 2019) atau lebih baru?

Saya telah menulis plugin blok bagian, yang telah saya gunakan pada beberapa proyek dan berharap dapat dirilis sebagai sesuatu yang lebih umum untuk repositori plugin. Ini memungkinkan warna latar belakang dan gambar atau video untuk disetel, serta kelas yang ditentukan oleh tema untuk memformat item yang terdapat dalam area innerblocks .

Dalam kasus penggunaan saya, lebih mudah bagi klien untuk memiliki bidang judul dan deskripsi yang telah ditentukan sebelumnya (opsional) di atas area pemblokiran dalam tempat mereka dapat menumpuk "item", yang, dalam kasus penggunaan saya, adalah widget palsu yang saya buat dengan blok lain Tipe. Tapi ini bisa dengan mudah menjadi bagian bersarang sederhana, di mana blok bagian pertama berisi heading, paragraf dan kemudian blok bagian lain, yang pada gilirannya berisi item ...

Bagian berarti gutenberg _must_ dapat menangani bagian yang tampilannya disetel ke flex dan merender properti flex anak-anak dengan benar.

Saya membuat bagian saya di JS tetapi kodenya memiliki sejumlah apa yang saya anggap sebagai retasan. Merendernya dalam PHP akan menjadi sangat mudah ... kecuali mengirimkan konten innerblock ke PHP masih belum terpecahkan, bukan?

Kolom, seperti yang diterapkan oleh blok kolom, adalah solusi yang sama sekali tidak bisa dijalankan karena memerlukan kurasi kolom secara manual, yang bukan merupakan hal yang ramah seluler dan membuat penambahan atau penghapusan item lain dalam satu set menjadi kerumitan yang besar dan membuat frustrasi.

"Kolom" di suatu bagian hanyalah deklarasi berbasis-fleksibel dan dapat, dan seharusnya, dengan mudah berupa baris, dan bukan merupakan wadah sebenarnya untuk item, tetapi hanya definisi untuk bagaimana mereka mengalir. Harap jangan merusak konsep bagian dengan sesuatu yang mirip dengan kolom sebagai wadah untuk item di dalamnya.

Properti yang diatur dalam suatu bagian harus mudah ditemukan oleh blok yang terdapat dalam bagian tersebut. Saya harus bisa membuat tipe blok yang bisa merespon dengan cara cerdas untuk pilihan yang dibuat di induk, jika memiliki induk. Karena itu, sulit untuk menemukan apa pun tentang atribut induk tanpa menulis apa yang tampak seperti 1.400 baris kode.

Blok disarangkan karena konteks induk / anak dari blok tersebut penting untuk bagaimana blok tersebut ditampilkan dan diedit. Berpura-pura konteksnya tidak ada adalah idealisme yang paling buruk.

Blok bersarang harus dapat mereferensikan atribut induk dengan mudah, dan secara default. Jika tujuan Anda adalah untuk tidak memiliki blok yang dirender di sisi server kecuali pada kesempatan yang jarang terjadi, pengiriman informasi konteks _has terjadi_, jika tidak render() akan menjadi gurun return null sebagai baru dan berguna tetapi blok rumit muncul.

(Saya pikir blok columns akan lebih berguna jika menerapkan properti CSS columns [masih eksperimental]. Pada dasarnya ini akan menjadi jenis khusus section , mengambil semua item di dalamnya dan mengalirkannya melalui properti kolom yang ditentukan di inspektur: column-width , column-count , column-rule , dll.)

apakah ada tanggal rilis untuk tipe blok ini (Tambah Blok: Bagian)?

@JQOz Tidak. Masalah ini ada di peta jalan untuk versi mayor berikutnya, tetapi tidak ada permintaan tarik terbuka yang sedang dikerjakan orang. Jika Anda memiliki ide atau fitur untuk blok ini, Anda dapat mulai menambahkannya di sini.

Hai,

Saya memikirkannya tidak hanya sekali. Bagian harus berupa wadah dengan lebar penuh. Bisakah kita menambahkan selokan ke wadah di dalam bagian dan membuatnya berfungsi seperti add_theme_support('alignwide') atau tidak.

Untuk kasus:

https://tech.cornell.edu/

Kami memiliki banyak bagian berbeda. Beberapa di antaranya masih hidup di dalam wadah. Beberapa tidak. Tetapi semuanya membutuhkan satu wadah.

Blok kolom Gutenberg terlalu kelas bersarang dan tidak banyak membantu. Ini harus mengikuti struktur grid dan menggunakan kelas induk> anak agar mereka tetap bekerja.

Ketika saya melakukan pengembangan https://www.luminasolar.com/ , saya harus membungkusnya di dalam kunci template untuk menjaga struktur.

Saya menyarankan itu sebagai bagian dari strategi untuk tata letak halaman yang beberapa pemikiran masuk ke dalam menyediakan hook / API untuk tema pihak ketiga dan pengembang plugin pembuat halaman untuk menambahkan antarmuka dan lonceng dan peluit mereka sendiri.

Mengikuti item ini di WPTavern , tampaknya pengguna mulai melihat masalah dengan standardisasi dan mengunci blok tertentu untuk tata letak yang kembali ke kastanye lama dari masalah yang telah menjadi masalah selama bertahun-tahun: ubah tema atau pembuat halaman dan tata letak menghilang atau dalam kasus editor blok baru, tampaknya, kode yang tidak dapat diubah karena diatur dalam batu.

Memiliki tata letak standar umum yang dapat diganti oleh CoBlocks, Kadence (atau apa pun yang Anda miliki sendiri), akan menyelesaikan masalah ini. Ubah plugin atau tema dan setidaknya konten Anda akan tetap mempertahankan tata letak dasar yang sama.

Ini pada dasarnya adalah satu-satunya fitur yang hilang yang membuat saya menyimpan elemen di situs saya ...

Mengikuti item ini di WPTavern , tampaknya pengguna mulai melihat masalah dengan standardisasi dan mengunci blok tertentu untuk tata letak yang kembali ke kastanye lama dari masalah yang telah menjadi masalah selama bertahun-tahun: ubah tema atau pembuat halaman dan tata letak menghilang atau dalam kasus editor blok baru, tampaknya, kode yang tidak dapat diubah karena diatur dalam batu.

Memiliki tata letak standar umum yang dapat diganti oleh CoBlocks, Kadence (atau apa pun yang Anda miliki sendiri), akan menyelesaikan masalah ini. Ubah plugin atau tema dan setidaknya konten Anda akan tetap mempertahankan tata letak dasar yang sama.

Ya ya ya! Saya percaya bahwa blok bagian yang fleksibel adalah satu-satunya fitur terbesar yang hilang dari Gutenberg. Saya senang mendengarnya direncanakan untuk rilis di masa mendatang, tetapi kecewa karena tidak ada yang mengerjakannya saat ini. Tanpa ini, pengguna masih tidak dapat mengatur format halaman umum dan pengembang tema masih perlu menggunakan teknik berpemilik untuk membawanya ke tempat pengguna benar-benar dapat membangun tata letak halaman yang cukup umum.

Blok bagian HARUS ada di inti Gutenberg (dan dapat dikonfigurasi serta dapat diperluas berdasarkan tema) untuk akhirnya menyelesaikan masalah untuk dapat menata halaman yang lebih kompleks dan masih dapat mengganti tema.

Tentu, sebagai desainer tema saya akan menambahkan palet warna saya sendiri, mengontrol margin dan padding agar sesuai dengan tema saya, memformat gambar agar sesuai, dan semua hal "desain" khusus tema ... tetapi pengguna harus dapat beralih ke tema WordPress apa pun dan setidaknya memiliki konten yang dipertahankan, pada dasarnya dalam tata letak yang sama (bagian yang dikelompokkan, kolom, dll.), dan dapat diedit sebagai Blok Gutenberg (tidak harus beralih ke blok HTML Kustom).

Saya memiliki plugin blok bagian yang saya memiliki versi kerja awal, dan berharap untuk memperbaruinya akhir minggu ini dan mengirimkannya ke repositori. Ini memungkinkan penumpukan tak terbatas dari blok (maksud saya, dengan alasan, saya kira). Plugin ini juga memungkinkan tema atau plugin untuk menentukan gaya bagiannya sendiri jika diinginkan, yang kemudian dapat dipilih oleh pengguna. Saya berencana untuk memasukkan hanya beberapa gaya default, yang dapat dinonaktifkan oleh tema, jika diinginkan.

Panel Inspektur

• _Background._ Plugin saya memungkinkan pengaturan warna latar belakang dan / atau gambar jika diinginkan, dengan kontrol untuk penempatan gambar, pencampuran, desaturasi, dan bahkan melapisi warna.
• _Dimensions, Padding, Margins._ Secara default, bagian otomatis-tinggi ke konten dan mematuhi perataan penuh, lebar dan tengah, dengan kiri dan kanan pada 45%. Yang mengatakan, saya akan menambahkan kontrol untuk memungkinkan lebar dan / atau tinggi tertentu, padding di sekitar InnerBlocks dan margin di sekitar blok. _Tapi lihat di bawah untuk masalah dengan Gutenberg._
• _Columns ... dan Rows._ Setelah banyak bereksperimen menggunakan flex, CSS _grid_ untuk turunan langsung adalah metode terbaik untuk digunakan jika Anda menginginkan layout berbasis kolom. Menggunakan grid adalah toggle; jika tidak, anak-anak hanyalah blok biasa. (Sejujurnya, sementara baris bisa dilakukan, mereka menambahkan banyak kerumitan ke antarmuka pengeditan yang mungkin paling baik ditangani dengan menambahkan bagian baru di bawah yang sedang Anda kerjakan ketika Anda perlu memulai baris baru.) Grid lebih unggul dari flex - bahkan jika Anda hanya membuat kolom - karena flex _requires_, tinggi non-persentase tertentu yang akan disetel pada container atau item turunan, yang menghilangkan banyak fleksibilitas.

Seluler
Satu masalah dengan plugin bagian mana pun yang menggunakan grid adalah apa yang terjadi pada grid pada breakpoint seluler yang ditentukan. Pengguna (atau penulis tema) harus dapat menentukan kapan suatu bagian berubah dari menampilkan 3 item menjadi 2 item menjadi 1 item secara keseluruhan.

Titik putus harus dapat ditentukan oleh tema dan tidak benar-benar terasa seperti berada di blok itu sendiri, karena ia menambahkan satu set besar pilihan inspektur, dan Anda mungkin ingin titik putus Anda konsisten di seluruh posting dan halaman . Namun saat menggunakan opsi kisi, blok tersebut perlu mengetahui tentang titik putus, dan perlu mengizinkan pengguna (atau tema) untuk menentukan bagaimana tata letak bagian beradaptasi dengannya.

Saya yakin ada cara elegan untuk melakukan ini, tetapi dalam jangka pendek demi kemanfaatan, saya hanya mengizinkan blok untuk "mempelajari" tentang breakpoint melalui config dan kemudian menggunakan daftar nilai yang dipisahkan koma untuk yang ditentukan breakpoints (bayangkan screenshot di sini):

Columns:        3,2,1,1
Column 1 width: 70%,50% 

Dll (Jelas satu kolom adalah 100% dan tidak perlu ditentukan).

Pertimbangan Tema dan Plugin
Sebuah tema (atau plugin) dapat menentukan bagian, dengan semua atributnya, dan menyembunyikan semua atribut tersebut dari pengguna, menyelamatkannya dari kemungkinan kebingungan, atau tema hanya dapat mengekspos hal-hal yang mereka inginkan agar dapat dimodifikasi oleh pengguna. (misalnya, gambar latar belakang sebenarnya yang dipilih). Tema atau plugin juga bebas untuk menambahkan hiasan menggunakan stylesheet mereka untuk menentukan jenis bagian ... memang, secara teori, dapat mengabaikan semua kotak inspektur saya, menyembunyikan semua panel inspektur dari pengguna, dan menata semuanya dengan lembar mereka. Namun, itu menghilangkan kemungkinan bagi pengguna untuk bertahan dari perpindahan tema dengan bagian mereka utuh.

Pertimbangan Pengguna
Dengan asumsi tema telah bermain bagus dan menggunakan berbagai jalur yang tersedia dalam blok saya untuk mendefinisikan bagian dan atributnya "dengan benar", jika tema diubah semua atribut tersebut bertahan, dan jika tema sampai sekarang menyembunyikannya dari pengguna, mereka ' terekspos kembali. Hal ini karena pilihan teratas di pemilih "bagian yang ditata sebelumnya" adalah "khusus", yang memungkinkan pengguna untuk mengubah semuanya, dan yang akan dijadikan default untuk pemblokiran jika gaya yang dipilih sebelumnya tidak lagi tersedia. Semua pengaturan tema yang dibuat BUKAN pilihan stylesheet langsung akan tetap ada.

Ini tidak menjamin bahwa bagian Anda bertahan dengan cara yang terlihat bagus (Anda mungkin memiliki tema yang memiliki tata letak super lebar dan pindah ke salah satu dengan tata letak sempit, jadi bagian enam kolom mungkin bukan lagi pilihan terbaik ... tetapi tata letak itu akan tetap utuh. Pengguna dapat menyimpan tata letak itu sebagai blok yang dapat digunakan kembali.

Saat memilih gaya bagian, jika Anda beralih dari bagian yang ditentukan sebelumnya ke kustom, atribut inspektur bagian yang ditentukan sebelumnya akan mengikuti, jadi ini adalah cara bagi pengguna untuk mengubah bagian yang telah ditentukan sebelumnya tanpa harus mengubah definisi bagian tersebut di tema atau plugin.

Masalah Gutenberg
Jadi, Gutenberg melakukan hal berikut dengan buruk:

• Blok yang perlu disatukan secara vertikal, yang terkadang perlu Anda gambar bagiannya.
• Segala jenis panggilan untuk menampilkan sesuatu sebagai flex atau grid. Karena sup div editor, Anda harus membatalkan panggilan CSS Anda ke grid atau flex pada pembungkus innerblocks dan menyetel ulang di salah satu blok editor.
• Rata kiri dan rata kanan. Saya mengajukan bug tentang ini, tetapi karena Gutenberg tidak membatasi float dari blok kiri atau kanan hanya untuk anak langsung dari blok yang memiliki atribut data kiri atau kanan (atau tengah), semua blok bersarang berikutnya diapungkan ke kiri atau Baik.
• Menambahkan blok baru seringkali merupakan misteri lengkap di mana mereka akan dimasukkan ... Anda pikir Anda berada di bagian bawah bagian Anda, menginginkan blok internal baru, dan sebaliknya editor akan memasukkan satu di bagian bawah dokumen Anda
• Model seret / lepas Gutenberg untuk memindahkan balok tidak dapat diandalkan dengan balok yang dapat memiliki posisi horizontal

Mencoba itu
Saya akan memposting tautan di utas ini ketika saya menjatuhkan versi di github yang menurut saya layak untuk dilihat, jika ada yang tertarik. Saya telah menghabiskan beberapa bulan untuk ini, dan itu mungkin masih tidak bagus, tapi itu sesuatu.

Saya harus menambahkan bahwa saya sangat percaya bahwa hal-hal seperti tampilan font, ukuran heading, dll bukanlah hal-hal yang harus dikatakan oleh blok bagian secara langsung. Atribut inspektur yang saya setel terasa bagi saya seperti dasar-dasar yang diperlukan untuk mempertahankan atribut "gambaran besar" dari suatu bagian dari tema ke tema, atau untuk mencegah penghapusan plugin agar tidak mengganggu tampilan situs sepenuhnya.

@rogerlos Anda harus mempertimbangkan untuk melihat Kadence Blocks . Mereka tampaknya menangani kolom berbasis flexbox dengan cukup baik.

Saya harus menambahkan bahwa saya sangat percaya bahwa hal-hal seperti tampilan font, ukuran heading, dll bukanlah hal-hal yang harus dikatakan oleh blok bagian secara langsung.

Saya sangat setuju dengan ini. Satu-satunya pengecualian adalah setelan "warna font" tingkat bagian. Hal ini diperlukan karena situs yang font utamanya gelap tidak akan cukup kontras dalam bagian yang memiliki gambar / hamparan latar belakang gelap.

Berikut adalah demo bagaimana blok Tata Letak Baris Kadence menggunakan kembali "Mode Align" di toolbar blok untuk memungkinkan tiga lebar konten dalam yang berbeda, lebar kolom yang dapat disesuaikan, margin baris atas / bawah yang dapat disesuaikan, serta latar belakang dan pengaturan warna teks.

Setelan "lebar-maks bagian konten" ini hampir merupakan satu-satunya pola yang berulang secara global (dan oleh karena itu ditentukan oleh tema) yang perlu diperhitungkan oleh blok bagian (selain batasan komponen yang diwariskan secara global, seperti warna font yang diizinkan, ukuran talang kolom, dll.) )

Berasal dari pengalaman agensi web, ada tidak lebih dari tiga lebar bagian konten yang berbeda dalam desain apa pun yang saya terima. Apa pun di luar tiga lebar ini cenderung menjadi variasi khusus konten yang sengaja melepaskan diri dari pola desain tema dengan cara yang tidak berulang.

Blok bagian yang baik akan mengarahkan pengguna ke default yang ditentukan tema (mengikuti pola desain asli), tetapi terkadang memungkinkan mereka untuk melepaskan diri dari pola tersebut dengan cara yang wajar.

Untuk menerapkan tata letak yang konsisten dan dapat diprediksi di semua ukuran layar, tidak ada pemblokiran "berorientasi teks" yang diizinkan di tingkat root dalam penyiapan kami.

Semua blok non-gambar / sematan harus berada dalam "bagian" (Tata Letak Baris Kadence) di tingkat akar, yang menerapkan lebar bagian konten tema kami, sambil tetap mengizinkan baris yang dapat disesuaikan sepenuhnya dengan sejumlah kolom serta latar belakang lebar penuh pilihan, dll.

Elemen penampung juga harus memungkinkan elemen lapisan untuk ditumpuk (indeks-z).
Hal ini memungkinkan, misalnya elemen video atau slider sebagai latar belakang atau efek paralaks.

@stris Ide bagus.

Idealnya, blok bagian akan menggunakan z-index untuk menyediakan mode pengeditan latar depan / latar belakang yang dapat diubah.

Dengan cara ini blok bagian itu sendiri tidak menemukan kembali hal-hal gambar latar / overlay, yang semuanya tersedia di blok Gambar Sampul bawaan.

Konten latar belakang tidak akan dibatasi oleh lebarnya dan oleh karena itu pengembang tema harus memiliki kemampuan untuk menentukan blok mana yang bisa menjadi latar belakang bagian. Lebar konten latar depan akan dibatasi ke sejumlah lebar maksimal yang disediakan oleh tema.

Jika pengguna perlu menyimpang dari lebar default yang diberikan sedikit konten tertentu, mereka dapat memilih bagian dengan lebar terbesar berikutnya dan memberi bantalan pada sisi yang sesuai.

Contoh di mana konten latar depan harus keluar secara visual di luar lebar maksimal bagian harus didaftarkan sebagai Variasi Gaya yang menyesuaikan margin negatif pada blok tertentu.

Alasannya adalah, meskipun pengguna akan cukup aman menyesuaikan nilai padding, kami pasti tidak ingin margin negatif menjadi sesuatu yang ditentukan pengguna.

Mengizinkan definisi margin negatif dalam editor akan menjadi berantakan saat merespons ukuran layar yang berbeda, paddings bagian konten, lebar selokan pada breakpoint tertentu, dll. Dan oleh karena itu harus digabungkan erat dengan tema / kode dan diekspos sebagai abstraksi tingkat yang lebih tinggi kepada pengguna akhir.

Mengenai kontrol pengembang: Ada plugin Mesh yang menyediakan wadah "keras",
yang harus dipaksakan oleh temanya.
Sebuah tema terkadang harus membatasi area yang tersedia, seperti hanya sudut kiri atas seluruh halaman.
Gutenberg harus menyediakan mekanisme untuk tema untuk menyetel wadah "keras" ini di dalam editor halamannya.

@strarsis Menurut pendapat saya, apa pun yang terjadi di luar the_content() area tidak ada urusannya di dalam editor Gutenberg.

"Area" ini adalah bagian dari template halaman dan bukan konten halaman dan harus ditangani di tempat lain.

Konten Halaman vs. Template Halaman (/ Tata Letak)

Konten / bagian di dalam editor harus mengasumsikan bahwa tata letak sekitarnya tidak ada (saat mengedit), dan sebagai gantinya diperlengkapi untuk merespons dengan tepat ketika ditempatkan di dalam tata letak tertentu (di ujung depan).

Elemen adalah bagian dari template halaman ( dan bukan konten halaman ), jika:

1. elemen mendefinisikan atau bergantung pada penataan, batas, atau pemosisian area the_content() secara keseluruhan , dan
2. elemen adalah bagian dari pola berulang (yaitu berpotensi dapat dilihat di dua atau lebih tautan permanen)

Beberapa latar belakang berbasis pengalaman

Elemen template / tata letak berulang biasanya khusus untuk jenis posting kustom dan mencakup pahlawan konten, bilah sisi konten, dan footer konten.

Dalam setiap kasus, saya telah menemukan bahwa konten dalam elemen tata letak ini cukup berasal dari informasi yang terletak di bidang khusus, taksonomi, atau pengaturan lain yang terletak di tingkat posting dan bukan di tingkat blok.

Dan, dalam setiap kasus, saya telah memperkuat keyakinan saya bahwa akan menjadi usaha yang luar biasa untuk memodifikasi atau mengubah gaya secara massal bagian-bagian ini seandainya telah diterapkan sebagai blok di dalam editor Gutenberg.

Jadi akhirnya

Definisi (dan implementasi akhirnya) dari sebuah Bagian harus diperluas cukup jauh untuk menangani kebutuhan pola desain tema yang berkaitan dengan the_content() .

Apa pun yang termasuk dalam "template" dan bukan "konten" harus ditangani di luar blok Bagian mana pun dan di luar editor Gutenberg (untuk saat ini).

Saya ingin Gutenberg dapat membuat template sebaris dengan konten sama seperti orang lain, tapi sepertinya kita belum berada di sana, dan kita harus menyelesaikan blok Bagian ini sebelum kita dapat menangani pembuatan template dengan tepat.

Beberapa hari yang lalu saya ingin membuat tata letak dasar dan membutuhkan ini. Jadi saya mulai dengan menginstal plugin A, mencobanya, ternyata buggy. Dicopot, menemukan plugin B, terinstal, mencoba blok bagiannya, itu baaad. Selanjutnya plugin C buggy, plugin D menyebutnya container dan itu meh. Plugin berikutnya E, F .........
Saya dapat meyakinkan Anda bahwa "ekosistem" Gutenberg saat ini sangat, sangat membuat frustrasi jika Anda ingin membuat halaman dan menulis konten.
Fakta bahwa orang-orang di sini terus mengatakan "lihat plugin X", "jika Anda ingin fitur ini, instal plugin Y", dll. Adalah indikasi yang jelas bahwa orang memerlukan ini. Mereka tidak _menginginkannya, mereka membutuhkannya . Saat ini ada selusin plugin semuanya dengan implementasi mereka sendiri dari wadah / bagian / terserah-Anda-ingin-menyebutnya.
Saya tidak mengatakan bahwa Gutenberg harus menambahkan setiap fitur di bawah matahari, tapi ini fitur dasar. Itu harus ada di sana. Tidak perlu memiliki semua opsi yang memungkinkan, tetapi dasar-dasarnya harus ada dan pengembang dapat memperluas jika diperlukan.
Kami mencapai titik di mana akan ada 20 penerapan berbeda untuk wadah dasar dan tidak ada yang berfungsi sebagaimana mestinya (pendapat pribadi tentu saja).

Sebagai alternatif yang mudah saya hanya menggunakan blok kolom dan mengatur jumlah kolom menjadi 1 (slider dibatasi antara 2 dan 6, tetapi Anda dapat memasukkan 1 di kolom input). Setelah itu Anda perlu memperbaiki CSS di admin:

//Allow single columns
add_action('admin_head', 'gutenberg_allow_single_columns');
function gutenberg_allow_single_columns() {
    ?>
    <style type="text/css">
    <strong i="6">@media</strong> (min-width: 600px) {
        .wp-block-columns.has-1-columns > .editor-inner-blocks > .editor-block-list__layout > [data-type="core/column"] {
            flex-basis: 100% !important;
            flex-grow: 0; } }
    </style>
    <?php
}

Dan tentu saja Anda perlu mengatur hal yang sama di frontend Anda juga, tapi itu masalah tema. Saya pikir mengizinkan tata letak kolom tunggal akan cukup untuk opsi wadah dasar, yang biasanya diperlukan untuk tujuan penataan gaya. Yang lainnya (seperti mengatur latar belakang, z-index, paralaks dll ...) harus dilakukan dengan plugin imo.

Dan tolong tambahkan sarana untuk tema (pengembang) untuk mengontrol berapa banyak dan pembungkus apa yang digunakan.
Beberapa desain hanya membutuhkan lebih dari satu elemen. Saat ini saya harus menggunakan plugin lain untuk elemen kontainer dan kemudian mengurai seluruh konten menggunakan parser PHP untuk membungkus konten kontainer menjadi elemen pembungkus ekstra untuk gaya.

@strarsis Ini jelas sesuatu yang harus dilakukan dari awal.

Untuk melakukan gaya apa pun yang layak pada konten postingan, setiap turunan tingkat root harus ditempatkan di baris / bagian yang konsisten.

Misalnya, tanpa membungkus setiap baris, akan sulit dan sulit untuk membuat bagian dengan lebar berbeda (terutama bagian lebar penuh).

Saya juga mempertimbangkan opsi penguraian PHP, tetapi menyadari bahwa itu tidak memberi editor konten kontrol apa pun atas jenis bagian mana konten tertentu berada.

Sebagai gantinya, dalam pengaturan kami, kami memaksa semua contoh editor Gutenberg untuk hanya mengizinkan satu blok Kontainer di tingkat akar untuk semua jenis posting / halaman / posting.

Blok penampung akar memberlakukan subset blok terbatas yang dapat ditambahkan di dalamnya.

Untuk menambahkan teks atau blok non-lebar penuh, Anda harus terlebih dahulu memasukkan Tata Letak Baris Kadence, yang dalam hal ini bertindak sebagai elemen pembungkus bagian utama kami.

Blok kontainer sederhana yang dapat diperpanjang adalah semua yang diperlukan di dalam inti. Memperluas blok ini sehubungan dengan gaya harus diserahkan kepada pengembang plugin / tema. Ini juga harus menyediakan status transformasi fallback untuk pengembang yang ingin membangun blok penampung mereka sendiri.

Semua plugin pihak ketiga yang menyediakan wadah / bagian / baris yang telah saya uji tunduk pada masalah signifikan terkait dengan penguncian konten. Setelah penonaktifan plugin ini, konten blok dalam tidak lagi dapat diakses dari dalam editor dan mengonversinya akan menghilangkan HTML. Sesuatu yang harus disadari sepenuhnya oleh pengguna.

Lihat:
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

Baik. Saya sudah menguji Gutengerg, itu bagus, tapi ya, itu pasti kekurangan bagiannya.
Sebenarnya, banyak blok memiliki wadahnya sendiri yang dapat kita tambahkan kelas css dan gayanya. Tapi, konten utama ditulis tanpa wadah, begitu pula kelas apa pun, dan karenanya kami tidak dapat menatanya. Dan karena konten utama ditulis dalam tahap yang sama dengan semua blok lainnya, ini membuat sangat sulit untuk mengemasnya secara berbeda dari yang lain.

Dengan kata lain, saya akan kembali ke klasik dan menunggu sampai Anda memberi kami Bagian.

Terima kasih. Salam.

Ya, itu benar sekali. Saya pikir itu bahkan lebih penting daripada semua blok lain yang saat ini sedang dikembangkan. @youknowriad Tidak bisakah Anda memberikan prioritas lebih?

Ini sudah ada dalam cakupan fase 2 https://github.com/WordPress/gutenberg/issues/13113 jika seseorang mau mencobanya, silakan.

@youknowriad Saya khawatir saya bukan pengembang. Tapi saya ingat bahwa perkembangannya sudah berjalan. Sesaat sebelum rilis Wordpress 5 ada PR yang sudah sangat advance. Masih ada detail yang harus diklarifikasi, tapi sudah hampir siap. Sayangnya saya tidak dapat menemukan PR lagi. Apakah ada yang tahu di mana itu?

Ya, jangan khawatir saya mengerti.

Berikut PR. https://github.com/WordPress/gutenberg/pull/10562

Saya ingin mengklarifikasi bahwa Ini adalah proyek open source dan didasarkan pada kesukarelaan. Saya dapat memberikan arahan global, meminta bantuan tetapi tidak menugaskan orang. Orang cenderung berpikir sebaliknya.

Saya tegaskan kembali bahwa jika ada pengembang yang ingin melihat ini terjadi lebih cepat dan ingin membantu, mereka dipersilakan untuk rapat mingguan di saluran Core Slack # core-editor (dan rapat) dan berdiskusi / berkolaborasi / meminta bantuan.

Ahhh ya itu dia! Bagus! Anda memiliki gambaran umum !!!

Ya, itu benar dan itu tidak boleh dicela. Apa yang saya tanyakan pada diri saya sendiri: apakah tidak ada tugas yang penting dan bahkan lebih penting? Jika 50 orang membutuhkan blok RSS, tetapi 1000 membutuhkan blok kontainer, masuk akal untuk memfokuskan semuanya secara lebih spesifik. Blok kontainer tidak eksotis sekarang. Saya rasa ini adalah _basis untuk setiap desain_.

Mohon jangan salah paham: Anda melakukan pekerjaan dengan baik. Dan Anda sebagai Pemimpin Fase 2 sedang melakukan pekerjaan kelas satu. Ini semua tentang pertanyaan tentang fokus. Saya akan bersulang di obrolan kendur berikutnya ... ;-)

Terima kasih banyak lagi!

Terima kasih dan dengan senang hati menjelaskan. Saya memberi mereka secara pribadi kepentingan yang sama. Langkah perantara untuk fase 2 adalah menggunakan blok di layar widget. Jadi, meskipun orang tidak meminta pemblokiran RSS, setelah layar widget (yang merupakan langkah penting untuk tahap 2) akan menggunakan pemblokiran, jika orang tidak menemukan widget RSS yang biasa mereka gunakan, mereka akan mengeluh tentang itu.

Kedua tugas ini adalah tugas "menengah" dalam hal kompleksitas, keduanya merupakan fitur penting, tetapi tidak penting dari segi kerangka kerja. Prioritas tinggi pribadi saya saat ini adalah kerangka kerja yang akan mengaktifkan sasaran fase 2 (blok di layar widget, editor di luar post_content) karena masalah konteptual ini penting untuk bereksperimen dan mengklarifikasi lebih cepat daripada nanti.

Baik. Saya sudah menguji Gutengerg, itu bagus, tapi ya, itu pasti kekurangan bagiannya.
Sebenarnya, banyak blok memiliki wadahnya sendiri yang dapat kita tambahkan kelas css dan gayanya. Tapi, konten utama ditulis tanpa wadah, begitu pula kelas apa pun, dan karenanya kami tidak dapat menatanya. Dan karena konten utama ditulis dalam tahap yang sama dengan semua blok lainnya, ini membuat sangat sulit untuk mengemasnya secara berbeda dari yang lain.

Dengan kata lain, saya akan kembali ke klasik dan menunggu sampai Anda memberi kami Bagian.

Terima kasih. Salam.

Ini adalah sikap yang saya ambil tentang ini dan kekurangan lainnya dari editor blok baru sampai terbentuk. Mudah-mudahan ini akan terjadi karena ada beberapa aspek bagus untuk editor baru.

Blok bagian akan luar biasa, apa yang dapat saya lakukan untuk membantu meskipun saya tidak memiliki keterampilan pengembangan backend.

Ada banyak plugin blok sekarang, tetapi satu-satunya blok dari mereka yang saya inginkan adalah bagian atau blok wadah jadi saya ingin melihatnya ditambahkan.

Inti WordPress perlu menyertakan implementasi sendiri dari bagian, baris, struktur tata letak kolom untuk editor blok, sesuatu yang standar dan yang dapat digunakan oleh semua plugin pihak ketiga, tema dan pembuat halaman. API harus disediakan, seperti yang telah saya sebutkan berkali-kali sebelumnya, sehingga ini dapat menambahkan antarmuka, lonceng, dan peluitnya sendiri. Matikan salah satu solusi pihak ketiga ini dan struktur halaman Anda tetap utuh.

Karena ada solusi pihak ketiga untuk bagian / baris yang datang dari segala arah tetapi, begitu Anda mulai mencampurkan blok inti asli dan blok pihak ketiga, Anda mulai melihat banyak ketidakkonsistenan dan blok mogok dan perlu diselesaikan. Bukannya saya ingin mengkritik upaya mereka yang memberikan solusi tata letak ini, mereka mengisi fitur yang sangat dibutuhkan. Banyak dari mereka bagus tetapi ada sesuatu yang kurang tepat tentang keseluruhan pengalaman.

Saya mendukung editor blok inti sederhana, memungkinkan pihak ketiga untuk menambahkan fungsionalitas dan kecanggihan ekstra, tetapi itu benar-benar perlu diperketat, jika tidak, mendapatkan daya tarik pada penerimaannya tidak akan dicapai dengan mudah.

Pertanyaan besarnya di sini adalah siapa yang akan mengurusnya. Bukankah ada sedikit developer yang punya waktu dan tenaga untuk melakukannya?

Ya ya ya! Saya percaya bahwa blok bagian yang fleksibel adalah satu-satunya fitur terbesar yang hilang dari Gutenberg.

Aku bahkan tidak percaya itu belum ada ...

Alternatifnya adalah membiarkan blok kolom hanya memiliki satu kolom dan juga memungkinkan pengaturan warna latar belakang ke kolom. TA-DA: blok bagian.

Nah, jika itu membantu siapa pun: Kami menulis blok bagian untuk proyek kami beberapa waktu lalu. Saya yakin ini bisa dipoles di beberapa titik, tetapi ini bisa menjadi titik awal yang baik:

https://github.com/Impuls-Werbeagentur/impuls-section-block

Aku akan mengangkat tangan untuk mengerjakan ini. Saya bisa memulainya dari pertengahan minggu depan

@chrisvanpatten - sepertinya Anda membuat kemajuan yang sangat bagus dalam hal ini sebelumnya, hanya ingin memeriksa apakah Anda

Saya telah menggunakan beberapa blok kontainer dari plugin. Saya pikir persyaratan utama mendukung perataan lebar dan penuh, pelampung, dan kontrol untuk mengubah latar belakang wadah. Bertujuan untuk mengirimkannya dalam versi pertama akan memberikan dasar yang baik untuk perbaikan lebih lanjut.

Saya pikir peningkatan pertama adalah menambahkan lebih banyak pembungkus di luar blok mana pun.

Sebagai contoh:

<div class="wp-block-paragraph">
  <div class="wp-block-paragraph__container">
    <InnerContent />
  </div>
</div>

Saat ini, banyak elemen disisipkan secara langsung, mencegah kita menerapkan gaya untuk membuat pembungkus.

<ol>
  <li></li>
</ol>

Dapat ditambahkan pembungkus untuk itu:

<div class="wp-block-listing">
  <div class="wp-block-listing__container">
    <ol>
      <li></li>
    </ol>
  </div>
</div>

Kemudian kita dapat menerapkan set wadah agar tetap cocok:

// Example
#content > * > * {
  max-width: 1280px;
  padding: 0 20px;
}

@talldan Maukah Anda
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

Blok bagian akan sangat bagus, tapi tolong buat markup semantik saja! Menjaga hal-hal dalam struktur HTML semantik akan menciptakan basis kode yang paling agnostik.
<section>, <article>, <header> jauh lebih baik <div class="wp-section"> atau apa pun.

@talldan Maaf saya melewatkan komentar Anda, tetapi saya 100% baik-baik saja dengan Anda menanggapi ini 🙌 Saya yakin Anda akan mengguncangnya!

Akan sangat bagus juga jika bisa menggunakan titik fokus blok teks & media # 10925. Tentu saja ini hanya masuk akal jika Anda memiliki latar belakang gambar.

Suatu hal yang hebat, yang juga dimiliki oleh banyak pembuat halaman. Atau setidaknya seperti itu:

Setuju, pemilih titik fokus akan hebat di sini. Ini bekerja dengan sangat baik di blok sampul!

Dengan mengingat hal itu, saya telah memperbarui maket saya sebelumnya untuk blok bagian. Ini bertindak murni sebagai elemen wadah dengan warna dan gambar latar belakang yang dapat disesuaikan.

Pratinjau :

Anda dapat melihat prototipe di sini .

Beberapa catatan tambahan:

• Saya pikir kita harus meluncurkannya tanpa gambar latar belakang untuk memulai, hanya warna latar / teks. Setelah kami mendorongnya keluar, selanjutnya kami dapat membuat gambar latar belakang. Ini keluar dengan cepat, menggunakan pola yang ada, dan masih harus mencakup sejumlah besar kasus penggunaan.
  
  
  
  • Setelah kami menggabungkan versi pertama, kami berpotensi menghentikan penggunaan latar belakang dan warna teks dari blok teks. Sebagai gantinya, kita bisa memiliki opsi warna sebaris / opsi sorotan di blok paragraf. Ini tampaknya menjadi pola paragraf yang lebih baik secara keseluruhan.
  
  
• Blok ini tidak akan berisi pengaturan responsif apa pun, karena itu akan selalu menjadi wadah. Konten di dalam wadah (seperti blok kolom) akan memberikan perilaku responsif.

Saya setuju, gambar background bisa ditambahkan menggunakan css jika diperlukan untuk saat ini: +1:

Setelah kami menggabungkan versi pertama, kami berpotensi menghentikan penggunaan latar belakang dan warna teks dari blok teks. Sebagai gantinya, kita bisa memiliki opsi warna sebaris / opsi sorotan di blok paragraf. Ini tampaknya menjadi pola paragraf yang lebih baik secara keseluruhan.

Salah satu alasan untuk mempertimbangkan blok bagian sebagai tempat yang tepat untuk warna tingkat blok adalah bahwa jika tidak, kita harus menjawab mengapa daftar, judul, dan blok teks dasar lainnya tidak memiliki opsi warna tersebut. Dan karena itu terbagi pada level blok, Anda tidak akan pernah bisa memiliki gambar latar belakang yang membentang semua itu secara terus menerus, sedangkan blok bagian memperbaikinya.

Cara untuk menghentikan warna-warna ini berpotensi dengan hanya menghapus UI-nya, tetapi biarkan blok yang ada tetap bergaya apa adanya.

Bagus! Akan berguna untuk memiliki kelas kecil / sedang / besar untuk bantalan vertikal.

Bagus! Akan berguna untuk memiliki kelas kecil / sedang / besar untuk bantalan vertikal.

Ini masuk ke dalam level tema / kerangka kerja, dan saya tidak yakin apakah inti memiliki tempat untuk sesuatu seperti https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing .html

Saya pikir kita harus meluncurkannya tanpa gambar latar belakang untuk memulai

Sangat setuju. Dapatkan v1 dan kemudian v2 dapat menambahkan fungsionalitas yang lebih kompleks.

Blok ini tidak akan berisi pengaturan responsif apa pun

Setuju - Blok ini harus sesederhana dan sebisa mungkin.

Saya pikir kita harus menggabungkan PR ini jika memungkinkan.

Saya terpukul pada sesuatu seperti ini ... dirilis sebagai plugin:

https://wordpress.org/plugins/magic-block/

Tolong, tidak ada lagi plugin yang akan membuat orang bergantung padanya. Lepaskan saja blok terkutuk itu.

@webdados Saya detik ini.

Bukan untuk mengurangi pekerjaan siapa pun, tetapi kami benar-benar membutuhkan ini untuk dibangun di tingkat tertentu.

Terutama di dunia di mana ada masalah ini .

Jika solusi yang memadai ditemukan untuk # 13391, maka keberadaan implementasi blok kontainer yang tak terhitung jumlahnya mungkin akan baik-baik saja.

Sampai pembangun blok baru retak memiliki fondasi standar untuk elemen tata letak (wadah, bagian, kolom baris) yang dapat diperluas oleh plugin pihak ketiga, maka itu tidak berarti apa-apa dan melanggengkan kekacauan mengaktifkan dan menonaktifkan blok pihak ketiga, tema, pembangun ( mereka yang mencoba mengatasi masalah tata letak) dan akhirnya kehilangan konten dan tata letak halaman.

Kapan kita bisa mengharapkan fitur ini?

Seharusnya sudah dalam versi terbaru:
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere : Saya melewatkannya mungkin karena changelog untuk v5.5.0 plugin kosong .

Benar-benar menggali implementasi sejauh ini. Saya mengerti ini baru saja dirilis di 5.5, tapi saya bertanya-tanya kapan kita mungkin mengharapkan tambahan untuk gambar latar belakang (dan posisinya), opasitas warna latar belakang, dll. Apakah ini sesuatu yang harus kita harapkan sebelum akhir 2019, atau apakah kita berbicara lebih lama -term dari itu?

@nathansnelgrove Terima kasih atas umpan baliknya. Pasti ada beberapa perbaikan yang datang ke blok grup, berikut dua yang sedang berlangsung:

• Menambahkan wadah bagian dalam untuk mempermudah penataan - https://github.com/WordPress/gutenberg/pull/15210
• Menambahkan opsi editor untuk mengelompokkan / memisahkan pilihan blok - https://github.com/WordPress/gutenberg/pull/14908

Saya belum melihat masalah yang Anda sebutkan tentang gambar latar belakang dan opacity dilacak di mana saja, mungkin ada baiknya membuat masalah terpisah untuk itu jika Anda punya waktu karena masalah ini sekarang ditutup.

Gambar latar / warna / opasitas berasal dari proposal asli - Saya akan membuat masalah baru untuk mereka.

Saya baru saja menginstal WordPress 5.2.4, dan saya tidak dapat menemukan blok "Bagian" atau "Grup". Apa yang terjadi di sini?

@patrikhuber : Ini akan dimasukkan ke dalam WordPress 5.3 yang saat ini rencananya akan dirilis pada 12 November.

@noisysocks Begitu , terima kasih banyak!