Buka Survei untuk Penulis Tema WordPress di File JSON dan Blokir Tema

WordPress 5.8 memperkenalkan sistem opt-in untuk tema untuk mengonfigurasi pengaturan blok, gaya, templat, dan banyak lagi. Ini dilakukan melalui file theme.json baru yang dapat diletakkan penulis di root folder tema mereka. Anne McCarthy, pemimpin Program Penjangkauan FSE, mengumumkan survei sebelumnya hari ini untuk mendapatkan umpan balik dari pengembang tentang fitur ini.

“Karena mekanisme baru ini merupakan langkah awal menuju sistem gaya yang komprehensif untuk masa depan WordPress, penting untuk mendengar dari semua orang yang saat ini menggunakan theme.json untuk mempelajari lebih lanjut tentang bagaimana orang menggunakan alat ini dan apa yang mungkin masuk akal untuk disertakan. di Core ke depan,” tulisnya dalam pengumuman tersebut.

Survei ini terbuka untuk semua penulis tema yang telah menggunakan theme.json , memberi mereka kesempatan untuk memasukkan beberapa umpan balik awal dan membantu mengarahkan kapal ke depan.

Karena saya telah bekerja secara ekstensif dengan sistem ini selama beberapa bulan terakhir, saya memiliki beberapa hal untuk dikatakan. Plus, saya hanya suka berpartisipasi dalam survei terkait WordPress. Saya juga memutuskan ini akan menjadi kesempatan untuk membagikan beberapa pemikiran saya yang tidak disaring dari perspektif pengembangan tentang keadaan theme.json saat ini.

Berikut ini adalah tanggapan saya terhadap pertanyaan survei — yah, versi yang sudah dirapikan.

Catatan: Ini adalah pos yang berpusat pada pengembang yang mungkin tidak menarik secara universal bagi semua pembaca kami. Saya telah mencoba menjelaskan beberapa hal dalam terminologi yang mudah digunakan, tetapi beberapa pengetahuan prasyarat tentang pengembangan tema mungkin diperlukan.

Pengalaman

Pertanyaan pertama dari survei ini cukup potong-dan-kering. Ini menanyakan apa pengalaman Anda dengan tema blok bangunan atau menggunakan theme.json . Ini menyediakan empat pilihan (dan opsi "lain"):

• Saya telah membangun dan meluncurkan tema blok.
• Saya telah bereksperimen dengan tema blok bangunan.
• Saya telah menjelajahi menggunakan theme.json dengan tema klasik.
• Saya telah menggunakan tema blok, tetapi saya belum membuatnya.

Saya memilih opsi pertama karena saya telah membangun dua tema blok untuk keluarga dan teman. Ini adalah situs pribadi sederhana yang sudah saya kelola secara gratis — sejujurnya, saya harus mulai menagih . Saya juga sedang mengerjakan tema yang saya harap akan dirilis secara publik.

Bagaimana Ini Dimulai dan Bagaimana Ini Terjadi

Pertanyaan kedua menanyakan bagaimana seseorang memulai dengan blok tema dan theme.json . Pilihannya antara forking theme yang sudah ada, menggunakan Empty Theme, atau mulai dari awal.

Sekali lagi, ini adalah salah satu hal di mana saya telah bereksperimen dengan setiap arah, tetapi saya tidak dapat mengingat titik awal yang tepat. Sebagian besar pekerjaan saya berasal dari membuat tema yang terakhir saya kerjakan pada tahun 2019.

Saya berencana untuk merilis ini sebagai tema baru secara gratis di beberapa titik. Saya sebagian besar menunggu yang berikut:

• Pengembangan blok navigasi untuk diselesaikan
• Blok Post Author untuk dipecah menjadi blok yang lebih kecil
• Seperangkat blok terkait komentar yang kuat
• Posting blok Gambar Unggulan untuk memiliki opsi ukuran

