Implikasi WordPress Bergabung dengan Block Protocol

Matt Mullenweg (pencipta WordPress) telah menyatakan minatnya agar editor WordPress mematuhi Block Protocol, spesifikasi yang baru-baru ini dirilis yang bertujuan untuk membuat "blok" menjadi portabel di seluruh aplikasi.

Ketika saya mengetahui tentang minat Matt, saya cukup senang, karena perkembangan seperti itu dapat menghasilkan beberapa konsekuensi positif bagi WordPress dan aktor lain juga. Kegembiraan saya berasal dari apa yang terjadi dengan GraphQL, di mana rilis server, klien, dan alat yang mengikuti spesifikasi umum telah menghasilkan ekosistem yang kaya; dan dari pengembangan plugin saya sendiri yang dapat mendukung fitur baru melalui protokol.

Dalam artikel ini, saya akan menganalisis ini, dan beberapa hasil potensial lainnya. Namun sebelum melakukannya, mari kita telusuri konteks ceritanya: apa itu blok, apa yang ingin dicapai Protokol Blok, dan bagaimana semuanya terhubung ke WordPress.

Apa Itu Blok?

Saat bekerja dengan pustaka berbasis JavaScript, seperti React atau Vue, kami bekerja dengan "komponen" yang merupakan potongan kode (biasanya terdiri dari HTML, gaya CSS, dan JavaScript) yang dikelompokkan bersama. Komponen merender tata letak yang ditentukan atau menghasilkan fungsionalitas tertentu, seperti carousel gambar, kalender acara, atau header sederhana. Untuk merender konten, komponen dapat mengambil data dari server melalui panggilan API, atau memiliki data yang disediakan melalui props oleh beberapa komponen ancestor yang membungkusnya. Dengan memasukkan datanya, komponen menjadi dapat digunakan kembali, mampu menghasilkan hasil yang berbeda untuk konteks atau aplikasi yang berbeda.

Sebuah "blok" juga merupakan komponen, tetapi tingkat tinggi, menegaskan tujuan yang pasti, dan mendefinisikan persyaratan untuk menghasilkan tata letak atau fungsionalitas yang diinginkan. Ini adalah komponen terluar dari hierarki komponen yang membungkus satu sama lain, sehingga memiliki pandangan mata burung tentang mereka.

Kita bisa bermain dengan komponen saat menggunakan Notion, di mana setiap tindakan (apakah itu menulis teks, menambahkan daftar peluru, membuat tabel atau apa pun) dilakukan dengan memasukkan satu atau lain blok:

Blok adalah konsep, bukan teknologi. Itu dapat diimplementasikan pada bahasa apa pun: tidak hanya JavaScript untuk memberi daya pada klien, tetapi juga bahasa sisi server untuk membuat tata letak. Blok tidak boleh disamakan dengan komponen web, yang merupakan kumpulan teknologi untuk menghasilkan komponen. Mereka juga tidak saling eksklusif — kita dapat menggunakan komponen web untuk membuat blok.

Mengambil analogi dari dunia gesit: jika MVP, atau Minimum Viable Product, adalah bagian terkecil dari pekerjaan untuk meluncurkan dan memasarkan proyek komersial, kita dapat menganggap blok tersebut sebagai MUC, atau Minimum Usable Component, sebagai unit dasar pekerjaan yang memberikan koherensi dan kepribadian pada suatu aplikasi.

Apa Itu Protokol Blok?

Komponen cukup dapat digunakan kembali. Misalnya, mencari "react component" di npm akan menghasilkan banyak library yang menawarkan komponen yang dapat langsung kita impor ke dalam aplikasi React kita.

Blok, bagaimanapun, adalah cerita yang berbeda, karena sebagian besar dirancang untuk beberapa aplikasi tertentu. Sementara blok harus menyediakan sarana untuk berinteraksi dengannya (seperti menawarkan API untuk menginisialisasi dan merendernya, atau mengekspos skema JSON yang menjelaskan data apa yang dibutuhkannya sebagai input), sarana ini biasanya bergantung pada aplikasi tempat blok tersebut hidup. , jadi kami tidak dapat menggunakan kembali blok di seluruh aplikasi.

Di situlah Block Protocol masuk. Ini memberikan spesifikasi untuk blok dan aplikasi yang harus dipenuhi, yang bertujuan untuk memungkinkan blok disematkan dalam aplikasi apa pun, tidak hanya yang dirancang untuk mereka. Sama seperti komponen, blok kemudian dapat digunakan kembali di seluruh aplikasi.

