WordPress 7.2: what's new and how to prepare before 8 Dec

WordPress 7.2 has been in beta since 20 October 2026, and the final release has a date: 8 December. That is a good month away, so there is nothing to update today. But there are things worth looking at, because some of the changes in this version never show up in the dashboard. Plugins and themes feel them instead.

One warning before we go on: everything below comes from the beta and the official developer notes. A beta can change until the final version ships, and the release post itself asks you not to install it on live websites.

The schedule

Source: the official 7.2 schedule. The date can slip if something serious turns up.

What you will see as a site owner

A new default theme, with no year in its name. The themes that came with WordPress were called Twenty Twenty-Five, Twenty Twenty-Four and so on. That ends. The next one is called Ipsum, a deliberately minimal block theme for blogs, and future default themes will get their own names and change "when the design calls for it", not every year. According to the team, every colour combination meets WCAG AA accessibility contrast.

Two caveats. The announcement describes it as a proposal "planned" for 7.2, and I could not confirm whether it is already in Beta 1. And it does not change the theme you use: if your site has its own or a commercial theme, Ipsum does not affect you. As a general rule, the themes that ship with WordPress are included but never activated on their own.

More control over how things look on mobile and desktop. The beta post mentions responsive controls in more tools (galleries, image cropping), text shadows, menu editing from the editor sidebar, and notes that stay open next to the block settings. Useful if you edit the site yourself; invisible if you never touch the editor.

Images are processed in the browser before upload. The beta adds client-side resizing, compression and format conversion. In theory, less load on your server. In practice, test it with your usual upload routine, especially if you use an image optimisation plugin: two things doing the same job do not always get along.

New icons in the dashboard. The Dashicons in the admin bar and side menu are replaced by icons from the WordPress icon library. It is a visual change, but there is small print, which you will find below.

A security change that is not part of 7.2 but affects you

The developer notes for 7.2 mention that plugin releases now go through an automated security review. It is not new in 7.2: it has been running since June 2026 and was announced in September.

Here is how it works. Every new version of a plugin in the WordPress.org directory waits through a cooldown (currently six hours) before it is offered to sites. During that time, several AI models and Jetpack Scan analyse it. If the risk score is high, the release is blocked and not distributed until the author publishes a corrected one. Your site keeps running the previous version, and the plugin is not removed from the directory.

The reason, in the team's own words: on 28 July this process caught a backdoor in a plugin with around 20,000 installs before it reached any site.

What that means for you, with some caution:

• It is one more layer, not a guarantee. The documentation admits false positives are not zero, and nothing catches everything.
• It only covers what is distributed through WordPress.org. Premium plugins updated from the vendor's own site do not go through it, or at least the official documentation does not say they do.
• A practical consequence that I am inferring, not something the source states: a plugin security update may take a little longer to reach you. It does not change anything you have to do.

What could break

This is what really justifies testing on staging. The «What's new for developers (October 2026)» guide lists what to check ahead of the beta.

wp_kses() rebuilt. This is the function that cleans the HTML typed in by users or plugins before it is saved or displayed. It is being rebuilt on WordPress's own HTML API, targeting 7.2 or 7.3 depending on how testing goes. The new version normalises the output HTML, strips the contents of script and style tags, and rejects some malformed SVG, MathML and comments. If a plugin compares, stores or tests that HTML as it is, results may differ: WooCommerce has already had to adjust one of its tests. There is a temporary filter, wp_kses_force_legacy_parser, to restore the old behaviour, but the guide treats it as a stopgap.

Icons and dashboard CSS. About 330 core icons become stroke-based. If a plugin or theme has its own dashboard CSS that relies on fill for those icons, it may look wrong. Cosmetic, yes, but a button with no visible icon in an orders screen is still a problem.

SQL mode. WordPress 7.2 removes NO_BACKSLASH_ESCAPES from the database session. That is an improvement: on servers where it was on, queries with escaped characters could fail or return the wrong data. It only causes trouble if something bespoke depends on that mode.

Editor components removed in 7.4. Five components (Divider, ResponsiveWrapper, Scrollable, ZStack, Elevation) are deprecated and will be removed in 7.4. Nothing breaks today. If you have a custom plugin or block, it is a job for your developer, to be done at leisure.

PHP compatibility. I have not found the minimum PHP requirements for 7.2 published. For the current picture, see the PHP and WordPress compatibility table. If you are still on an unsupported PHP version, that job comes before this one, as we explained in the piece on the PHP vulnerability.

How to prepare, depending on your case

A content or brochure site with few plugins.

Update when the final version is out and a few days have passed without serious incidents. Take a backup first, then check the home page, a form and the contact page afterwards.

A WooCommerce shop.

Do not update on the 8th. Wait for the first maintenance release (numbers like 7.2.1 tend to fix what the big release let through), and test on a copy first: a complete test order, the payment gateway, order emails and any plugin that touches the checkout. It is the same list as in the PHP guide, for the same reason.

A site with a page builder or bespoke plugins.

Ask, or check each plugin's page, whether its developer already declares 7.2 compatibility. A plugin that has not been updated in two years is the first one to watch. If you have custom code that cleans HTML with wp_kses(), have whoever wrote it review it now, not in December.

If you would rather not look at any of it.

That is reasonable. Your hosting provider or whoever maintains your site should test it on a copy and tell you if anything fails.

A recipe that works for any version

1. Take a full backup (files and database) before touching anything, stored away from the server.
2. Update what you already have first: the current WordPress branch, plugins and theme. The developer guide points out that September brought three security releases.
3. Clone the site to a test environment and update there.
4. Test whatever earns you money: form, checkout, emails, customer area.
5. Look at the error log and the browser console.
6. If all is well, repeat on the live site at a quiet hour, not on a Friday afternoon.

If you want to try the beta yourself

Do it on a copy or in WordPress Playground, never on the live site. With WP-CLI it would be wp core update --version=7.2-beta1. If something odd turns up, you can report it in the WordPress.org Alpha/Beta forum, which helps get it fixed before December.

When to update and when not to

The rule I recommend is simple, and it works for this version and the next ones:

• Security releases: fast, within a day or two. Attackers read the same advisories you do.
• Major versions (7.2, 7.3…): with a week or two of margin, first on a copy, and with extra care on shops.
• Minor fix releases (7.2.1…): when they come out, after reading what they fix.

Facts checked on 25 October 2026, with the beta still under way. If you spot anything outdated, let us know and we will correct it.

And if you would rather hand the process over, at AGENCIA RSE testing on a copy and checking the checkout are part of our WordPress maintenance. But with the recipe above, you can do it yourself.