Saya pikir saya dapat secara realistis merilis versi beta gunakan-dengan-risiko Anda sendiri dari tema saya hari ini jika item-item itu ditangani.

Template dan Bagian Template

Survei menanyakan templat dan tema bagian templat mana yang selalu disertakan dalam tema berbasis blok mereka. Ada kolom komentar bentuk bebas — langkah-langkah di atas kotak sabun…

Saya memiliki hubungan cinta/benci dengan templat blok saat ini. Sifat statis dari template HTML mengingatkan saya pada masa-masa yang lebih sederhana ketika pengembangan tema tidak terlalu rumit. Namun, ini juga menghadirkan masalah dalam sistem dinamis.

Saya tidak ingat kapan terakhir kali saya membuat tema tradisional berbasis PHP dengan lebih dari satu templat tingkat atas: index.php . Potongan dinamis selalu menjadi inti dari hal itu, yang merupakan bagian template. Dengan PHP, mudah untuk mengatur beberapa variabel atau menggunakan panggilan fungsi untuk secara kontekstual memuat bagian template yang diperlukan untuk halaman mana pun yang sedang dilihat pengunjung di situs.

Sistem templat blok tidak berfungsi seperti itu. Ini pada dasarnya memaksa pengembang untuk melanggar prinsip Jangan Ulangi Diri Sendiri (KERING).

Misalnya, jika seorang desainer ingin menampilkan bagian template header yang berbeda untuk halaman dan postingan, mereka hanya perlu membuat template header-page.php atau header-post.php dalam tema tradisional. Namun, karena sistem templat blok berbeda, mereka sekarang harus membuat dua templat tingkat atas, single.html (posting) dan page.html , untuk mencapai hal yang sama.

Ini adalah "hal yang buruk" karena pembuat tema harus menduplikasi semua kode lain di setiap templat tingkat atas. Tidak ada cara untuk memuat bagian template yang berbeda secara kontekstual.

Untuk menjawab pertanyaan: Saya menggunakan hampir semua templat tingkat atas yang mungkin karena kebutuhan.

Saya juga menjawab bagian kedua dari pertanyaan dan mencantumkan bagian templat yang paling sering saya gunakan (dipecah berdasarkan hierarki):

• tajuk
• Isi
  - Lingkaran
  – Bilah Samping
• catatan kaki

Bagian template content-*.html dan loop-*.html adalah yang paling banyak variasinya.

Mendefinisikan Warna

Bagian survei selanjutnya menanyakan bagaimana penulis tema mendefinisikan siput palet warna mereka di theme.json . Percaya atau tidak, penamaan warna mungkin menjadi topik paling kontroversial di dunia bertema selama bertahun-tahun. Hanya dua hal yang umumnya disepakati adalah warna "latar belakang" dan "latar depan".

Morten Rand-Hendriksen membuka tiket pada tahun 2018 untuk standarisasi skema penamaan warna tema. Itu bukan diskusi pertama dan bukan yang terakhir. Masalah yang dimaksudkan untuk diatasi adalah siput untuk warna dalam sistem, yaitu bagaimana tema menentukan palet mereka. Setelah pengguna menggunakan warna preset, slug dikodekan ke dalam konten mereka. Beralih ke tema lain dengan siput yang berbeda, dan warna lama menghilang dan tidak secara otomatis berubah ke warna tema baru.

Saya menggunakan nama semantik yang mengikuti sesuatu yang sangat mirip dengan sistem bayangan kerangka kerja CSS Tailwind. Alih-alih red-medium (deskriptif), saya akan menggunakan primary-500 (semantik), misalnya. Pendekatan semantik akan memungkinkan penulis tema untuk menentukan satu set warna yang diperbarui setiap kali pengguna mengganti tema.

Tentu saja, ada aliran pemikiran lain, dan bahkan setiap orang yang lebih suka penamaan semantik tidak setuju dengan sistem yang sama. Saya telah menjelaskan pendekatan saya secara lebih rinci dalam tiket GitHub yang lebih baru dan memiliki theme.json Gist untuk orang lain yang mungkin ingin mencobanya.

