WordPress 7.2 is due on 8 December. What to check before then
Beta 1 is due on 20 October. Two under-the-bonnet changes can alter existing content. We checked the one touching the database: nothing changes on our servers. Try the other on a copy.
WordPress 7.2 is scheduled for 8 December 2026, with the first beta on 20 October and release candidates from 17 November. It is planned to bring a new default theme, Ipsum, the first since 2010 without a year in its name, and a long list of editor changes. None of that needs anything from you in advance. Two changes deeper down might, because they alter how WordPress handles content that is already on your site. We checked one of them on our servers; the other is best tried on a copy.
The database mode WordPress will switch off#
MySQL and MariaDB have an optional mode, NO_BACKSLASH_ESCAPES, that changes how a backslash in text is handled, and WordPress doesn't work reliably with it. From 7.2, WordPress switches the mode off for its own database connection, as it already does with a few other modes; the server's settings stay as they are. On a server that has the mode on, that cures hard-to-find bugs; a site that depends on it can keep it, and the developer note says how.
We checked our servers on 11 October: the database servers behind hosting accounts here don't use this mode. For a site hosted with us, this change does nothing at all.
The HTML filter that cleans what you save#
When an Author or Contributor saves a post (on a multisite, anyone), when a comment is posted, and in many places where themes and plugins display text, WordPress passes the HTML through a filter (wp_kses) that removes what isn't allowed. In 7.2, if testing goes to plan, that filter moves to WordPress's newer HTML parser. WordPress says plugins and themes shouldn't need changes, but the output differs in the edge cases, and the developer note lists them: a stray < in a sentence used to swallow everything up to the next >, and now it all stays, as text; a & followed by letters in ordinary text or in a pasted code sample can be read as a character code (its example: §ion= turning into §ion=), while inside a link's address it is left alone; a disallowed <script> is removed together with everything inside it.
A filter, wp_kses_force_legacy_parser, restores the old behaviour for now, though WordPress says the old code could be gone as soon as 7.2.0. Where to look after updating: pages with pasted HTML or embedded code, text that shows a web address or a code sample with a & in it, posts and product descriptions written by several people, and comments.
Try it on a copy, not on your site#
The place to try a beta is a copy of your site on a subdomain of its own, with its own database, that search engines don't see. Ask us and we'll set one up for you; it's included. Tell us the site, and you'll get the address of the copy; your usual WordPress login works there.
On the copy, install the WordPress Beta Tester plugin, open Tools → Beta Testing, choose Bleeding edge with the Beta/RC Only stream, and run the update from Dashboard → Updates. From 20 October that gives you Beta 1; from 17 November, the release candidates, which are close to the final version. Click through the pages that matter to you. When you're done, tell us and we'll remove the copy, since it counts towards your plan's storage like everything else.
Never put a beta on the live site. The plugin's own settings page warns that these releases "should not be used anyplace where your data is important".
When 7.2 arrives#
Whether 7.2 installs itself is a setting, and on a site installed in the last few years it may well be on. Dashboard → Updates says whether the site is kept up to date with each new version of WordPress or only with maintenance and security releases; the same choice sits in WP Toolkit under Update WordPress automatically, where Yes, but only minor (security) updates means 7.2 waits for you. Set it the way you want before December. When you do update, do your theme and plugins first, then WordPress; if the copy ran clean, there's no reason to wait long.
Two smaller things while you're there. WordPress 7.1.3, with seven security fixes and four bug fixes, came out on 6 October, and it (or its equivalent for an older branch) should already be on your site, because security releases install themselves unless someone switched that off. And WordPress recommends PHP 8.3 or newer: 8.3 and 8.4 are a few clicks away in cPanel's MultiPHP Manager, and we've explained why to leave 8.2 before the end of the year.