Blok dan WordPress yang Dapat Digunakan Kembali

Sejak versi 5.0 dari Desember 2018, pengalaman default di WordPress untuk membuat konten telah melalui blok. Sejak versi 5.9 yang baru-baru ini dirilis, pengalaman ini telah diperluas ke dalam pembuatan tata letak situs web melalui Pengeditan Situs Penuh (FSE). Pengalaman modern untuk membuat konten dan tema untuk WordPress sekarang melalui blok.

Ketika Joel Spolsky baru-baru ini memperkenalkan Block Protocol kepada dunia, dia melakukannya dari blognya yang diberdayakan WordPress. Saat menjelaskan bagaimana dia menggunakan blok untuk menyusun postingannya, dia menyarankan agar blok dapat digunakan kembali di seluruh web. Ini adalah saran langsung bahwa blok WordPress harus dapat digunakan kembali di seluruh web, yang segera disetujui oleh Matt Mullenweg.

Mari kita analisis selanjutnya konsekuensi apa yang dapat kita ramalkan dari perkembangan seperti itu jika itu terjadi.

Siapa yang Akan Menggunakan Protokol Blok?

Ini adalah deskripsi Joel tentang bagaimana Protokol Blok muncul:

“[Implementasi blok oleh aplikasi yang berbeda] sepenuhnya eksklusif dan tidak standar.

Saya pikir, bukankah lebih keren jika blok dapat dipertukarkan dan digunakan kembali di seluruh web?

[...] Pengguna mungkin ingin menggunakan blok yang lebih menarik yang mereka lihat di WordPress atau Medium atau Notion, tetapi editor saya tidak memilikinya. Blok tidak dapat dibagikan atau dipindahkan dengan sangat mudah, dan pengguna kami terbatas pada fitur dan kemampuan yang sempat kami terapkan kembali.”

Sementara saya setuju 100% dengan motivasi Joel, saya percaya bahwa mengharapkan Notion atau Medium untuk mengimplementasikan blok mereka menggunakan protokol yang dibagikan secara publik tidak realistis. Mengapa mereka? Tentu saja, mereka ingin blok mereka menjadi milik. Jika Medium membuat bloknya sendiri tersedia untuk aplikasi apa pun untuk disematkan, maka siapa pun dapat dalam semalam menawarkan klon Medium dan mengalihkan lalu lintas dari mereka. Sama untuk Notion. Menjadi platform komersial yang bertujuan untuk mendapatkan pengguna berdasarkan fitur canggih dan pengalaman pengguna yang luar biasa, tidak ada gunanya bagi mereka untuk memberikan teknologi mereka (yaitu, mereka masih dapat mematuhi protokol untuk penggunaan internal mereka sendiri, tetapi kemudian kami, orang luar, tidak akan mendapat manfaat darinya).

Jadi, siapa lagi, selain WordPress, yang mungkin ingin mematuhi Protokol Blok? Siapa yang akan diuntungkan?

Kesan saya adalah sebagai berikut:

• Tim tanpa anggaran besar
  Alih-alih mengembangkan blok mereka sendiri dari awal (yang membutuhkan banyak usaha dan karena itu menuntut tim yang berdedikasi), situs web dapat dibangun menggunakan blok yang dikembangkan oleh orang lain; tim kemudian dapat menyesuaikan blok untuk aplikasi mereka sendiri dan mungkin berkontribusi kembali ke kode sumber terbuka blok.
• Aplikasi yang perlu mengejar ketinggalan untuk menawarkan pengalaman pengguna yang menarik
  Medium dan Notion populer karena pengalaman penggunanya yang menarik. Jika kami dapat memberikan pengalaman pengguna yang serupa untuk situs web kami (dan dengan biaya yang sangat sedikit atau tanpa biaya), mengapa kami tidak melakukannya?
  Ini tidak selalu terbatas pada situs web kecil, tetapi juga dapat terjadi pada situs web populer yang tertinggal dalam perlombaan blok. Misalnya, beberapa waktu lalu saya melihat Mailchimp bereksperimen dengan editor berbasis blok modern untuk menulis buletin (saya tidak dapat menemukan editor baru ini lagi… apakah mereka telah mengambilnya?). Saya telah mencobanya, tetapi buggy, jadi saya kembali ke editor split-pane klasik (yang juga mendukung blok tetapi dari jenis yang berbeda, tidak dapat diedit di tempat). Mungkinkah Mailchimp mendapat manfaat dari penggunaan blok yang ditawarkan oleh WordPress?