Pengaturan JSON Tema Lainnya

Di luar warna dan tipografi, survei menanyakan apa yang telah digunakan oleh penulis tema pengaturan lain. Ini adalah skenario lain di mana saya biasanya menggunakan semuanya — jika ada opsi untuk itu, saya mendefinisikannya.

Satu kasus penggunaan yang saat ini tidak memiliki preset untuk WordPress adalah spasi global. Sebagian besar penulis tema menggunakan nilai tunggal untuk sebagian besar margin vertikal (spasi putih antara blok dan elemen). Ini juga sering digunakan untuk padding vertikal dan horizontal default.

Saya tidak yakin apakah saya menginginkan preset karena saya tidak tahu bagaimana WordPress akan menggunakannya. Ini adalah sesuatu yang diminta orang lain, dan hampir digunakan di mana-mana. Mendefinisikan seluruh sistem di sekitarnya dapat menyebabkan sakit kepala di jalan, tetapi saya masih ingin melihat beberapa diskusi seputar penerapan setidaknya preset jarak global standar.

Pengaturan dan Gaya Per Blok

Bagian survei ini adalah pertanyaan ya/tidak, hanya menanyakan apakah penulis tema menyertakan pengaturan atau gaya per blok dalam file theme.json mereka. Tentu saja, saya meninggalkan beberapa komentar tambahan nanti di bagian komentar opsional.

Saya senang dengan sistem dalam hal pengaturan, yang memungkinkan tema menentukan fitur mana yang diaktifkan secara global atau per blok. Namun, saya tidak menjual menambahkan gaya melalui theme.json .

Menulis CSS di JSON, pada dasarnya apa yang kita bicarakan, terasa salah di banyak tingkatan. Saat ini, ini terbatas hanya pada beberapa gaya yang dapat dikonfigurasi, jadi apa pun di luar itu perlu menyelami file CSS yang sebenarnya. Itu bermasalah karena setengah dari kode CSS tema dibagi antara theme.json dan file CSS terpisah. Dari sudut pandang pengembangan, itu membuat basis kode lebih sulit untuk dipelihara.

Awalnya, saya mulai mengonfigurasi gaya per-blok dan elemen dari theme.json . Namun, saya telah memindahkan gaya saya kembali ke file CSS. Rasanya lebih alami, dan saya memiliki manfaat tambahan dari semua perkakas yang biasa saya gunakan. Saat ini, saya tidak dapat membayangkan skenario di mana saya akan mundur.

Selain menyimpan beberapa byte kode, saya belum melihat banyak manfaat menambahkan gaya untuk sebagian besar hal melalui JSON. Mungkin itu akan berubah di masa depan, dan saya akan menjadi mualaf. Untuk saat ini, saya tetap menggunakan CSS.

Umpan Balik Lainnya: Lapisan PHP

Saya telah mengatakannya sebelumnya, tetapi perlu diulang. Kami membutuhkan lapisan PHP untuk sistem konfigurasi theme.json ini. Saat ini ada tiket terbuka untuk mengatasi hal ini.

Ada dua manfaat utama dari sistem seperti itu. Memiliki API PHP untuk menyatukan konfigurasi akan terasa jauh lebih alami bagi pengembang tema tradisional. Saya melihatnya sebagai sedikit cabang zaitun, menunjukkan itikad baik bahwa pengembang inti/Gutenberg mengakui bahwa banyak penulis tema akan lebih mudah masuk ke fitur FSE melalui bahasa pemrograman yang sudah dikenal.

Keuntungan kedua adalah ada banyak ide plugin untuk memperluas gaya global, pengeditan situs, dan banyak lagi jika ada cara mudah untuk menghubungkan ke sistem JSON tema dan menimpa berbagai hal. Kait filter sederhana akan membuat ini tidak menyakitkan.