Pluginmu Siap WP 6.7? Ini Audit 15 Menit yang Bikin Nggak Fatal Error Pas Update

• block_editor_settings_all – sekarang menerima parameter ke-2 $block_editor_context. Callback tanpa parameter ini bakal dapat PHP notice
• wp_enqueue_scripts dengan wp_add_inline_script – inline script yang ditambahkan ke handle dengan strategy defer atau async sekarang dieksekusi dalam urutan ketat sesuai antrian. Jangan asumsi inline script selalu di atas
• the_content filter – urutan prioritas berubah saat block hooks aktif. Filter dengan priority 10 mungkin dipanggil lebih awal dari expected
• register_block_type_args – sekarang dipanggil lebih awal di bootstrap sequence. Jangan refer ke get_current_screen() karena belum tersedia

Cek juga WordPress Developer Reference untuk daftar lengkap deprecated hooks per versi.

Script Loading Strategy: Defer Itu Keren, Tapi Bisa Bikin Order Dependency Ambyar

WP 6.7 memperkenalkan Script Loading Strategy API yang udah kamu baca di artikel sebelumnya soal A/B test script loading. Tapi dari sisi plugin developer, ada jebakan batman-nya: defer + dependency order.

Kalau plugin kamu punya tiga script: A (jQuery dependent), B (React dependent), dan C (custom). Lalu kamu set semuanya defer, urutan eksekusi dijamin sesuai deklarasi dependency. Tapi kalau ada satu script yang lupa dideklarasikan dependency-nya, eksekusi jadi chaos. C bisa jalan sebelum jQuery loaded.

// Aman
wp_register_script( 'myplugin-a', $url_a, ['jquery'], '2.0', ['strategy' => 'defer'] );
wp_register_script( 'myplugin-b', $url_b, ['myplugin-a'], '2.0', ['strategy' => 'defer'] );

// Berbahaya — nggak declare dependency jquery
wp_register_script( 'myplugin-unsafe', $url, [], '2.0', ['strategy' => 'defer'] );

Audit semua wp_register_script dan wp_enqueue_script di plugin kamu. Pastikan parameter dependencies (array ke-3) terisi dengan benar. Jangan tinggalin array kosong cuma karena “script-nya jalan kok sebelumnya.”

Testing Staging: Jangan Cuma Andalkan WP_DEBUG

Kebanyakan developer cuma nge-flip WP_DEBUG jadi true, lihat nggak ada notice, lalu anggap aman. Padahal banyak error di 6.7 bersifat runtime conditional: cuma muncul saat kombinasi spesifik block, template, dan user role tertentu.

Minimal, lakukan ini di staging:

• Buka 20 halaman acak sebagai subscriber, bukan admin
• Test dengan block theme (Twenty Twenty-Five) dan classic theme (Twenty Twenty-One)
• Aktifkan SCRIPT_DEBUG – banyak module Interactivity API error cuma muncul saat ini true
• Gunakan Query Monitor plugin untuk ngecek hooks yang fired. Lihat apakah ada hook deprecated yang masih triggered

Referensi resmi: WordPress 6.7 Field Guide dari Make Core dan Gutenberg 20.0 Release Notes untuk detail teknis Interaction API.

Kesimpulan: 15 Menit Sekarang, Hemat Ratusan Jam Nanti

WP 6.7 bukan rilis yang bisa kamu skip. Block hooks menggantikan render_block, lazy loading native bentrok dengan library kustom, dan Interaction API minta deklarasi eksplisit. Tiga perubahan ini saling terkait dan bisa bikin plugin kamu fatal error secara silent.

Jalankan checklist audit di atas. Grep codebase. Migrasi render_block ke hooked_block_types. Fix double lazy load. Deklarasikan "interactivity": true di semua block.json. Update dependency array di tiap wp_register_script. Test di staging sebagai subscriber, bukan admin.

Kalau kamu maintain plugin dengan ribuan installs, 15 menit audit sekarang bakal menghemat ratusan jam support ticket nanti. Jangan tunggu user komplain dulu baru bertindak.

FAQ: Plugin Audit WP 6.7

Apa risiko terbesar kalau plugin nggak diaudit sebelum WP 6.7?

