Tim WordPress Core mengumumkan perubahan WordPress 7.2 SQL mode pada 9 Oktober 2026: mode MySQL/MariaDB NO_BACKSLASH_ESCAPES masuk daftar mode yang tidak kompatibel dengan ekosistem WordPress. Saat WordPress membuka koneksi database, wpdb::set_sql_mode() menghapus mode itu dari session koneksi aplikasi—not dari konfigurasi global server.
Rujukan primer ada di dev note Make WordPress Core, ticket #66185, dan changeset 64240 (target milestone WordPress 7.2). Perubahan menyelesaikan query yang gagal atau menyimpan nilai salah ketika hosting mengaktifkan mode tersebut secara global.
Untuk mayoritas situs standar, tidak ada tindakan manual. Developer custom DB, drop-in, atau plugin dengan SQL mentah perlu memverifikasi session mode di staging—bukan karena «CVE baru», melainkan koreksi kompatibilitas escaping backslash yang sudah lama diasumsikan WordPress.
Apa Arti NO_BACKSLASH_ESCAPES
Bila NO_BACKSLASH_ESCAPES aktif, MySQL memperlakukan backslash di string literal sebagai karakter biasa, bukan karakter escape. WordPress core, plugin, dan tema bertahun-tahun mengandalkan escaping backslash pada banyak query. Ticket #66185 memberi contoh konseptual: literal 'It\'s' bisa terurai berbeda sehingga insert, update, atau perbandingan string menghasilkan error sintaks atau data salah.
WordPress 7.2 menambahkan mode ini ke $wpdb->incompatible_modes berdampingan dengan mode lain yang core normalkan di session (misalnya ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES). Jangan menyamakan headline ini dengan «WordPress mematikan strict mode» secara generik—fokus perubahan hanya NO_BACKSLASH_ESCAPES.
Global @@GLOBAL.sql_mode di server tidak WordPress ubah. Perubahan hanya menyentuh @@SESSION.sql_mode pada koneksi aplikasi. Provider hosting boleh tetap memakai mode tersebut untuk workload non-WordPress; session WordPress menormalkannya sendiri.
Siapa yang Perlu Merespons
Situs tanpa query database custom kemungkinan hanya merasakan perbaikan stabilitas setelah update 7.2. Gejala sebelum patch—error SQL sporadis, teks escaped aneh, gagal simpan meta—bisa reda bila penyebabnya mode session yang incompatible.
Stack dengan drop-in database, Hyperdb-style routing, atau plugin yang mengatur sql_mode manual perlu Anda tinjau: apakah wpdb::set_sql_mode() core tetap jalan, atau koneksi bypass sehingga mode lama masih aktif. Override filter incompatible_sql_modes masih ada untuk kasus langka yang benar-benar membutuhkan mode lama, tetapi dev note menekankan filter harus hook sangat awal—sering via db.php drop-in, bukan plugin biasa yang load belakangan.
Perubahan ini bukan advisory keamanan. Jangan memframing «WordPress 7.2 menutup SQL injection». Tetap gunakan $wpdb->prepare() dan API database WordPress. Berita terkait rilis 7.2 di codef.id membahas lapisan lain—misalnya wp_kses dan HTML API pada WordPress 7.2. Pembahasan session database tetap terpisah dari HTML API itu.
Checklist Staging WordPress 7.2 sebelum Produksi
Di staging 7.2, jalankan SELECT @@SESSION.sql_mode; (read-only) setelah bootstrap aplikasi dan pastikan NO_BACKSLASH_ESCAPES tidak muncul pada session yang dipakai CMS. Uji form, simpan post, impor, checkout WooCommerce bila ada, serta CRUD plugin custom.
Backup database sebelum major upgrade tetap wajib. Artikel backup database WordPress dan MySQL menjelaskan prosedur impor/ekspor MySQL di lingkungan WordPress. Log PHP/MySQL membantu menangkap query legacy yang masih mengasumsikan semantics backslash alternatif.
Hosting tidak perlu mengedit global SQL mode hanya demi rilis ini. Normalisasi session sudah cukup untuk core. Override mode incompatible hanya untuk requirement teknis yang terdokumentasi, dengan testing penuh—bukan default untuk pemilik situs umum.
Langkah Lanjut Menjelang Rilis 7.2
Status milestone 7.2 dan tanggal rilis final bisa bergeser; verifikasi Trac sebelum go-live produksi. Setelah rilis, pantau plugin database langka dan drop-in kustom—bukan seluruh ekosistem plugin «wajib rewrite».
Kajian CodeF: update mayor WordPress kerap membawa perubahan compat di lapisan rendah (database, HTML parsing, API) selain fitur editor. Namun jangan panik mengubah global SQL config di server. Jadi rencanakan maintenance window, staging, dan uji alur kritis sebagai langkah pertama.