• Sistem Manajemen Konten
  Mirip dengan WordPress, CMS lain juga dapat mengambil manfaat dari menawarkan blok siap pakai untuk membangun aplikasi. Memang, Drupal Gutenberg telah berusaha membawa editor WordPress ke Drupal. Berkat Block Protocol, tugas ini bisa lebih mudah diselesaikan.
• Proyek sumber terbuka
  Mirip dengan komponen yang tersedia melalui npm, jika blok dapat digunakan kembali, maka hanya masalah waktu sebelum komunitas mulai membangun blok dan menawarkannya secara bebas sebagai sumber terbuka (baik melalui GitHub, Block Hub, atau di tempat lain) untuk kepentingan setiap orang.

Bagaimana Orang Lain Akan Diuntungkan Dengan Bergabungnya WordPress dengan Block Protocol?

Kami baru saja menjelajahi siapa yang mungkin mendapat manfaat, dan karena itu mungkin ingin bergabung dengan Protokol Blok. Tetapi selain itu, kita dapat bertanya pada diri sendiri: Bagaimana mereka bisa mendapatkan keuntungan jika WordPress bergabung dengan Block Protocol?

Ini kesan saya:

• Akses ke blok WordPress
  Jawaban yang paling jelas adalah bahwa semua blok yang saat ini tersedia untuk WordPress (melalui editor dan FSE) juga akan tersedia untuk aplikasi mereka sendiri, baik yang berbasis WordPress atau tidak.
• Bergabung dengan proses yang dipimpin komunitas untuk membuat blok
  Membuat blok adalah proses yang memakan waktu dan tenaga. Proyek Gutenberg membutuhkan waktu 5 tahun untuk menghasilkan Editor Situs Lengkap, dan ini masih dalam proses. Dan jumlah orang yang terlibat dengan rilis baru WordPress ada ratusan, dengan yang terbaru melebihi 600 kontributor.
  Komunitas WordPress terus menginvestasikan banyak sumber daya dalam komunikasi untuk memastikan proses ini berjalan semulus mungkin, bahkan termasuk pertemuan retrospektif untuk menganalisis apa yang salah, dan memperbaikinya untuk rilis mendatang.
  Berapa banyak organisasi yang dapat menyamai proses yang dipoles dengan baik dalam mengelola ratusan orang untuk menghasilkan sumber daya bersama? Untuk alasan ini, bergabung dengan upaya yang dipimpin oleh komunitas WordPress untuk menghasilkan blok, alih-alih melakukannya sendiri, dapat bermanfaat bagi semua orang.
• Pengadopsi besar memberikan kredibilitas dan daya tarik pada protokol
  Block Protocol baru saja dirilis, dan masih berupa draft. Siapa yang akan menggunakannya? Bagaimana proyek akan menghasilkan dukungan dari pemangku kepentingan potensial? Memiliki dukungan WordPress, itu mengirimkan sinyal yang kuat dan menciptakan kepercayaan diri bagi orang lain untuk bergabung dengan mengetahui bahwa proyek tersebut akan memiliki kontributor dan dukungan jangka panjang.

Apa Manfaatnya Untuk WordPress?

Agar WordPress relevan selama 15 tahun ke depan, WordPress perlu bertahan di dunia aplikasi modern yang sangat dinamis. Untuk itu, mulai dari versi 5.0 dan seterusnya, WordPress telah memulai proses modernisasi, yang telah melihatnya bermetamorfosis dari aplikasi yang agak statis, merender tata letak berdasarkan template PHP di sisi server menjadi tetap statis-tetapi-kurang- jadi aplikasi yang mengambil data dari REST API, dan menggunakan blok JavaScript untuk merender konten, dan — sejak versi terbaru 5.9 — tata letak.

Catatan : Ini masih tidak terlalu dinamis, karena tata letak dibuat terlebih dahulu di wp-admin dan disimpan ke DB, alih-alih dihasilkan pada klien yang bereaksi terhadap beberapa tindakan oleh pengguna.

Transformasi ini membutuhkan waktu untuk terwujud, dimulai sejak tahun 2015 ketika Matt Mullenweg meminta komunitas WordPress untuk “mempelajari JavaScript secara mendalam”. Bergabung dengan Block Protocol akan menjadi perhentian lain dalam perjalanan modernisasi WordPress.