Risiko terbesar adalah fatal error diam-diam. Banyak perubahan di 6.7 bersifat depresiasi tanpa warning di WP_DEBUG. Akibatnya: whitescreen di halaman tertentu, gambar lenyap tanpa jejak, atau block interaktif yang tiba-tiba statis. Plugin kamu bisa tetap “aktif” tapi fungsionalitasnya rusak sebagian, dan user nggak bisa jelasin apa yang salah.

Apakah semua plugin harus migrasi ke Block Hooks API?

Nggak wajib sekarang, tapi sangat direkomendasikan. Filter render_block masih berfungsi di 6.7, tapi potensi konflik dengan sistem block hooks native meningkat. Plugin yang melakukan manipulasi markup via render_block bisa kena double injection. Migrasi ke Block Hooks API bukan cuma soal kompatibilitas, tapi juga ngasih user kontrol lebih baik di editor.

Gimana cara paling gampang cek apakah plugin sudah Interaction API ready?

Cara termudah: buka setiap file block.json di plugin kamu, lalu pastikan tiga hal: (1) "apiVersion": 3, (2) "supports": {"interactivity": true}, dan (3) menggunakan "viewScriptModule" bukan "viewScript". Kalau ketiganya ada, plugin kamu sudah Interaction API ready. Kalau ada yang kurang, runtime Interactivity API di 6.7 bakal mengabaikan blok tersebut sepenuhnya.

Apakah lazy loading native WP 6.7 masih bisa dimatikan?

Bisa, pakai filter wp_img_tag_add_loading_attr untuk gambar dan wp_iframe_tag_add_loading_attr untuk iframe. Return false di filter tersebut akan menghapus atribut loading="lazy" dari elemen terkait. Tapi pertimbangkan baik-baik: matiin native lazy loading berarti kamu harus handle sendiri performa loading di semua browser.

Kapan batas akhir migrasi sebelum WP 6.7 rilis?

WP 6.7 sudah dirilis. Kalau plugin kamu belum diaudit, lakukan sekarang. Setiap hari delay adalah potensi user yang kena error dan ninggalin review negatif. Prioritaskan audit block hooks dan Interaction API dulu karena dampaknya paling besar, baru lanjut ke lazy loading dan enqueue fixes.

---

Baca juga: Theme.json v3 di WP 6.7 Bikin Theme Lamamu Error? Ini yang Harus Kamu Audit dan Block Gutenberg Jadulmu Masih Pakai Float? Migrasi ke Grid Sekarang Juga.

• Jangan lupa: "apiVersion": 3 wajib ada. Tanpa itu, Interactivity API nggak akan dikenali
• Kalau kamu masih pakai viewScript (bukan viewScriptModule), itu legacy pattern yang nggak kompatibel dengan Interaction API runtime baru

Hot tip: gunakan wp-scripts build --experimental-modules untuk memvalidasi module output. Flag ini bakal ngecek apakah semua import/export di view.js kamu kompatibel dengan ES module spec yang dipakai Interactivity API 6.7.

Checklist 15 Menit: Dari Grep ke Fix

Simpan checklist ini. Jalankan berurutan. Jangan skip.

#	Langkah	Command / File	Status
1	Deprecated hooks audit	grep -rn "render_block" --include="*.php"	☐
2	Block hooks migration	Ganti ke hooked_block_types	☐
3	Lazy loading konflik	grep -rn "lazy" --include="*.js"	☐
4	wp_get_attachment_image	Cek output loading attr	☐
5	Interaction API deklarasi	Cek semua block.json ada "interactivity": true	☐
6	apiVersion check	Pastikan semua block.json pakai "apiVersion": 3	☐
7	viewScriptModule	Ganti viewScript lama ke viewScriptModule	☐
8	WP_DEBUG test	Aktifkan define('WP_DEBUG', true) di staging	☐
9	Load test 20 halaman	Buka 20 halaman acak, cek console error	☐

Deprecated Hooks di WP 6.7 yang Kamu Mungkin Masih Pakai

Selain tiga sistem besar di atas, ada beberapa hooks spesifik yang resmi deprecated atau berubah perilaku di 6.7:

