WordPress 7.2 Beta 1: A Staging Test Checklist for Agencies, and Which Client Sites Go First

WordPress 7.2 Beta 1 was scheduled for October 20, 2026, with Release Candidate 1 on November 17 and the final release on December 8. It is the last major WordPress release of 2026, and several of its changes sit deep in the stack: how WordPress talks to MySQL, how it cleans HTML, and how its icons are drawn.

This piece is a test plan for agencies. It covers the dates, the changes most likely to break a client site, a staging checklist, and an order for which client sites to test first. It also notes what is not in 7.2, because the AI work many people expect is still in plugins.

The short version: put the WordPress 7.2 beta on staging copies of your riskiest sites first. Those are sites with custom database code, sites that store a lot of user-supplied or imported HTML, sites with REST API integrations, and sites running custom blocks. Brochure sites on a maintained theme can wait for the Release Candidate.

As of the morning of October 19, the WordPress 7.2 Beta 1 announcement had not been posted on WordPress.org News. The details below come from the Make WordPress Core posts and the WordPress Developer Blog. Roadmap items are planned, and the roadmap itself says not every item will make the final release.

The WordPress 7.2 beta schedule

The WordPress 7.2 development cycle page lists the milestones below. Release parties run at 15:00 UTC in the #core Slack channel.

One gap to note. The release party schedule from October 6 lists three betas and two Release Candidates. The cycle page lists four and three. The dates that matter most, Beta 1, RC1 and the final release, match in both.

December 8 also lands next to other year-end platform dates. We collected those in our Q4 2026 platform calendar.

NO_BACKSLASH_ESCAPES is now off by default

This is the change most likely to surprise a host or a custom plugin. WordPress 7.2 strips the NO_BACKSLASH_ESCAPES SQL mode from its own database session when it connects.

The Make Core dev note explains why. WordPress escapes special characters in SQL with a backslash. With this mode on, MySQL treats the backslash as an ordinary character, so escaped queries can fail or return the wrong data.

The change affects only the WordPress connection. It does not change the server’s global settings. WordPress already removed other modes this way, such as STRICT_ALL_TABLES and ANSI.

Most sites on the WordPress 7.2 beta will see no difference. If a client site needs the mode, there is a filter, incompatible_sql_modes. It only works from a db.php drop-in, because WordPress connects to the database before plugins load. The Developer Blog puts it plainly: "Plugins and mu-plugins load too late to change it."

What to test: Run your custom reports, imports and exports on staging. Search for strings with quotes and backslashes. Check any plugin that writes raw SQL, such as membership, event or data sync code.

The wp_kses() rebuild on the HTML API

wp_kses() is the HTML sanitizer WordPress uses to strip unsafe markup. It is being rebuilt on the HTML API. Dennis Snell’s progress report says to expect it in WordPress 7.2 or 7.3, depending on testing.

There are no interface changes, so plugin code should not need edits. The output can change, though. According to the report:

• Output is normalized. Tags become lowercase and attributes get double quotes.
• A disallowed script or style element is removed with its contents.
• The parser stops at SVG or MathML it cannot parse with certainty.
• Some malformed HTML comments are rejected.
• Text like <$500 is now kept as escaped text instead of being removed.

The fallback is one line in a plugin: add_filter( 'wp_kses_force_legacy_parser', '__return_true' );. The report says the legacy code "will disappear in future releases or even in WordPress 7.2.0." Treat it as a short-term fix, and report breakage on Trac ticket 66208.

What to test: Save and preview posts with inline SVG, embeds, tables and pasted content. Compare the HTML before and after, not just how the page looks.

Application Passwords, Secrets API and other security work

The roadmap lists hardening for Application Passwords. The Developer Blog names four items: an email notice when a new password is added, detection of non-HTTPS environments, safer default_role values and SameSite cookie support. Each is a separate Trac ticket, so check which ones made Beta 1.

Application Passwords are how many integrations log in to WordPress over the REST API. That includes AMS and CRM sync jobs, headless front ends and automation tools. A new email notice may reach site owners who never saw one before. Tell clients before it does.

