Block Gutenberg Jadulmu Masih Pakai Float? Migrasi ke Grid Sekarang Juga

Kenapa Grid Layout Itu Bukan Sekadar Tren CSS

Kamu ingat block pertama yang kamu bikin? Yang pakai registerBlockType, editornya masih RichText biasa, dan styling-nya cuma modal float: left atau display: inline-block. Itu dulu cukup. Sekarang? Nggak lagi.

WordPress 6.6 ke atas udah bawa layout grid native ke block editor. Fitur ini bukan sekadar gimmick visual. Grid support memungkinkan block kamu kompatibel dengan theme JSON, responsive secara otomatis, dan siap buat full-site editing. Kalau block lamamu masih pakai pendekatan CSS jadul, kamu melewatkan arsitektur yang jadi fondasi Gutenberg phase 3.

Artikel ini adalah walkthrough kode buat developer yang mau porting block klasik ke grid layout modern plus interaktivitas client-side. Bukan teori. Langsung ke kode.

Anatomi Block Klasik vs Block Modern: Di Mana Letak Masalahnya?

Sebelum porting, kamu harus paham dulu apa yang berubah. Block klasik biasanya punya struktur seperti ini:

// block.json — versi lama
{
    "apiVersion": 2,
    "name": "my-plugin/old-card-block",
    "title": "Old Card Block",
    "category": "design",
    "supports": {
        "align": ["wide", "full"]
    },
    "editorScript": "file:./index.js"
}

Strukturnya sederhana. Tapi ada tiga kelemahan besar:

• Tidak ada layout awareness. Block nggak tahu dia ada di dalam grid, stack, atau row container. Semua di-handle manual lewat CSS custom.
• Zero client-side interactivity. Semua update harus lewat server render. Klik tombol? PHP reload. Filter konten? PHP lagi.
• CSS bloated. Setiap block bawa stylesheet sendiri yang sering konflik dengan theme.

Sekarang bandingkan dengan block modern:

// block.json — versi modern dengan grid
{
    "apiVersion": 3,
    "name": "my-plugin/new-card-block",
    "title": "New Card Block",
    "category": "design",
    "supports": {
        "align": ["wide", "full"],
        "layout": {
            "default": {
                "type": "grid",
                "columnCount": 3,
                "minimumColumnWidth": "18rem"
            }
        },
        "spacing": {
            "blockGap": true,
            "margin": true,
            "padding": true
        },
        "interactivity": true
    },
    "viewScriptModule": "file:./view.js"
}

Perhatikan perbedaannya. Block modern punya apiVersion: 3, layout grid, spacing support, dan viewScriptModule untuk interaktivitas. Semua ini di-handle native oleh WordPress, bukan oleh CSS custom yang kamu tulis sendiri.

Langkah Demi Langkah: Porting Block Klasik ke Grid

1. Audit Struktur Block Lamamu Dulu

Jangan langsung refactor. Buka block.json lamamu dan checklist tiga hal ini:

• Apakah block ini punya inner blocks atau cuma konten statis?
• Apakah styling-nya bergantung pada breakpoint manual di CSS?
• Apakah ada event handler (onClick, onChange) di editor yang perlu di-port ke frontend?

Kalau jawabannya “iya” buat lebih dari satu, block kamu kandidat sempurna buat porting ke grid. Block dengan inner blocks paling diuntungkan karena grid native otomatis mengatur tata letak children tanpa perlu CSS tambahan.

2. Implementasi Grid Native di block.json

Ini langkah paling krusial. Tambahkan properti layout ke supports:

"supports": {
    "layout": {
        "default": {
            "type": "grid",
            "columnCount": null,
            "minimumColumnWidth": "16rem"
        },
        "allowEditing": true,
        "allowSwitching": true
    },
    "spacing": {
        "blockGap": {
            "sides": ["horizontal", "vertical"]
        }
    }
}

Parameter columnCount: null artinya WordPress yang otomatis menghitung jumlah kolom berdasarkan lebar container dan minimumColumnWidth. Ini jauh lebih pintar daripada hardcode grid-template-columns: repeat(3, 1fr) di CSS. Kamu bisa pelajari lebih lanjut soal konfigurasi ini di dokumentasi resmi Block Supports WordPress.

Pro tip: Jangan set columnCount fixed. Biarkan null. Biarkan theme JSON dan viewport menentukan jumlah kolom. Ini yang bikin block kamu benar-benar responsif tanpa media query.

3. Tambah Interaktivitas Client-Side dengan Interactivity API

Sampai di sini block kamu udah pakai grid modern. Tapi masih statis. Sekarang saatnya menambahkan interaktivitas client-side pakai @wordpress/interactivity.

Pertama, daftarkan module di block.json:

"viewScriptModule": "file:./view.js",
"supports": {
    "interactivity": true
}

Lalu bikin view.js:

import { store, getContext } from '@wordpress/interactivity';

store('my-plugin/new-card-block', {
    state: {
        get isExpanded() {
            const ctx = getContext();
            return ctx.expanded;
        }
    },
    actions: {
        toggleCard() {
            const ctx = getContext();
            ctx.expanded = !ctx.expanded;
        }
    },
    callbacks: {
        initCard() {
            const ctx = getContext();
            ctx.expanded = false;
        }
    }
});

