WordPress 7.2: Release Date, What’s New, and What We Found Testing It Early

Last updated 14 October 2026. Beta 1 is due on 20 October, and we’ll update this post once it’s out and we’ve checked what actually made it in.

WordPress 7.2 is the last big release of 2026, and it’s due on 8 December. Most of what’s been written about it so far just repeats the roadmap. We wanted to know what has really landed, so we installed the nightly build (7.2-alpha-64337), ran our own plugins on it, and pushed a pile of real HTML through the one change most likely to surprise people. It’s a rewrite of wp_kses(), the function that cleans up HTML.

Short version: for most site owners 7.2 is a quiet update. But comments, author-written posts and anything a plugin “sanitizes” are now cleaned by brand new code. That code mostly fixes old bugs, and it changes a few small things you might notice.

WordPress 7.2 release dates

From the official WordPress 7.2 schedule:

You’ll see 9 December in some write-ups. The official schedule page says the 8th, so we’re going with that.

What’s actually in 7.2 so far (and what’s still just planned)

The Roadmap to 7.2 is long, and a roadmap is a wish list. So we grepped the nightly code on 14 October to see what’s really there:

Beta 1 is the feature freeze, so anything in the “planned” rows that isn’t in on 20 October probably waits for 7.3. We’ll update the table then.

About Ipsum: it also ends a 16-year habit. Default themes have been named after years since Twenty Ten, and the core team says that’s over (Ipsum posts on make.wordpress.org). Existing sites don’t change theme on update. It only matters for new installs.

The big one nobody explains: the new wp_kses()

What wp_kses() is, in plain words

Every time someone who isn’t fully trusted sends HTML to your site, WordPress runs it through wp_kses(). It keeps safe tags like <strong> and links, and throws away dangerous stuff like <script>. That covers:

• Every comment on your site.
• Posts by Authors and Contributors. Administrators and Editors on a normal single site skip it, because they have the unfiltered_html permission. On multisite, everyone except Super Admins gets filtered.
• Plugins that call it on purpose. Form plugins, page builders, anything that shows user-supplied HTML. Our own form plugin calls wp_kses_post() in 18 places.

The old version is built on kses, a small regex-based library WordPress has used since version 1.0. It worked, mostly, but it guessed at HTML instead of reading it properly. In 7.2 it’s been rebuilt on WordPress’ newer HTML API, which reads HTML the way a browser does (progress report from Dennis Snell, commit r64233 on 7 October).

What we tested

Full disclosure: we make three WordPress plugins, a form builder, an entry manager and an internal linking tool. So that’s where we started. On a clean 7.2-alpha install we:

• ran all three plugins’ automated test suites (594, 474 and 106 tests) with the new parser on,
• loaded every one of their 22 admin screens and checked the debug log,
• pushed 74 real blog posts (1.3 MB of HTML, the drafts of this blog) through wp_kses_post() with the old parser and with the new one, and compared the output,
• tried a handful of everyday comments and form snippets both ways.

All three test suites passed, and no admin screen threw a PHP warning or deprecation notice. Good start. The interesting part is the HTML comparison.

Result 1: your normal text stops getting eaten

This was the nicest surprise. The old parser saw a lone < as “maybe a tag” and deleted everything up to the next >. In comments, that ate real words:

A form with a budget field like “<$500, $500-$2,000, >$2,000” had the same problem in the old version. The text came out as just “$2,000”. The new parser keeps it all.

Result 2: hidden scripts stop leaking onto the page

When a <script> or <style> tag isn’t allowed, the old parser removed the tag but left the code inside it sitting on your page as visible text. 73 of our 74 posts carry a JSON-LD FAQ block inside a script tag. If an Author-role writer had published them, the old parser would have dumped that raw JSON into every article. The new parser removes the tag and its contents. Much better, but if you relied on Authors pasting tracking scripts or schema into posts, that was never really working anyway, and now it disappears cleanly.

Result 3: the markup gets tidied

Once we set the scripts aside, 43 of the 74 posts came out byte-for-byte identical. The other 31 changed only in markup, never in the text a reader sees. The changes were:

• tag names lowercased (<P> becomes <p>), and <br /> becomes <br>,
• attributes put in alphabetical order (src before alt becomes alt before src),
• named entities turned into the actual characters: — becomes —, → becomes →,   becomes a real non-breaking space.

Browsers render all of that the same. Where it can bite is code that compares HTML as a string, like a plugin test that expects exactly <br />, or a “has this content changed?” check. The core team had to update many of WordPress’ own tests for the same reason.