• block_editor_settings_all – sekarang menerima parameter ke-2 $block_editor_context. Callback tanpa parameter ini bakal dapat PHP notice
• wp_enqueue_scripts dengan wp_add_inline_script – inline script yang ditambahkan ke handle dengan strategy defer atau async sekarang dieksekusi dalam urutan ketat sesuai antrian. Jangan asumsi inline script selalu di atas
• the_content filter – urutan prioritas berubah saat block hooks aktif. Filter dengan priority 10 mungkin dipanggil lebih awal dari expected
• register_block_type_args – sekarang dipanggil lebih awal di bootstrap sequence. Jangan refer ke get_current_screen() karena belum tersedia

Cek juga WordPress Developer Reference untuk daftar lengkap deprecated hooks per versi.

Script Loading Strategy: Defer Itu Keren, Tapi Bisa Bikin Order Dependency Ambyar

WP 6.7 memperkenalkan Script Loading Strategy API yang udah kamu baca di artikel sebelumnya soal A/B test script loading. Tapi dari sisi plugin developer, ada jebakan batman-nya: defer + dependency order.

Kalau plugin kamu punya tiga script: A (jQuery dependent), B (React dependent), dan C (custom). Lalu kamu set semuanya defer, urutan eksekusi dijamin sesuai deklarasi dependency. Tapi kalau ada satu script yang lupa dideklarasikan dependency-nya, eksekusi jadi chaos. C bisa jalan sebelum jQuery loaded.

// Aman
wp_register_script( 'myplugin-a', $url_a, ['jquery'], '2.0', ['strategy' => 'defer'] );
wp_register_script( 'myplugin-b', $url_b, ['myplugin-a'], '2.0', ['strategy' => 'defer'] );

// Berbahaya — nggak declare dependency jquery
wp_register_script( 'myplugin-unsafe', $url, [], '2.0', ['strategy' => 'defer'] );

Audit semua wp_register_script dan wp_enqueue_script di plugin kamu. Pastikan parameter dependencies (array ke-3) terisi dengan benar. Jangan tinggalin array kosong cuma karena “script-nya jalan kok sebelumnya.”

Testing Staging: Jangan Cuma Andalkan WP_DEBUG

Kebanyakan developer cuma nge-flip WP_DEBUG jadi true, lihat nggak ada notice, lalu anggap aman. Padahal banyak error di 6.7 bersifat runtime conditional: cuma muncul saat kombinasi spesifik block, template, dan user role tertentu.

Minimal, lakukan ini di staging:

• Buka 20 halaman acak sebagai subscriber, bukan admin
• Test dengan block theme (Twenty Twenty-Five) dan classic theme (Twenty Twenty-One)
• Aktifkan SCRIPT_DEBUG – banyak module Interactivity API error cuma muncul saat ini true
• Gunakan Query Monitor plugin untuk ngecek hooks yang fired. Lihat apakah ada hook deprecated yang masih triggered

Referensi resmi: WordPress 6.7 Field Guide dari Make Core dan Gutenberg 20.0 Release Notes untuk detail teknis Interaction API.

Kesimpulan: 15 Menit Sekarang, Hemat Ratusan Jam Nanti

WP 6.7 bukan rilis yang bisa kamu skip. Block hooks menggantikan render_block, lazy loading native bentrok dengan library kustom, dan Interaction API minta deklarasi eksplisit. Tiga perubahan ini saling terkait dan bisa bikin plugin kamu fatal error secara silent.

Jalankan checklist audit di atas. Grep codebase. Migrasi render_block ke hooked_block_types. Fix double lazy load. Deklarasikan "interactivity": true di semua block.json. Update dependency array di tiap wp_register_script. Test di staging sebagai subscriber, bukan admin.

Kalau kamu maintain plugin dengan ribuan installs, 15 menit audit sekarang bakal menghemat ratusan jam support ticket nanti. Jangan tunggu user komplain dulu baru bertindak.

FAQ: Plugin Audit WP 6.7

Apa risiko terbesar kalau plugin nggak diaudit sebelum WP 6.7?