Di PHP render callback kamu, binding directive-nya:

<div 
    data-wp-interactive="my-plugin/new-card-block" 
    data-wp-context='{ "expanded": false }'
    data-wp-init="actions.initCard"
    class="wp-block-my-plugin-new-card-block"
>
    <button data-wp-on--click="actions.toggleCard">
        Toggle
    </button>
    <div data-wp-bind--hidden="!state.isExpanded">
        Konten tersembunyi di sini...
    </div>
</div>

Interactivity API ini masih experimental. Tapi udah production-ready buat sebagian besar use case. Kelebihannya: nggak perlu React, nggak perlu hydration, dan ukurannya kecil banget. Semua interaksi berjalan di client tanpa bolak-balik ke server. Referensi lengkapnya ada di Interactivity API WordPress Developer Guide.

4. Testing dan Debugging yang Bener

Jangan cuma tes di editor. Ini checklist testing wajib:

• Resize viewport dari 320px sampai 2560px. Grid harus otomatis menyesuaikan tanpa horizontal scroll.
• Nested blocks — taruh block kamu di dalam group, columns, dan cover block. Layout jangan pecah.
• Disable JS — pastikan konten tetap terbaca meski interaktivitas mati. Progressive enhancement.
• Cek console — Interactivity API bakal log warning kalau directive salah ketik atau namespace konflik.

Untuk testing yang lebih sistematis, kamu bisa manfaatkan Playwright buat automation test viewport dan interaksi block. Ini jadi standar baru di kalangan developer WordPress buat memastikan block berjalan mulus di berbagai kondisi.

Satu Hal yang Bikin Developer Sering Salah

Banyak developer mengira grid support di Gutenberg sama dengan CSS Grid biasa. Ini keliru. Grid di block editor adalah abstraksi di atas CSS Grid. WordPress generate class seperti .is-layout-grid dan .wp-container-core-post-template-is-layout-1 secara otomatis. Kamu nggak perlu menyentuh CSS-nya.

Masalah muncul ketika developer mencoba override class-class itu dengan CSS custom. Jangan. Gunakan theme.json atau add_theme_support('appearance-tools') buat mengontrol spacing dan layout secara global. Biarkan WordPress yang ngurusin CSS grid-nya.

Intinya: percaya sama sistem layout native. Semakin sedikit CSS custom yang kamu tulis, semakin kompatibel block kamu dengan semua theme block-based. Kalau kamu masih pakai WordPress versi lama, baca dulu panduan upgrade WordPress 7.0 biar lingkungan development kamu siap.

Kapan Kamu Nggak Perlu Porting?

Nggak semua block perlu dimigrasi. Tetap pakai pendekatan klasik kalau:

• Block kamu cuma render shortcode atau third-party embed yang strukturnya dikontrol eksternal.
• Target kamu masih WordPress 6.4 ke bawah (tapi serius, upgrade).
• Block kamu adalah single element tanpa children — misalnya divider atau spacer custom.

Tapi kalau block kamu punya dua atau lebih children elements, porting ke grid itu investasi satu jam yang bakal hemat puluhan jam maintenance ke depan.

FAQ

Apa minimum WordPress version buat pakai grid layout native di block?

WordPress 6.6 adalah rilis pertama yang membawa grid layout support ke block editor. Tapi buat pengalaman paling stabil dengan Interactivity API, sebaiknya gunakan WordPress 6.7 ke atas.

Apakah grid layout Gutenberg kompatibel dengan theme non-block (classic theme)?

Kompatibel, tapi dengan catatan. Classic theme yang nggak mendeklarasikan add_theme_support('wp-block-styles') mungkin nggak me-load stylesheet grid WordPress. Kamu bisa fallback manual dengan enqueue wp-block-library stylesheet, atau lebih baik: dorong klien kamu buat migrasi ke block theme.

Bagaimana cara debugging Interactivity API kalau directive nggak jalan?

Buka browser console. Interactivity API otomatis log error kalau namespace nggak match antara store() di JS dan data-wp-interactive di HTML. Tools tambahan: install @wordpress/interactivity-debug package buat development mode yang ngasih insight lebih detail tentang state changes.

Apakah aku bisa pakai grid layout tanpa Interactivity API?

Bisa banget. Grid layout dan Interactivity API adalah dua fitur terpisah. Kamu bisa upgrade block ke grid support dulu, lalu menambahkan interactivity belakangan. Pendekatan inkremental ini justru yang paling aman buat project production.

Kesimpulan

Porting block klasik ke grid layout itu bukan sekadar “biar keren.” Ini soal future-proofing kode kamu. WordPress makin bergerak ke arah native layout system, dan block yang masih pakai float atau inline-block bakal makin susah di-maintain dalam dua tahun ke depan.

Mulai dari satu block dulu. Audit. Porting. Tes. Lalu ulangi. Satu jam per block. Dalam seminggu, seluruh plugin kamu udah pakai grid native dan interaktivitas modern.

Kalau ada pertanyaan spesifik soal porting blockmu, tulis di kolom komentar. Atau kalau kamu nemu edge case yang belum dibahas di sini, kabarin. Siapa tahu jadi bahan artikel berikutnya.