WordPress 7.2はNO_BACKSLASH_ESCAPESを既定でオフに、SQLモードの変更点

ニュースの概要
何が変わるのか
1. モードを残したい場合
読者への影響
確認すること
筆者の見解
出典（一次情報）

ニュースの概要

WordPress 7.2 では、データベース接続時に NO_BACKSLASH_ESCAPES という SQL モードが既定でオフになります。コアチームが 2026年10月9日に Make WordPress Core で公開した開発者ノート「NO_BACKSLASH_ESCAPES SQL mode is now turned off by default in WordPress 7.2」で明らかになりました。WordPress はすでに複数の SQL モードを接続時に無効化していますが、その一覧に今回このモードが加わります。

7.2 は 12月8日の一般公開が予定されており、10月20日に Beta 1 が出る見込みです（予定のため、変更の可能性があります）。日程の詳細はWordPress 7.2 のリリース予定の記事にまとめています。

何が変わるのか

開発者ノートによると、変更点は次のとおりです。

wpdb::set_sql_mode() が、データベース接続のセッションから NO_BACKSLASH_ESCAPES を取り除く
影響を受けるのは WordPress が張るデータベース接続だけで、サーバー全体の MySQL 設定は変わらない
WordPress は以前から STRICT_ALL_TABLES、TRADITIONAL、ANSI などを接続時に無効化しており、今回はその対象が増える形になる
ノートは、ほとんどのサイトでは違いに気づかないとしている
詳しい経緯は Trac のチケット #66185 に記録されている

理由として挙げられているのは、WordPress が SQL の特殊文字をバックスラッシュ（\）でエスケープしている点です。このモードが有効だと MySQL はバックスラッシュを普通の文字として扱います。その結果、エスケープ済みの値を含むクエリが失敗したり、意図と違うデータを返したりします。一部のホスティング環境ではこのモードが有効になっていることがあり、原因の分かりにくいデータベース不具合につながることがあった、と説明されています。

モードを残したい場合

どうしてもこのモードが必要なサイトのために、既存の incompatible_sql_modes フィルターが使えます。ノートに載っている例は次のコードです。

add_filter( 'incompatible_sql_modes', function ( $modes ) {
	return array_diff( $modes, array( 'NO_BACKSLASH_ESCAPES' ) );
} );

WordPress はプラグインを読み込む前にデータベースへ接続します。そのため、このコードは通常のプラグインや must-use プラグインではなく、db.php ドロップインに書く必要があると明記されています。あわせて、このモードを有効にしたままだとコアが正しく動かない可能性がある、という注意も添えられています。

読者への影響

開発者ノートから考えられる範囲ですが、対象は、WordPress のテーマやプラグインを自作している開発者と、自分でサーバーを管理している人です。大半のサイトでは何も起きません。影響が出うるのは次のような場合です。

レンタルサーバーや自前の MySQL で、サーバー側の既定の SQL モードに NO_BACKSLASH_ESCAPES を入れている
直接 SQL を書くコードが、このモードが有効な前提でエスケープしている（バックスラッシュを使わない書き方に依存している）
WordPress の接続とは別に、同じデータベースを使う外部ツールやバッチ処理がある

注意したいのは、変更が効くのは WordPress の接続セッションだけという点です。外部ツールは、この WordPress 側の変更の影響を受けません。同じテーブルを WordPress とほかのプログラムが触る構成では、エスケープの考え方が接続ごとに食い違わないかを見ておく価値があります。

なお、7.2 はまだ開発中です。この変更も最終リリースまでに内容が調整される可能性はゼロではありません。確定情報は、Beta や RC のリリース告知で確かめてください。

確認すること

自分のサーバーの SQL モードを確認する。SELECT @@GLOBAL.sql_mode, @@SESSION.sql_mode; で、NO_BACKSLASH_ESCAPES が含まれていないかを見る（共有サーバーでは、管理画面や phpMyAdmin から実行できる場合がある）。
自作コードの SQL を点検する。値を直接つなげず、$wpdb->prepare() でプレースホルダーを使っているかを確認する。書き方は$wpdb->prepare で LIKE と IN 句を安全に書く方法で整理しています。
外部ツールやバッチ処理が同じデータベースを使っていないかを洗い出す。
モードを残す必要があるときだけ、db.php ドロップインに上記のフィルターを書く。事前にバックアップを取り、ステージング環境で試してから本番に入れる。
7.2 Beta 1（10月20日予定）が出たら、テスト環境で自分のサイトとプラグインを動かして挙動を見る。

筆者の見解

私見では、大半のサイトには影響しない堅実な変更だと考えます。WordPress のコアは SQL を組み立てるときにバックスラッシュのエスケープを前提にしているので、前提を崩すモードをこちら側で外すのは筋が通っています。

一方で、見落としやすいのは WordPress の外側だと考えます。サーバー設定を変えずに接続ごとに挙動を切り替える方式なので、同じデータベースを複数のプログラムで使う場合は、プログラムごとにエスケープの前提が違いうるからです。この点は開発者ノートの範囲外で、確認できていない部分ですので、構成に心当たりのある方は自分の環境で確かめるのが確実です。

また、前向きな見方もできます。このモードを強制するサーバーで、過去に原因不明の保存失敗や文字の不具合に悩んだサイトは、7.2 で改善するか試す価値があると考えます（ノートに明記はなく、私の推測です）。オプトアウトの置き場所が db.php ドロップインに限られることも、運用面では意識しておきたい点だと考えます。普通のプラグインに書いても効かないため、書いたつもりで効いていない状態になりやすいからです。