The Secrets API is less certain. Eric Mann’s proposal would store API keys encrypted, with a PHP API and WP-CLI support but no admin screen in 7.2. The proposal named Beta 1 as the deadline to commit it or move it to 7.3. If it lands, it bears on the credential storage issues we covered in our Connectors API encryption status check.

The roadmap also lists a sudo mode that asks for your password again before sensitive actions. As of the Developer Blog’s October 14 roundup, that proposal had not been posted.

Ipsum, the new default theme

WordPress 7.2 is planned to ship Ipsum, a minimal blog theme built around a blank canvas. It is the first default theme not named for a year. The introduction post says future default themes will change "when the design calls for it."

The same post says "Every combination passes WCAG AA." That is a design claim, not an audit. It also says development review is still ahead.

For agencies, Ipsum matters most on new builds, demos and starter sites. If you use the default theme as a test baseline for plugin work, add Ipsum to your test matrix.

Blocks and styling changes in the WordPress 7.2 beta

Three block changes are on the roadmap:

• Description List block. A new block for <dl>, <dt> and <dd> markup, useful for glossaries and staff bios.
• Table of Contents block. Moving to server-side rendering. Check pages that already use it, and any CSS that targets its markup.
• Responsive style states. These shipped in WordPress 7.1, but only Core blocks could use them. Gutenberg 24.1 made the helpers public, and 7.2 extends the work.

The new public functions are getStyleForState() and setStyleForState() in @wordpress/block-editor. If your team built per-breakpoint workarounds, as in our responsive block visibility guide, this is the time to see what can be retired.

Stroke-based Core icons will change your custom blocks

Gutenberg 24.1 finished redrawing the Core icon set. The Developer Blog says about 330 icons are now stroke-based, and each one sets fill: none inline on its SVG.

The warning in that post is direct: "A fill prop or CSS fill rule no longer recolors them." Use the CSS color property instead.

The same post says to update @wordpress/icons and @wordpress/components together. Mixing versions can drop merged styles.

Separately, a Make Core post proposes replacing Dashicons in the admin bar and sidebar menu with WordPress icons. It does not name a target release. If you style admin menu icons with custom CSS, check them on the beta.

What to test: Open every custom block and admin screen your team built. Look for icons that are blank, the wrong color or the wrong size.

Deprecations to plan for in 7.4

Gutenberg 24.1 deprecated five components in @wordpress/components: Divider, ResponsiveWrapper, Scrollable, ZStack and Elevation. The Developer Blog says they are marked deprecated since 7.2, with removal planned for 7.4.

The suggested replacements are plain CSS in most cases. Use the Separator component for Divider and CSS aspect-ratio for ResponsiveWrapper.

In MediaUpload, the unstableFeaturedImageFlow prop is now featuredImageFlow. The old name follows the same path to removal.

None of these break in 7.2. Add them to your 7.4 backlog now.

What is not in WordPress 7.2

The Roadmap to 7.2 lists AI work, including the Abilities API and MCP Adapter updates, in the separate AI plugin. It says that work has no guarantee of landing in 7.2.

So if a client asks about AI agents in WordPress, the answer for 7.2 is plugins. Our posts on the Abilities API and what shipped in 7.1 still describe the Core baseline.

Collaborative editing is "intentionally not on the roadmap for 7.2." The React 19 upgrade is listed, but the roadmap says it is unlikely to fully land.

Which client sites to test on the WordPress 7.2 beta first

Not every site needs a beta pass. Start where a change can break real work.

For associations and nonprofits, rows 1 and 3 often describe the same site: the one that syncs members or donations with an AMS or CRM. Test that one first.

A staging checklist for the WordPress 7.2 beta

1. Clone production to staging, including the database and any db.php drop-in.
2. Install the WordPress 7.2 beta and confirm the version in the admin.
3. Check whether the host sets NO_BACKSLASH_ESCAPES, and run your custom queries.
4. Save sample content with SVG, embeds and pasted HTML. Diff the stored HTML.
5. Run every REST API integration that uses Application Passwords.
6. Open each custom block and admin screen. Check icon color and size.
7. Check pages using the Table of Contents block.
8. Log deprecation notices for the 7.4 backlog.
9. Report Core bugs on Trac, with steps to reproduce.

Retest the failures on each new WordPress 7.2 beta. Then do one full pass on RC1, after the string freeze.

Frequently Asked Questions