⚡ Jawaban Singkat / Key Takeaways: WordPress 6.7 menyimpan setiap blok Gutenberg sebagai HTML terstruktur dengan komentar pembuka dan penutup (<!-- wp:paragraph -->). Kamu bisa mengekspos markup ini ke React, Next.js, atau static site generator lewat REST API maupun WPGraphQL, lalu merender ulang blok tersebut di frontend non-WordPress. Strategi ini memungkinkan tim konten tetap menikmati UX Full Site Editing sementara frontend-mu berjalan full headless dengan performa maksimal.
Kenapa Arsitektur Headless Sering “Buta” dengan Block Data WordPress?
Kamu sudah investasi waktu membangun workflow headless dengan Next.js atau Astro. Tim konten-mu senang karena WordPress tetap jadi CMS yang mereka kenal. Tapi begitu kamu mengaktifkan Full Site Editing di WordPress 6.7, semuanya mulai retak.
Masalah klasiknya begini: REST API WordPress secara default hanya mengembalikan content.rendered dalam bentuk HTML final. Artinya, semua blok Gutenberg sudah “dimasak” menjadi markup polos. Informasi tentang blok apa yang dipakai, atribut masing-masing blok, dan struktur nested block-nya lenyap ditelan proses render.
Akibatnya, frontend React-mu cuma bisa menampilkan HTML mentah tanpa tahu bahwa bagian itu adalah kolom, atau bahwa paragraf itu punya warna background custom. Kamu kehilangan semua konteks blok yang justru jadi kekuatan utama WordPress modern.
Ini bukan bug. Ini konsekuensi dari arsitektur yang menganggap API sebagai output channel, bukan data channel. Tapi WordPress 6.7 sudah menyediakan jalan keluarnya.
Apa Itu Block Markup dan Kenapa Kamu Perlu Peduli?
Setiap kali kamu mengetik di block editor, WordPress menyimpan data dalam dua bentuk: HTML final (yang kamu lihat di frontend) dan block serialization (representasi mentah dari setiap blok). Block serialization ini punya struktur khas berupa komentar HTML:
<!-- wp:paragraph {"textColor":"primary","fontSize":"large"} -->
<p class="has-primary-color has-large-font-size">Halo dari editor!</p>
<!-- /wp:paragraph -->Tiga komponen kunci di sini: block delimiter (komentar pembuka/penutup), block attributes (JSON di dalam delimiter), dan inner HTML (konten yang dirender). Kalau kamu bisa mengakses data ini via API, kamu bisa merekonstruksi ulang halaman WordPress dengan komponen React native tanpa bergantung pada template PHP.
Bahkan lebih jauh, kamu bisa mem-parsing atribut JSON untuk mengisi props komponen React-mu. Sebuah blok wp:columns bisa jadi <Grid columns={2} />. Sebuah blok wp:group dengan background gradient bisa jadi <Section variant="gradient" />. Kontrol penuh di tanganmu.
Endpoint REST API yang Jarang Dieksplorasi Developer Headless
WordPress 6.7 memperkenalkan sejumlah endpoint REST API yang secara spesifik menangani block data. Kebanyakan developer headless masih berkutat dengan /wp/v2/posts, padahal endpoint yang lebih powerful sudah tersedia:
/wp/v2/block-renderer/<block-name>: Render blok secara server-side dengan atribut kustom tanpa perlu frontend WordPress/wp/v2/block-directory: Akses block directory WordPress.org untuk instalasi block baru via API/wp/v2/templates: Ambil template FSE lengkap beserta struktur block-nya/wp/v2/template-parts: Ambil bagian template seperti header, footer, atau sidebar dalam format block serialization
Yang paling menarik untuk arsitektur headless adalah endpoint templates. Responsenya mengandung field content.raw yang berisi block markup asli sebelum dirender. Inilah data yang bisa kamu parsing dan konversi menjadi komponen React:
// GET /wp/v2/templates?slug=home
{
"id": 1,
"slug": "home",
"content": {
"raw": "<!-- wp:group {"backgroundColor":"primary"} -->\n...<!-- /wp:group -->",
"rendered": "<div class="has-primary-background-color">...</div>"
}
}Perhatikan bahwa content.raw memberikanmu block markup utuh. Sedangkan content.rendered hanya memberi HTML matang yang sudah kehilangan metadata blok. Untuk workflow headless yang canggih, kamu selalu ingin memulai dari .raw.
WPGraphQL dan Strategi Block Serialization yang Lebih Granular
Kalau REST API memberikanmu content.raw sebagai satu string besar, WPGraphQL memungkinkan pendekatan yang jauh lebih presisi. Dengan plugin WPGraphQL dan ekstensi wp-graphql-gutenberg, setiap blok menjadi node tersendiri dalam GraphQL tree.
Ini artinya kamu bisa melakukan query seperti:
query HomePage {
template(id: "home", idType: SLUG) {
blocks {
name
attributes {
... on CoreGroupBlockAttributes { backgroundColor }
... on CoreHeadingBlockAttributes { level }
}
innerBlocks { name }
}
}
}Dengan struktur ini, frontend React-mu tidak perlu melakukan HTML parsing manual. Setiap blok sudah terurai sebagai objek typed yang bisa langsung di-map ke komponen. Sebuah query GraphQL tunggal bisa menggantikan puluhan baris kode parsing yang rawan error.
Static Site Generation: Dari Block Markup ke HTML Statis dalam Satu Pipeline
Static site generator seperti Astro, Hugo, atau Eleventy biasanya mengonsumsi Markdown atau headless CMS API. Tapi dengan block markup WordPress 6.7, kamu bisa membangun pipeline yang lebih kaya. Begini alurnya:
- Fetch block markup via REST API atau GraphQL saat build time
- Parse JSON attributes dari setiap delimiter blok
- Map setiap blok ke komponen React, Vue, atau Svelte
- Render menjadi HTML statis dengan hydration opsional
- Deploy ke CDN sebagai situs statis yang ultra-cepat
Keuntungan terbesarnya: tim konten tetap menggunakan WordPress dan FSE seperti biasa. Mereka bisa mengubah layout, warna, tipografi, dan konten lewat block editor yang intuitif. Sementara itu, pipeline SSG-mu menangkap semua perubahan itu sebagai block data dan menghasilkan ulang seluruh situs statis secara otomatis.
Kamu mendapatkan yang terbaik dari dua dunia: editing experience WordPress yang matang, dan delivery performance static site yang bisa skor 100 di Lighthouse tanpa effort tambahan.
React Block Renderer: Rekonstruksi Blok Tanpa Bergantung pada Template PHP
Ini adalah titik di mana banyak tim headless menyerah. Mereka sudah punya block markup dari API, tapi tidak tahu cara merendernya di React. Solusinya adalah membangun block renderer registry — sebuah mapping sederhana antara nama blok WordPress dan komponen React:
const blockMap = {
"core/paragraph": ParagraphBlock,
"core/heading": HeadingBlock,
"core/group": GroupBlock,
"core/columns": ColumnsBlock,
"core/button": ButtonBlock,
// ...daftarkan semua blok yang dipakai
};
function renderBlock(block) {
const Component = blockMap[block.name];
if (!Component) return renderFallback(block);
return <Component {...block.attributes}>
{block.innerBlocks?.map(renderBlock)}
</Component>;
}Pendekatan ini disebut recursive block resolution. Setiap komponen menerima atribut blok sebagai props dan merender innerBlocks secara rekursif. Hasilnya adalah pohon komponen React yang identik dengan struktur blok WordPress, namun sepenuhnya berjalan di luar ekosistem PHP.
Kejutan yang sering bikin developer tersenyum: sebagian besar blok WordPress sebenarnya punya struktur yang sederhana. Blok core/paragraph cuma butuh <p>. Blok core/heading tinggal render <h2> atau <h3> sesuai atribut level. Kamu bisa memulai dari 5-10 blok yang paling sering dipakai tim konten-mu, lalu memperluas registry seiring kebutuhan.
Menangani Global Styles FSE di Frontend React
Satu tantangan yang kerap terlewat adalah global styles. WordPress 6.7 menyimpan konfigurasi theme.json di endpoint /wp/v2/global-styles. Data ini mencakup palet warna, preset tipografi, spacing scale, dan konfigurasi layout yang didefinisikan oleh theme author maupun customizer.
Daripada menebak-nebak nilai CSS di frontend React-mu, kamu bisa membaca global styles langsung dari API dan mengonversinya menjadi CSS custom properties atau Tailwind config:
// GET /wp/v2/global-styles/1
// Response menyertakan:
{
"settings": {
"color": {
"palette": [
{ "slug": "primary", "color": "#1a1a2e" },
{ "slug": "accent", "color": "#e94560" }
]
},
"typography": {
"fontSizes": [
{ "slug": "small", "size": "0.875rem" },
{ "slug": "large", "size": "2rem" }
]
}
}
}Dengan mengambil file theme.json yang sama, frontend-mu akan selalu sinkron dengan tampilan editor. Kalau tim konten mengubah warna aksen, React-mu ikut berubah. Tanpa deploy ulang, tanpa sinkronisasi manual.
Keamanan dan CORS: Jangan Sampai Block Markup Jadi Celah
Mengekspos block data via API membawa implikasi keamanan tersendiri. Block markup mentah bisa mengandung informasi yang tidak dimaksudkan untuk publik. Kalau ada plugin custom yang menyematkan API key atau konfigurasi internal di atribut blok, data itu ikut terbawa ke frontend headless.
Strategi mitigasi yang direkomendasikan:
- Audit atribut blok sebelum mengekspos endpoint ke publik. Pastikan tidak ada data sensitif yang bocor lewat block attributes.
- Gunakan application password untuk request server-to-server, bukan cookie-based auth yang rawan CSRF.
- Terapkan CORS whitelist ketat via filter
rest_allowed_originsuntuk membatasi domain mana yang boleh mengakses endpoint block. - Sanitasi output di sisi frontend. Jangan pernah mengeksekusi
dangerouslySetInnerHTMLtanpa sanitasi DOMPurify atau sejenisnya.
Poin terakhir ini penting: meskipun WordPress sudah membersihkan markup di sisi server, frontend React-mu tetap harus melakukan sanitasi ulang sebagai lapisan pertahanan tambahan. Defense in depth bukan paranoia, ini best practice.
Performa: Apakah Block Parsing di Frontend Akan Memperlambat Situs?
Pertanyaan yang selalu muncul: kalau kami mem-parsing block markup di React, bukankah itu menambah overhead dibanding HTML statis? Jawabannya tergantung strategi implementasi. Kalau kamu mem-parsing block markup di client-side setiap kali halaman dimuat, iya, ada overhead.
Tapi arsitektur yang benar melakukan parsing ini sekali saja: saat build time. Static site generator seperti Next.js atau Astro mem-parsing block data di server saat build, menghasilkan HTML statis, lalu men-deploy-nya. Pengguna akhir tidak pernah merasakan overhead parsing karena semuanya sudah selesai sebelum deployment.
Untuk use case yang butuh render dinamis (misalnya preview konten sebelum publish), kamu bisa menggunakan ISR (Incremental Static Regeneration) di Next.js atau on-demand revalidation. WordPress webhook mentrigger rebuild halaman yang berubah saja, bukan seluruh situs.
Baca juga: FSE Bikin Skor Core Web Vitals Merah? Ini Biaya Tersembunyi CSS untuk memahami lebih dalam tentang performa block theme.
FAQ: Pertanyaan Umum Seputar Block Markup dan Headless WordPress 6.7
Apakah block markup WordPress 6.7 bisa langsung dipakai di Next.js tanpa plugin tambahan?
Bisa. REST API bawaan WordPress 6.7 sudah menyediakan endpoint /wp/v2/templates dan /wp/v2/posts dengan field content.raw yang berisi block markup. Kamu tidak butuh plugin khusus untuk mengambil data ini. Namun, untuk pengalaman yang lebih baik dengan typed block tree, WPGraphQL beserta ekstensi wp-graphql-gutenberg sangat direkomendasikan karena setiap blok menjadi node GraphQL yang terstruktur.
Bagaimana cara menangani custom block buatan sendiri di frontend React?
Custom block mengikuti struktur yang sama dengan core block. Nama blok-nya mengikuti pola namespace/block-name (contoh: acme/testimonial-card). Kamu tinggal mendaftarkan nama ini di block renderer registry React dengan komponen yang sesuai. Atribut blok yang didefinisikan di block.json otomatis muncul sebagai JSON dalam block delimiter dan bisa dibaca sebagai props komponen.
Apakah block markup berubah saat konten diperbarui oleh editor non-teknis?
Ya, dan ini justru kelebihannya. Setiap kali editor memperbarui konten lewat block editor, WordPress menyimpan ulang block markup dengan atribut baru. Kalau kamu menggunakan SSG dengan webhook, perubahan ini otomatis mentrigger rebuild. Editor tidak perlu tahu apa pun tentang React atau GraphQL. Mereka cukup edit seperti biasa di WordPress.
Apakah pendekatan ini kompatibel dengan WordPress multisite?
Sepenuhnya kompatibel. Endpoint REST API WordPress mendukung multisite secara native. Setiap subsite punya namespace API sendiri. Untuk WPGraphQL, setiap subsite bisa mengaktifkan plugin-nya secara independen. Strategi ini bahkan memungkinkan satu frontend React mengonsumsi block markup dari beberapa subsite sekaligus.
Saatnya Bangun Jembatan Antara FSE dan Frontend Headless-mu
WordPress 6.7 bukan lagi CMS monolitik yang memaksa kamu memilih antara editing experience dan arsitektur modern. Dengan block markup yang terekspos lewat REST API dan GraphQL, kamu bisa memberikan yang terbaik untuk tim konten dan tim engineering sekaligus.
Mulailah dari satu endpoint /wp/v2/templates. Ambil content.raw-nya. Parsing JSON attributes dari block delimiter. Bangun 5 komponen React pertama untuk blok yang paling sering dipakai. Selebihnya, iterasi sambil berjalan.
Headless WordPress dengan FSE bukan lagi eksperimen. Ini arsitektur produksi yang sudah dipakai oleh tim-tim yang serius menggabungkan content velocity WordPress dan delivery performance Jamstack. Kalau kamu tertarik mendalami topik-topik seputar headless WordPress, React, dan arsitektur modern, baca juga panduan Headless WordPress dengan Next.js kami.
Untuk referensi lebih lanjut, kamu bisa mengecek dokumentasi resmi WordPress REST API Handbook, spesifikasi WPGraphQL, dan panduan Incremental Static Regeneration Next.js.