Risiko terbesar adalah fatal error diam-diam. Banyak perubahan di 6.7 bersifat depresiasi tanpa warning di WP_DEBUG. Akibatnya: whitescreen di halaman tertentu, gambar lenyap tanpa jejak, atau block interaktif yang tiba-tiba statis. Plugin kamu bisa tetap “aktif” tapi fungsionalitasnya rusak sebagian, dan user nggak bisa jelasin apa yang salah.

Apakah semua plugin harus migrasi ke Block Hooks API?

Nggak wajib sekarang, tapi sangat direkomendasikan. Filter render_block masih berfungsi di 6.7, tapi potensi konflik dengan sistem block hooks native meningkat. Plugin yang melakukan manipulasi markup via render_block bisa kena double injection. Migrasi ke Block Hooks API bukan cuma soal kompatibilitas, tapi juga ngasih user kontrol lebih baik di editor.

Gimana cara paling gampang cek apakah plugin sudah Interaction API ready?

Cara termudah: buka setiap file block.json di plugin kamu, lalu pastikan tiga hal: (1) "apiVersion": 3, (2) "supports": {"interactivity": true}, dan (3) menggunakan "viewScriptModule" bukan "viewScript". Kalau ketiganya ada, plugin kamu sudah Interaction API ready. Kalau ada yang kurang, runtime Interactivity API di 6.7 bakal mengabaikan blok tersebut sepenuhnya.

Apakah lazy loading native WP 6.7 masih bisa dimatikan?

Bisa, pakai filter wp_img_tag_add_loading_attr untuk gambar dan wp_iframe_tag_add_loading_attr untuk iframe. Return false di filter tersebut akan menghapus atribut loading="lazy" dari elemen terkait. Tapi pertimbangkan baik-baik: matiin native lazy loading berarti kamu harus handle sendiri performa loading di semua browser.

Kapan batas akhir migrasi sebelum WP 6.7 rilis?

WP 6.7 sudah dirilis. Kalau plugin kamu belum diaudit, lakukan sekarang. Setiap hari delay adalah potensi user yang kena error dan ninggalin review negatif. Prioritaskan audit block hooks dan Interaction API dulu karena dampaknya paling besar, baru lanjut ke lazy loading dan enqueue fixes.

---

Baca juga: Theme.json v3 di WP 6.7 Bikin Theme Lamamu Error? Ini yang Harus Kamu Audit dan Block Gutenberg Jadulmu Masih Pakai Float? Migrasi ke Grid Sekarang Juga.

⚡ Jawaban Singkat / Key Takeaways

WordPress 6.7 membawa tiga perubahan arsitektur yang bisa bikin plugin besar ambyar diam-diam: Block Hooks menggantikan mekanisme injeksi template lama, lazy loading native bentrok dengan script wp_enqueue manual, dan Interaction API mewajibkan deklarasi eksplisit di block.json. Audit 15 menit pakai checklist di bawah ini bakal menyelamatkan ribuan instalasi user kamu dari fatal error.

Kenapa WP 6.7 Bisa Jadi Silent Killer Buat Plugin Besar

Bayangin skenario ini: kamu maintain plugin dengan 50rb+ active installs. WP 6.7 rilis, lalu support inbox kamu banjir laporan “site broke after update.” Padahal sebelumnya baik-baik aja selama dua tahun terakhir.

Masalahnya bukan di kode kamu yang jelek. WordPress 6.7 memperkenalkan arsitektur baru yang mendepresiasi puluhan hooks lama secara silent. Nggak ada deprecation warning di WP_DEBUG kebanyakan kasus. Yang ada cuma fatal error tiba-tiba, layout rusak, atau fitur yang menghilang tanpa jejak.

Tim WordPress Core memang mempercepat transisi ke full site editing. Setiap rilis mayor sejak 6.4 membawa perubahan fondasi. Tapi versi 6.7 jadi titik balik karena tiga sistem besar berubah bersamaan: block hooks, lazy loading, dan Interaction API. Plugin yang cuma mengandalkan satu di antaranya aja udah rawan. Apalagi yang pakai kombinasi ketiganya.

Artikel ini adalah checklist audit praktis, bukan dokumentasi teknis yang bikin ngantuk. Kamu bisa selesaikan dalam 15 menit dan langsung tahu bagian mana yang harus difix.