Result 4: one change you might actually see

An ampersand that isn’t followed by a semicolon gets read the way a browser reads it. So text like &section=pricing or ?a=1&copy=2 typed as plain text (not inside a link) turns into “§ion=pricing” and “?a=1©=2”, because &sect and &copy are old HTML names for § and ©. Links themselves are fine, href values aren’t touched this way. It’s rare, but if you write tutorials that show URL parameters in comments or Author posts, wrap them in <code> or write &.

Is it faster?

The core team describes the new parser as faster and lighter on memory. On our batch of 74 fairly long posts it wasn’t: after a warm-up, the median over 9 runs was 206 ms for the new parser against 130 ms for the old one on PHP 8.4, about 1.6x slower. That’s under 3 ms per post, and this is pre-beta code, so treat it as one data point, not a verdict.

If something breaks

Developers can switch back to the old parser for now:

add_filter( 'wp_kses_force_legacy_parser', '__return_true', 20 );

Note the priority. Core adds its own __return_false at the default priority 10, so your filter needs to run after it. The progress report says this escape hatch is temporary and could disappear “even in WordPress 7.2.0”. If you hit a real problem, report it on Trac ticket #66208. That’s exactly the feedback they’re asking for before December.

The Secrets API, explained simply

Right now, when you paste a Stripe key or an OpenAI key into a plugin’s settings, it usually goes straight into the wp_options database table as plain text. Anyone with a database backup can read it.

7.2 adds functions like wp_set_secret() and wp_get_secret() that store those values encrypted, with versioning so a key can be rotated (the proposal). It landed in trunk on 13 October. No admin screen is planned for 7.2, and according to the proposal nothing moves over automatically: each plugin has to switch its own keys. So you won’t see a difference on day one. It’s plumbing, but it’s the kind that matters later.

NO_BACKSLASH_ESCAPES, in one paragraph

Some hosts switch on a MySQL setting called NO_BACKSLASH_ESCAPES. WordPress escapes data with backslashes, so with that setting on, some queries quietly fail or save the wrong thing. From 7.2, WordPress turns it off for its own database connection only (dev note). If you’ve ever had weird, unexplainable “data didn’t save” bugs on one particular host, this might be why. If you don’t know what it is, you don’t need to do anything.

What got cut

• Real-time collaboration (several people editing one post at the same time) is not in 7.2. The roadmap says it was left off on purpose while it’s redesigned.
• AI features stay in the separate WordPress AI plugin for now, not in core.
• React 19 is “unlikely to fully land”, which mostly matters to block developers.

What you should do before 8 December

1. Don’t test on your live site. Make a staging copy (many hosts have a one-click button) or use a local install.
2. On the staging copy, install the WordPress Beta Tester plugin and switch to the beta channel once Beta 1 is out on 20 October.
3. Post a test comment with a < or & in it. Submit each of your forms once. Open a few posts written by Author-role users.
4. Look at anything that shows custom HTML: form confirmation messages, HTML blocks, page builder sections.
5. Check that your plugins have been updated recently. One that hasn’t seen an update in a year is the one to watch (how to spot an abandoned plugin).
6. If something looks broken, switch plugins off one at a time to find the culprit (our plugin conflict guide walks through it), then tell that plugin’s developer.

How we tested

WordPress nightly 7.2-alpha-64337, downloaded 14 October 2026, PHP 8.4, MySQL. Plugin test suites ran against the matching trunk test library. For the HTML comparison we called wp_kses_post() on each document twice, forcing wp_kses_force_legacy_parser to true and then false at priority 999. “Identical” means byte-for-byte. “Markup only” means the same tags, attributes and visible text once both outputs are parsed. Comments went through wp_filter_kses(), the same filter WordPress applies to new comments. All of this is pre-beta code and may change before December.

Frequently asked questions

When is WordPress 7.2 coming out?

The official schedule puts the final release on 8 December 2026. Beta 1 is due on 20 October and Release Candidate 1 on 17 November.

Will WordPress 7.2 break my site?

Probably not. It’s a smaller release than 7.0. The change most likely to cause trouble is the new wp_kses() HTML cleaner, which can change how comments and plugin output look. Test on a staging copy before you update a live site.

Is Ipsum replacing my current theme?

No. Ipsum is planned as the default theme for new installs only. Existing sites keep their current theme when they update, and as of 14 October Ipsum isn’t bundled in the nightly build yet.