Mari kita lihat manfaat apa yang bisa didapat darinya.

Menjaga Pertumbuhan Pangsa Pasarnya

Sampai hari ini, WordPress mendukung 43% dari semua situs web. Meskipun kesuksesannya tidak dapat disangkal, itu masih belum cukup bagi Matt Mullenweg, yang telah menyatakan keinginannya agar WordPress mencapai 85% pangsa pasar. (Menilai apakah pendirian ini benar atau salah berada di luar cakupan artikel ini.)

Sekarang, kita dapat bertanya pada diri sendiri, apa sebenarnya situs WordPress itu? Di masa lalu, dengan arsitektur monolitik berbasis PHP, responsnya cukup jelas. Namun saat ini kami membangun situs web berdasarkan tumpukan yang terdiri dari beberapa teknologi. Kami mungkin memiliki backend WordPress yang memberi daya pada frontend React, memberinya data melalui WP REST API. Apakah itu situs WordPress?

Jawabannya adalah: Saya tidak tahu, tapi mungkin juga tidak masalah. Jika WordPress adalah salah satu teknologi di tumpukan, maka itu akan terus berkembang. Sejauh ini, WordPress hanya dapat mengambil peran CMS, mengelola data untuk diumpankan ke klien. Tapi sekarang, berkat Block Protocol, WordPress dapat mengambil peran baru: menyediakan blok untuk memberi daya pada frontend aplikasi apa pun.

Dalam skenario ini, WordPress akan mengambil peran lebih besar dalam pembuatan situs. Yang akan menyebabkan WordPress masih mendapatkan pangsa pasar, dan menjadi lebih mengakar dalam perangkat pengembangan web, membuatnya lebih sulit untuk menjadi tidak relevan.

Kumpulan Kontributor yang Lebih Besar

Dengan menggunakan blok yang ditawarkan oleh WordPress, pengembang yang biasanya tidak menggunakan WordPress akan mengenalnya, dan, semoga, menghargainya, dan menjadi kontributor kode sumber terbuka. Ini penting karena kumpulan kontributor akan bertambah besar (misalnya, JavaScript memiliki sekitar 3 kali lebih banyak pengembang profesional daripada PHP), dan akan membawa serangkaian keterampilan yang lebih beragam.

Ketersediaan Blok Lebih Lanjut

Tak perlu dikatakan, hub blok akan bekerja dua arah: WordPress akan membuat bloknya tersedia untuk semua orang, tetapi juga blok yang dikodekan untuk orang lain akan tersedia untuk memberi daya pada situs WordPress.

Misalnya, jika Mailchimp memutuskan untuk bergabung menggunakan blok WordPress untuk memberi daya pada editor buletinnya, dan kemudian memperbaikinya atau memproduksi dan merilis bloknya sendiri, maka ini akan tersedia untuk plugin WordPress yang membuat dan mengirim buletin.

Memisahkan Editor WordPress Dari Gutenberg

Gutenberg adalah proyek yang memberikan fondasi untuk editor blok di WordPress. Ini menyediakan mesin yang memungkinkan berinteraksi dengan blok. Misalnya, dibutuhkan output dari metode edit dan save blok, untuk merender HTML di editor dan menyimpannya ke DB.

Namun, editor blok tidak perlu digabungkan ke Gutenberg. Bagaimanapun, "blok" adalah sebuah konsep, dan Gutenberg adalah implementasi khusus. Protokol Blok dapat dengan sempurna ditempatkan di antara mereka, bertindak sebagai penghubung antara konsep dan implementasi.

Akibatnya, sekarang Gutenberg dapat diambil, dan mesin implementasi lainnya dapat menggantikannya, memberikan pengalaman berbeda yang masih ditenagai oleh blok yang sama.

Konsekuensi yang menarik adalah bahwa WordPress sendiri dapat mengambil manfaat dari arsitektur ini, karena Gutenberg tidak tinggal di mana-mana di situs WordPress, tetapi hanya di wp-admin . Dengan kata lain, situs publik yang kami bangun menggunakan WordPress itu sendiri tidak mengandalkan Gutenberg; sebagai gantinya, itu hanya mencetak HTML yang dibuat dengan Gutenberg di backend. Itu sebabnya saya sebutkan sebelumnya bahwa situs WordPress masih belum terlalu dinamis.

