NO_BACKSLASH_ESCAPES Is Turned Off by Default in 7.2

A developer note published on 9 October 2026 says that WordPress 7.2 will switch off the MySQL NO_BACKSLASH_ESCAPES SQL mode for its own database connection. The change is small and the note says most sites will not notice it. It is still worth understanding, because the failures it prevents are the kind that take a long time to trace, and the one workaround it offers has a placement rule that is easy to get wrong.

What the mode does

When NO_BACKSLASH_ESCAPES is on, MySQL treats the backslash as an ordinary character rather than an escape character. WordPress escapes special characters in SQL queries with backslashes, so with the mode active an escaped value can break: a query fails, or it quietly returns or stores the wrong data. According to the developer note, some hosts and server setups enable the mode, and before this change the resulting problems were hard to diagnose.

Because the mode is a session setting, two applications on one database server can behave differently. A reporting script that connects with the mode on and WordPress connecting with it off will read the same table under different rules for backslashes. The change makes WordPress consistent with itself, not with every other client on the same server.

What 7.2 changes

WordPress already keeps a list of SQL modes it considers incompatible and removes from the session when it connects. The note says 7.2 adds NO_BACKSLASH_ESCAPES to that list, alongside STRICT_ALL_TABLES, TRADITIONAL and ANSI. The removal happens in wpdb::set_sql_mode(), which strips the mode from the session’s modes at connection time. It applies only to WordPress’s own connection and does not alter the server’s global settings. The background is in ticket #66185.

The note does not describe specific breakage from removing the mode. It says WordPress Core may not work correctly if the mode stays on, and that is the reason for the change. A site where something else on the same server depends on the mode keeps that behaviour for those other applications, since only WordPress’s session is altered.

Checking what your host has set

The modes in force are readable from the database. Running SELECT @@GLOBAL.sql_mode, @@SESSION.sql_mode; through a database client, or through wp db query where WP-CLI is available, shows the server default and the current session. If NO_BACKSLASH_ESCAPES appears in the global value, the host has enabled it, and that is the situation the change is written for. If it appears in neither value, 7.2 changes nothing for the site.

A site that has been intermittently failing on content containing quotation marks or backslashes, with no error that points anywhere, is a reasonable candidate to check now instead of waiting for 8 December. Such symptoms are the type of failure the note describes, though it does not claim any particular symptom.

Keeping the mode, and where the code must live

A site that genuinely requires the mode can keep it by removing it from WordPress’s unsupported list with the incompatible_sql_modes filter. The note’s example returns array_diff( $modes, array( 'NO_BACKSLASH_ESCAPES' ) ) from the filter callback. The placement is the part that matters: the code has to go in a db.php drop-in in wp-content, because WordPress connects to the database before plugins load, so a regular plugin or a must-use plugin runs too late to affect the connection.

Anyone who has set up a persistent object cache will recognise the pattern, because that also relies on a drop-in file that WordPress loads very early, as covered in the post on Redis object caching for WordPress. A drop-in is outside the normal update path, so whoever adds one for this purpose should record it, since it appears under the Drop-ins view of the Plugins screen and not among the ordinary plugins.

Where this fits in the release

The change sits in the same release as several other behaviour changes that deserve staging time, set out in the 7.2 beta test plan and scheduled on the official 7.2 page for release on 8 December 2026. Database-side issues are also a recurring theme in WordPress database maintenance, but this one is a configuration mismatch rather than accumulated data, and the check above takes a minute.