Tim WordPress Core menargetkan refactor wp_kses() berbasis HTML API untuk WordPress 7.2 tanpa mengubah cara plugin memanggil fungsi itu. Output sanitasi HTML pada input tertentu tetap bisa berbeda meski signature API sama. Laporan kemajuan Dennis Snell di Make WordPress Core bertanggal 7 Oktober 2026 (Progress report wp_kses).
Juga, post itu mengacu ticket #66208 dan PR #13271. Core masih menguji perilaku baru sebelum rilis 7.2.0 final. Untuk agensi maintenance dan developer plugin, sinyal ini ajakan regression test di staging. Namun jangan anggap semua plugin rusak sebelum Anda melihat data staging sendiri. Jadi clone production ke staging menjadi langkah pertama yang masuk akal.
Core menargetkan wp_kses WordPress 7.2
wp_kses() menyaring HTML tidak tepercaya lewat subsistem KSES WordPress.
Tag dan atribut di luar allowlist Core buang atau netralkan. Fungsi ini bukan pengganti esc_html(), autentikasi, CSRF, atau escaping output. Sanitasi input dan escape tampilan tetap dua langkah terpisah. Namun escape output tetap wajib setelah sanitasi input.
Implementasi lama memakai rangkaian fungsi, regex PCRE, dan asumsi string. Refactor beralih ke WordPress HTML API supaya parser membaca struktur dokumen.
Karena parser lama mengandalkan regex, tim Core perlu memperbarui asumsi markup modern. Core menulis parser baru lebih robust dan lebih mudah dirawat. Post Snell juga menyebut klaim performa lebih cepat dan hemat memori pada workload KSES.
Kami tidak menambahkan angka benchmark independen di artikel ini.
Replacement Core rencanakan in-place menuju 7.2. Fitur belum otomatis aktif di semua instalasi production hari ini. Jadwal beta dan RC mayor konteks terpisah. Lihat checklist uji WordPress 7.2 bila Anda merencanakan upgrade bertahap.
API sama, output sanitasi bisa beda
Plugin dan tema seharusnya tidak perlu mengubah pemanggilan wp_kses() atau filter allowlist. String hasil sanitasi untuk input yang sama tetap bisa berubah signifikan. Meskipun API stabil, dokumentasikan hasil string sanitizer Anda. Prinsip penting: tidak ada break API tidak berarti tidak ada perubahan perilaku.
Selanjutnya parser baru mem-parse struktur lalu serialize ulang HTML. Kemudian Core menulis ulang serialisasi sesuai struktur yang terbaca. Tag bisa lowercase. Atribut memakai tanda kutip ganda. Referensi karakter parser normalisasi. Flag self-closing void element Core abaikan. Atribut duplikat parser tangani secara deterministik.
Contoh: <IMG class="foo" /> legacy versus <img class="foo"> setelah normalisasi.
Browser sering merender sama. Unit test snapshot string bisa gagal. Core merekomendasikan uji maksud semantik atau DOM bila itu tujuan bisnis. Tetapi jangan ubah test snapshot bila tim sengaja mengunci format string. Sebaliknya, tim yang peduli render browser bisa fokus ke DOM.
Copy-paste dan teks malformed
Post Snell mencontohkan teks seperti <$500 atau >5yo.
Parser lama kadang mengira fragmen sebagai markup lalu menghapus teks.
Parser struktural cenderung mempertahankan teks dengan escape benar.
Kasus itu relevan untuk teks harga atau usia yang memakai simbol kurung sudut.
Alur Block Editor dan paste dari Docs berpotensi hasil lebih prediktif.
Demikian pula import HTML kotor dari CMS lama.
Itu bukan jaminan semua HTML tempelan Core perbaiki sempurna.
Publisher yang menyiapkan konten agen AI tetap butuh markup bersih.
Panduan markdown feed WordPress relevan untuk readiness konten.
Topik itu terpisah dari detail KSES.
Elemen atom SCRIPT atau STYLE yang tidak masuk allowlist berperilaku berbeda.
Legacy bisa membuang tag tetapi meninggalkan isi sebagai teks terlihat.
Implementasi baru dapat membuang tag beserta kontennya.
Tag executable sudah Core hapus sejak awal.
Perbedaannya ada pada sisa kode yang masih terlihat di editor.
SVG, MathML, dan sanitasi konservatif
HTML API menangani aturan parsing khusus lebih baik daripada token logic regex lama.
Contoh konteks: elemen title, script/style, foreign content.
Untuk SVG dan MathML, parser baru memproses sejauh tingkat keyakinan parser.
Bila kompleksitas melebihi jalur saat ini, sanitizer bisa berhenti secara konservatif.
Refactor KSES bukan berarti «WordPress 7.2 full support upload SVG».
Parsing sanitizer, kebijakan media, dan allowlist upload adalah lapisan berbeda.
Core merancang wp_kses() untuk input tidak tepercaya.
Pada ambiguitas, Core cenderung menolak input aman tertentu.
Prioritasnya mencegah markup berisiko lolos.
Walau demikian, sanitizer konservatif bisa menolak markup yang dulu lolos.
Agar aman, uji ulang artikel lama ber-HTML kompleks di staging.
Kajian CodeF: tes plugin dan tema
Kajian CodeF menekankan situs yang memproses HTML pengguna sebagai kandidat regression prioritas.
Contoh alur: form custom, editor pihak ketiga, impor WXR, field meta, template email.
Daftar itu bukan prediksi plugin pasti rusak.
Ternyata page builder kerap memanggil KSES saat save post.
Berikut langkah praktis yang tim CodeF sering pakai di proyek maintenance.
Sedangkan tim content, utamakan skenario paste Docs dan simbol kurung sudut.
Di staging, paste konten Word dengan simbol < dan > aneh.
Setelah itu bandingkan hasil tersimpan di database dan tampilan front.
Uji blok kode, link panjang, dan markup block editor.
Kemudian bandingkan revisi dan respons REST bila workflow Anda bergantung API.
Bila REST jadi sumber truth, uji payload HTML setelah filter.
Tema dengan opsi custom lewat wrapper KSES perlu uji allowlist tag dan atribut duplikat.
Tambahkan entity, nesting, dan URL malformed ke sample test.
Apabila allowlist custom panjang, uji entity dan nesting dulu.
Kalau snapshot gagal, bandingkan render browser sebelum mengubah test.
Tim yang mempertimbangkan stack di luar monolit murni bisa baca WordPress vs Laravel.
Refactor ini spesifik ekosistem Core.
Bukan alasan otomatis pindah framework.
Filter legacy dan langkah sebelum 7.2
Selama fase pengujian, Core menyediakan opt-out sementara ke parser lama:
add_filter( 'wp_kses_force_legacy_parser', '__return_true' );Pertama, uji perilaku baru dulu.
Apabila ada selisih, konfirmasi dengan mode legacy.
Maka Anda tahu apakah bug berasal dari parser baru atau dari data lama.
Dokumentasikan perbedaan dan laporkan ke Trac.
Pakai filter hanya mitigasi sementara.
Jangan jadikan bypass legacy permanen untuk seluruh production.
Implementasi legacy masih ada untuk kompatibilitas.
Post Snell membuka kemungkinan Core hapus parser lama bila tes 7.2.0 memuaskan.
Jangan anggap filter ini jaminan jangka panjang.
Core meminta feedback extenders sebelum rilis final.
Regression otomatis, log plugin, dan sample konten klien nyata lebih berguna daripada update buta.
Akhirnya, rencanakan upgrade mayor WordPress 7.2 setelah daftar regression hijau.
Sebelum itu, ikuti siklus beta Core bila hosting Anda menyediakan environment uji.
Sementara siklus beta berjalan, tunda update production bisnis.
Meski klaim memori menarik, bukti ada di hook save admin.
Refactor ini bukan advisory keamanan CVE.
Jangan membingkai sebagai «patch XSS WordPress 7.2» tanpa laporan kerentanan resmi.
Performa front-end visitor tidak otomatis naik.
Manfaat kecepatan memori terasa bila admin memanggil KSES berulang pada HTML besar.
Setelah staging lulus, catat plugin yang masih bergantung bentuk string legacy.
Jadi simpan fixture HTML klien sebagai baseline regression.
Walau API tidak berubah, diff string sanitizer tetap wajar.
Tim tahu kapan opt-out bisa cabut.
Bila tim maintenance butuh bantuan regression tema atau plugin, tim internal kerap meminta CodeF mengecek staging WordPress.
Itu terpisah dari hype versi angka.