Dengan menggunakan Protokol Blok untuk berkomunikasi dengan blok, kita tidak perlu memiliki Gutenberg di sisi klien untuk menggunakan blok. Sebagai gantinya, kita bisa memiliki aplikasi React yang merender blok secara langsung dan berdasarkan interaksi pengguna, membuat situs lebih dinamis.

Ide yang sama dapat bekerja di wp-admin , di halaman apa pun di mana Gutenberg masih belum tersedia (setidaknya sampai tersedia). Misalnya, jika kami ingin menyediakan halaman pengaturan yang sepenuhnya didukung oleh blok untuk plugin kami, dengan Protokol Blok, kami dapat menggunakan React untuk merender blok konfigurasi yang diperlukan (kalender, peta interaktif, bilah geser, dropdown dengan opsi, atau masukan yang sesuai) dan tambahkan sedikit logika PHP untuk menyimpan data di tabel wp_options .

Menanamkan Blok Di Situs yang Menghadapi Publik

Mengambil bagian sebelumnya sedikit lebih jauh, blok sebenarnya dapat disematkan di situs yang menghadap publik agar pengguna dapat berinteraksi dengannya.

Ada banyak kasus penggunaan untuk fitur seperti itu, termasuk:

• menunjukkan kalender bagi pengguna untuk memesan slot rapat, seperti yang dilakukan oleh Calendly;
• memungkinkan pengguna untuk menggambar sesuatu, seperti yang dilakukan oleh Brush Ninja, atau bermain game, seperti pada Block-a-saurus;
• minta pengguna memanipulasi gambar, seperti yang mungkin terjadi dengan pengalaman media yang akan datang dengan FSE.

Contoh lain datang dari plugin WordPress saya sendiri, dan dapat mendukungnya adalah alasan mengapa saya senang dengan Block Protocol. GraphQL API untuk WordPress dikirimkan dengan blok klien GraphiQL yang memungkinkan pembuatan kueri tetap GraphQL:

Pada saat yang sama, saya menyematkan klien GraphiQL di situs dokumentasi agar pengunjung dapat bermain dengannya dan menemukan cara kerja server GraphQL:

Dengan Block Protocol, ide untuk mengekspos klien GraphiQL di situs dokumentasi ini juga dapat diberikan kepada pengguna plugin saya. Kemudian, mereka cukup menyematkan blok GraphiQL di situs publik mereka sendiri untuk mendokumentasikan cara mengambil data dari API GraphQL mereka sendiri untuk pengunjung mereka sendiri.

Membantu Dalam Fase “Kolaborasi” Gutenberg

Mampu menyematkan blok di situs publik juga dapat berguna untuk fase 3 editor blok, yang bertujuan untuk merampingkan kolaborasi guna menghasilkan pengalaman penulisan bersama yang serupa dengan Google Documents atau Dropbox Paper.

Ketika saya menerima tautan ke Dropbox Paper, saya tidak perlu masuk untuk memvisualisasikan isinya:

Demikian pula, kita dapat memiliki sisi klien yang dapat merender dan berinteraksi dengan blok, sehingga pengguna yang tidak masuk juga dapat memberikan umpan balik. Pengunjung ini tidak perlu mengakses wp-admin situs, jadi kami akan memaksimalkan peluang untuk berkolaborasi.

Lebih Meningkatkan Konsep “Single API For Everything”

Konsep blok diperkenalkan sebagai cara untuk menyatukan semua cara berbeda untuk menambahkan konten di situs WordPress. Di masa lalu, saat menggunakan editor "klasik", kita dapat menambahkan kode dinamis melalui widget atau kode pendek, dan memanipulasi tampilan situs melalui penyesuai. Blok tersebut menggantikan semua mekanisme yang berbeda ini dengan menyediakan "API tunggal" untuk memproduksi dan menyesuaikan semua konten di situs.

Penyederhanaan ini telah terjadi di UI. Namun, blok itu sendiri tidak selalu menyediakan satu cara untuk menanganinya, karena blok dinamis memerlukan output yang sama untuk dirender dalam JavaScript dan PHP (yang pertama untuk merender HTML untuk editor, yang terakhir untuk mencetaknya. situs yang menghadap publik). Situasi ini menyebabkan kecemasan bagi pengembang, dan menambah hambatan bagi kontributor baru.