1. Block Hooks: Kenapa inject_block_type Lama Bisa Bikin Whitescreen

WordPress 6.7 memperkenalkan Block Hooks API yang menggantikan pola lama render_block + str_replace untuk menyisipkan konten ke dalam blok. Kalau plugin kamu masih pakai pendekatan seperti ini:

add_filter( 'render_block', function( $block_content, $block ) {
    if ( 'core/post-content' !== $block['blockName'] ) {
        return $block_content;
    }
    return $block_content . $my_custom_html;
}, 10, 2 );

Maka kamu berada di zona bahaya. Pendekatan ini rawan double injection saat block hooks native ikut memproses blok yang sama. Hasilnya: markup duplikat, layout ancur, atau PHP memory exhaustion di halaman berat.

Audit Poin #1: Cari Semua Filter render_block

• Grep seluruh codebase dengan keyword add_filter( 'render_block'
• Ganti dengan add_filter( 'hooked_block_types' untuk injeksi blok baru
• Gunakan add_filter( 'hooked_block_' . $block_type untuk modifikasi atribut blok existing

Contoh migrasi yang benar:

// WP 6.7+ style
add_filter( 'hooked_block_types', function( $hooked_blocks, $relative_position, $anchor_block ) {
    if ( 'core/post-content' === $anchor_block && 'after' === $relative_position ) {
        $hooked_blocks[] = 'myplugin/newsletter-cta';
    }
    return $hooked_blocks;
}, 10, 3 );

Keuntungan tambahan: block hooks bisa diedit user dari editor. Zero PHP buat logic penempatan. Ini bakal jadi standar baru, jadi mending migrasi sekarang daripada nanti buru-buru pas user komplain.

2. Lazy Loading Bentrok: Kenapa Gambar di Pluginu Bisa Hilang Semua

Sejak WP 6.4, WordPress otomatis menambahkan loading="lazy" ke semua gambar. Di 6.7, mekanisme ini diperluas ke iframe dan elemen embed. Masalah muncul kalau plugin kamu punya lazy loading kustom pakai JavaScript seperti LazySizes, vanilla-lazyload, atau Intersection Observer manual.

Double lazy loading bikin gambar nggak muncul sama sekali. Browser menerima dua sinyal: “jangan load gambar ini” dari atribut native dan “jangan load sampai scroll” dari library JS. Hasilnya? Gambar stuck di limbo, nggak pernah dirender.

Audit Poin #2: Deteksi Library Lazy Loading Kustom

• Grep wp_enqueue_script untuk keyword: lazysizes, lozad, vanilla-lazyload, lazy-load, intersection-observer
• Cek apakah script tersebut memanipulasi atribut src, data-src, atau loading
• Kalau iya, tambahkan filter untuk menghapus loading="lazy" native dari gambar yang dihandle kustom

// Fix double lazy load
add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image ) {
    if ( strpos( $image, 'myplugin-lazy' ) !== false ) {
        return false; // skip native lazy
    }
    return $value;
}, 10, 2 );

Satu hal yang sering overlooked: wp_get_attachment_image sekarang otomatis menambahkan loading=”lazy” di 6.7. Kalau plugin kamu generate markup gambar sendiri lewat fungsi ini, cek kembali output HTML-nya. Pastikan nggak ada atribut lazy ganda.

3. Interaction API: Block.json Kamu Harus Deklarasi Langsung atau Nggak Jalan

Ini yang paling sering bikin developer frustrasi. Di WP 6.5 dan 6.6, Interaction API masih toleran: kamu bisa register interaktivitas lewat PHP wp_register_script_module tanpa deklarasi di block.json. Di 6.7, aturan ini diperketat. Block yang nggak mendeklarasikan interactivity di block.json bakal diabaikan oleh runtime Interactivity API.

Audit Poin #3: Verifikasi Deklarasi Interactivity

• Buka semua file block.json di plugin kamu
• Pastikan setiap block yang pakai @wordpress/interactivity punya entri eksplisit:

{
  "apiVersion": 3,
  "name": "myplugin/interactive-block",
  "title": "Interactive Block",
  "supports": {
    "interactivity": true
  },
  "viewScriptModule": "file:./view.js"
}

• Jangan lupa: "apiVersion": 3 wajib ada. Tanpa itu, Interactivity API nggak akan dikenali
• Kalau kamu masih pakai viewScript (bukan viewScriptModule), itu legacy pattern yang nggak kompatibel dengan Interaction API runtime baru

Hot tip: gunakan wp-scripts build --experimental-modules untuk memvalidasi module output. Flag ini bakal ngecek apakah semua import/export di view.js kamu kompatibel dengan ES module spec yang dipakai Interactivity API 6.7.

Checklist 15 Menit: Dari Grep ke Fix

Simpan checklist ini. Jalankan berurutan. Jangan skip.

#	Langkah	Command / File	Status
1	Deprecated hooks audit	grep -rn "render_block" --include="*.php"	☐
2	Block hooks migration	Ganti ke hooked_block_types	☐
3	Lazy loading konflik	grep -rn "lazy" --include="*.js"	☐
4	wp_get_attachment_image	Cek output loading attr	☐
5	Interaction API deklarasi	Cek semua block.json ada "interactivity": true	☐
6	apiVersion check	Pastikan semua block.json pakai "apiVersion": 3	☐
7	viewScriptModule	Ganti viewScript lama ke viewScriptModule	☐
8	WP_DEBUG test	Aktifkan define('WP_DEBUG', true) di staging	☐
9	Load test 20 halaman	Buka 20 halaman acak, cek console error	☐

Deprecated Hooks di WP 6.7 yang Kamu Mungkin Masih Pakai

Selain tiga sistem besar di atas, ada beberapa hooks spesifik yang resmi deprecated atau berubah perilaku di 6.7:

• block_editor_settings_all – sekarang menerima parameter ke-2 $block_editor_context. Callback tanpa parameter ini bakal dapat PHP notice
• wp_enqueue_scripts dengan wp_add_inline_script – inline script yang ditambahkan ke handle dengan strategy defer atau async sekarang dieksekusi dalam urutan ketat sesuai antrian. Jangan asumsi inline script selalu di atas
• the_content filter – urutan prioritas berubah saat block hooks aktif. Filter dengan priority 10 mungkin dipanggil lebih awal dari expected
• register_block_type_args – sekarang dipanggil lebih awal di bootstrap sequence. Jangan refer ke get_current_screen() karena belum tersedia

Cek juga WordPress Developer Reference untuk daftar lengkap deprecated hooks per versi.

Script Loading Strategy: Defer Itu Keren, Tapi Bisa Bikin Order Dependency Ambyar

WP 6.7 memperkenalkan Script Loading Strategy API yang udah kamu baca di artikel sebelumnya soal A/B test script loading. Tapi dari sisi plugin developer, ada jebakan batman-nya: defer + dependency order.

Kalau plugin kamu punya tiga script: A (jQuery dependent), B (React dependent), dan C (custom). Lalu kamu set semuanya defer, urutan eksekusi dijamin sesuai deklarasi dependency. Tapi kalau ada satu script yang lupa dideklarasikan dependency-nya, eksekusi jadi chaos. C bisa jalan sebelum jQuery loaded.

// Aman
wp_register_script( 'myplugin-a', $url_a, ['jquery'], '2.0', ['strategy' => 'defer'] );
wp_register_script( 'myplugin-b', $url_b, ['myplugin-a'], '2.0', ['strategy' => 'defer'] );

// Berbahaya — nggak declare dependency jquery
wp_register_script( 'myplugin-unsafe', $url, [], '2.0', ['strategy' => 'defer'] );

Audit semua wp_register_script dan wp_enqueue_script di plugin kamu. Pastikan parameter dependencies (array ke-3) terisi dengan benar. Jangan tinggalin array kosong cuma karena “script-nya jalan kok sebelumnya.”

Testing Staging: Jangan Cuma Andalkan WP_DEBUG

Kebanyakan developer cuma nge-flip WP_DEBUG jadi true, lihat nggak ada notice, lalu anggap aman. Padahal banyak error di 6.7 bersifat runtime conditional: cuma muncul saat kombinasi spesifik block, template, dan user role tertentu.

Minimal, lakukan ini di staging:

• Buka 20 halaman acak sebagai subscriber, bukan admin
• Test dengan block theme (Twenty Twenty-Five) dan classic theme (Twenty Twenty-One)
• Aktifkan SCRIPT_DEBUG – banyak module Interactivity API error cuma muncul saat ini true
• Gunakan Query Monitor plugin untuk ngecek hooks yang fired. Lihat apakah ada hook deprecated yang masih triggered

Referensi resmi: WordPress 6.7 Field Guide dari Make Core dan Gutenberg 20.0 Release Notes untuk detail teknis Interaction API.

Kesimpulan: 15 Menit Sekarang, Hemat Ratusan Jam Nanti

WP 6.7 bukan rilis yang bisa kamu skip. Block hooks menggantikan render_block, lazy loading native bentrok dengan library kustom, dan Interaction API minta deklarasi eksplisit. Tiga perubahan ini saling terkait dan bisa bikin plugin kamu fatal error secara silent.

Jalankan checklist audit di atas. Grep codebase. Migrasi render_block ke hooked_block_types. Fix double lazy load. Deklarasikan "interactivity": true di semua block.json. Update dependency array di tiap wp_register_script. Test di staging sebagai subscriber, bukan admin.

Kalau kamu maintain plugin dengan ribuan installs, 15 menit audit sekarang bakal menghemat ratusan jam support ticket nanti. Jangan tunggu user komplain dulu baru bertindak.

FAQ: Plugin Audit WP 6.7

Apa risiko terbesar kalau plugin nggak diaudit sebelum WP 6.7?

Risiko terbesar adalah fatal error diam-diam. Banyak perubahan di 6.7 bersifat depresiasi tanpa warning di WP_DEBUG. Akibatnya: whitescreen di halaman tertentu, gambar lenyap tanpa jejak, atau block interaktif yang tiba-tiba statis. Plugin kamu bisa tetap “aktif” tapi fungsionalitasnya rusak sebagian, dan user nggak bisa jelasin apa yang salah.

Apakah semua plugin harus migrasi ke Block Hooks API?

Nggak wajib sekarang, tapi sangat direkomendasikan. Filter render_block masih berfungsi di 6.7, tapi potensi konflik dengan sistem block hooks native meningkat. Plugin yang melakukan manipulasi markup via render_block bisa kena double injection. Migrasi ke Block Hooks API bukan cuma soal kompatibilitas, tapi juga ngasih user kontrol lebih baik di editor.

Gimana cara paling gampang cek apakah plugin sudah Interaction API ready?

Cara termudah: buka setiap file block.json di plugin kamu, lalu pastikan tiga hal: (1) "apiVersion": 3, (2) "supports": {"interactivity": true}, dan (3) menggunakan "viewScriptModule" bukan "viewScript". Kalau ketiganya ada, plugin kamu sudah Interaction API ready. Kalau ada yang kurang, runtime Interactivity API di 6.7 bakal mengabaikan blok tersebut sepenuhnya.

Apakah lazy loading native WP 6.7 masih bisa dimatikan?

Bisa, pakai filter wp_img_tag_add_loading_attr untuk gambar dan wp_iframe_tag_add_loading_attr untuk iframe. Return false di filter tersebut akan menghapus atribut loading="lazy" dari elemen terkait. Tapi pertimbangkan baik-baik: matiin native lazy loading berarti kamu harus handle sendiri performa loading di semua browser.

Kapan batas akhir migrasi sebelum WP 6.7 rilis?

WP 6.7 sudah dirilis. Kalau plugin kamu belum diaudit, lakukan sekarang. Setiap hari delay adalah potensi user yang kena error dan ninggalin review negatif. Prioritaskan audit block hooks dan Interaction API dulu karena dampaknya paling besar, baru lanjut ke lazy loading dan enqueue fixes.

---

Baca juga: Theme.json v3 di WP 6.7 Bikin Theme Lamamu Error? Ini yang Harus Kamu Audit dan Block Gutenberg Jadulmu Masih Pakai Float? Migrasi ke Grid Sekarang Juga.