WordPress 7.2 Lands December 8: What I’m Testing on Client Sites Right Now

WordPress 7.2 is due on December 8, and Beta 3 turned up on October 28, a few days ahead of its original slot. That is usually my signal to stop reading changelogs and start clicking around on real sites. I have spent the last week running the beta against staging copies of a few client projects, and there are a handful of changes worth your attention before the final release lands. Some are front-end polish. A couple could quietly break custom code if you are not watching for them. Most of what follows comes from the WordPress developer team’s October update and my own time in the beta.

Mark your calendar: the 7.2 timeline

The final release is scheduled for December 8 at 15:00 UTC. Release Candidate 1 arrives on November 17, and that is the moment the feature list freezes. If you maintain sites for clients, treat the window between RC1 and December 8 as your real testing period, because what you see in RC1 is what ships. You can check the full cadence in the 2026 major release schedule. I walked through how the 7.x line has been evolving in my WordPress 7.0 rundown for developers, and 7.2 keeps that same steady rhythm of smaller, more frequent releases.

The visible changes your clients will notice

Notes come to the editor canvas

The feature I am most pleased about is Notes. You can now leave a note pinned to a specific block, and it stays visible on the canvas even while the settings sidebar is open. Each note takes a single reaction picked from five emoji. For teams that review content inside WordPress instead of bouncing to email or a chat app, this is a genuine workflow change. I plan to switch it on for a couple of editorial clients the day it ships.

Text shadows, now built in

Typography picks up a text shadow control with None, Light, and Strong presets, and themes can define their own. If you build block themes, you set it up by adding textShadowPresets to theme.json, which generates a CSS custom property and a utility class you can reuse across the site. On the block side it is a supports flag in block.json. Nothing exotic, but it removes one more reason to reach for custom CSS. If you want the rendering details, MDN’s text-shadow reference is the clearest explainer I know.

SVG icons replace Dashicons in the admin

The admin bar and admin menu now use SVG icons instead of the old Dashicons font. Most sites will not notice a thing. But if you have ever targeted a Dashicon with CSS on a custom admin screen or inside a plugin, check those selectors against the beta. This is the kind of change that looks purely cosmetic and then breaks an admin tweak you forgot you wrote three years ago.

Under the hood: what developers actually need to test

This is where I spend most of my beta time, because a few of these changes can bite custom code in ways a quick visual check will miss.

The team is rebuilding wp_kses() on top of the newer HTML API. The sanitized output gets normalized, script and style contents are stripped, and some malformed markup is rejected outright. If any of your code compares sanitized HTML against a stored string, or caches that result, test it against the beta now. There is a wp_kses_force_legacy_parser filter to fall back to the old behavior while you sort things out. This one may land in 7.2 or slip to 7.3, so keep an eye on the release notes.

Another quiet one: wpdb now strips NO_BACKSLASH_ESCAPES from its database session. If your site leans on that SQL mode, you keep it with the incompatible_sql_modes filter, and it has to go in a db.php drop-in because plugins and must-use plugins load too late to catch it.

On the brighter side, roughly 140 core blocks gained supports they did not have before, including backgrounds, borders, shadows, and gradients. The practical win is that a lot of the custom CSS you wrote to style core blocks can now move into the styles.blocks section of theme.json. I am slowly auditing client themes to see what I can delete, and less custom CSS means fewer things to maintain later. If you build custom blocks, the same applies, and it pairs well with the native blocks that already shipped, like the Tabs block in 7.1.

The editor is also inching toward per-breakpoint styling, with new functions in the block editor package for reading and setting styles per viewport state. It is promising. That said, the per-viewport gallery columns did not behave the way the notes described in the build I tested, so treat anything responsive as not final yet. There is early work too on an encrypted credential store for plugins and some sensible hardening around Application Passwords, but I would not build production features on the beta versions of either.

My checklist before I let 7.2 near a live site

Here is the short version of what I run through on every project before the final release:

• Clone to staging first. I never test a major release on a live site, for all the reasons I laid out in my safe-update playbook.
• Run the beta with the real theme and the real plugin stack, not a clean install. Clean installs hide the conflicts that actually matter.
• Search custom code for wp_kses usage and for any Dashicon CSS selectors in admin styling.
• Re-check any block you built or heavily styled against the new block supports, and move CSS into theme.json where you can.
• Confirm your SQL mode assumptions if you run anything custom at the database layer.
• Hold off on the new Ipsum default theme for production child themes until December 8, since its templates and patterns can still change.

The short version

None of this is dramatic, and that is the point. 7.2 is a steady, useful release rather than a reinvention, which is exactly what I want from WordPress at this stage. The real work sits in the quiet details that touch custom code, not the headline features. If you want help putting a proper staging and testing process in place before December 8, or you just want a second set of eyes on a site before you hit update, that is a big part of what I do. The way I set up new projects to make this painless is in my development workflow post. Get in touch and I will take a look at yours.