Ada beberapa usulan untuk mengatasi masalah ini (diringkas secara brilian dalam diskusi ini), tetapi tidak ada yang cukup meyakinkan. Plugin WooCommerce juga menangani masalah yang sama, tetapi solusinya tampaknya (bagi saya) agak rumit. Mekanisme untuk membuat kode KERING idealnya disediakan oleh CMS tanpa perlu peretasan.

Protokol Blok dapat memberikan alternatif yang lebih baik. Jika pengembang tidak ingin mengkodekan logika yang sama lagi di PHP, rendering blok dapat dilakukan di frontend dengan menggunakan blok yang sama. Ini akan didasarkan pada rendering sisi klien (CSR) alih-alih rendering sisi server (SSR) yang tidak selalu disarankan (karena dapat memengaruhi pengindeksan konten oleh mesin telusur), tetapi opsi untuk memutuskan salah satunya akan beristirahat pada pengembang.

Sebagai keuntungan sampingan, solusi ini juga dapat menarik lebih banyak pengembang React untuk menggunakan WordPress.

Menggunakan Perkembangan Dari Luar Dunia WordPress

Seperti yang saya sebutkan sebelumnya, mengikuti protokol bersama dapat menyebabkan perkembangan yang tidak terkoordinasi yang menghasilkan ekosistem yang kaya, seperti yang terjadi dengan GraphQL.

Misalnya, SpectaQL adalah generator dokumentasi untuk GraphQL API. Hanya dengan mengikuti spesifikasi GraphQL, proyek ini memungkinkan API untuk didokumentasikan secara otomatis, yang membutuhkan sedikit usaha dari pengembang.

Mematuhi Protokol Blok dapat menghasilkan efek serupa. Kami dapat memperkirakan bahwa beberapa proyek dapat secara otomatis mengekstrak informasi dari block-metadata.json , dan menghasilkan situs statis yang mendokumentasikan semua blok. Ide yang sama saat ini sedang diterapkan untuk Gutenberg. Jika beberapa proyek telah menangani pekerjaan ini untuk Protokol Blok, Gutenberg dapat menumpanginya, dan membebaskan kontributornya untuk menangani tugas lain.

Peningkatan Dukungan Untuk GraphQL

Alasan lain yang sangat menggairahkan saya, adalah bahwa server GraphQL untuk WordPress (WPGraphQL dan GraphQL API saya sendiri untuk WordPress) saat ini tidak dapat memberikan dukungan optimal untuk Gutenberg, karena block.json tidak mendeklarasikan tipe objek atau properti array yang sebenarnya. Misalnya, sebuah blok di Gutenberg dapat mendeklarasikan properti bertipe array , tetapi GraphQL perlu mengetahui bahwa itu adalah array bertipe String .

Protokol Blok sangat menganjurkan untuk menentukan tipe akhir dari properti:

Jika tersedia, blok HARUS mengharapkan dan menangani bidang entityTypes yang berisi definisi tipe entitas untuk entitas apa pun yang dikirim ke blok.

Oleh karena itu, jika blok WordPress mematuhi Protokol Blok, skema JSON mereka akan ditingkatkan untuk memberikan informasi ini, dan plugin GraphQL kemudian dapat mengambil data blok tanpa menggunakan peretasan.

Membungkus

Dalam artikel ini, saya telah membahas beberapa konsekuensi potensial dari bergabungnya WordPress dengan Block Protocol, menunjukkan bahwa itu akan menghasilkan hasil yang positif. Namun, saya belum menyentuh seberapa layak hal itu terjadi.

Apakah secara teknis mungkin? Bisakah itu dilakukan tanpa merusak kompatibilitas ke belakang? Apakah manfaat potensial lebih besar daripada upaya yang diperlukan? Apakah masuk akal jika Protokol Blok ada di tempat pertama atau persyaratan yang berbeda oleh aplikasi yang berbeda tidak dapat didamaikan di tingkat blok?

Semua pertanyaan ini (dan banyak lainnya) perlu mendapat tanggapan sebelum keputusan untuk bergabung dengan Protokol Blok diambil atau tidak. Sebagaimana Matt Mullenweg telah menyatakan minatnya, sekarang saatnya bagi komunitas untuk mempertimbangkan dan memutuskan apakah WordPress harus berhenti dan mengisi bahan bakar di pelabuhan baru ini dalam perjalanan modernisasinya, atau lewati saja dan terus berlayar ke depan.