WordPress 7.2 Beta 1: What's Coming and How to Test (2026)

WordPress 7.2 beta testing starts this week. Beta 1 is scheduled for today — 20 October 2026 — with the release window running 20–22 October, and the final release is planned for 8 December. This is the final major WordPress release of 2026, which means the next seven weeks are your testing window. If you run client sites or maintain plugins and themes, this is your guide. Every claim below is verified against the official 7.2 roadmap, the developer blog, and independent coverage published this week.

Published 20 October 2026 — the beta window is open now, and facts in this post were checked against sources available on this date. Roadmap items below are marked clearly where they are still proposals.

Table of Contents

The WordPress 7.2 Schedule at a Glance

From the official release party schedule and the Make WordPress release schedules page:

Milestone	Date	What it means for you
Beta 1	20–22 October 2026	Feature freeze. Test on staging now; feedback counts most this week.
Beta 2	27 October 2026	Dev notes published; re-test anything they touch.
Beta 3	3 November 2026	Fix your own deprecation notices; test with WP_DEBUG on.
Beta 4	10 November 2026	Last beta. Anything still broken needs a fix scheduled.
Release Candidate 1	17 November 2026	Hard string freeze; the Field Guide collects every dev note. Update “Tested up to” after testing this.
Release Candidate 2	24 November 2026	Ship compatibility releases so users have them before 7.2.
Release Candidate 3	1 December 2026	Final check round.
Dry run + code freeze	7 December 2026	Nothing new lands.
Final release	8 December 2026	Update day (or the day you start testing it, honestly).

Beta 1 is the milestone that matters: once it ships, the feature set is largely locked. Anything that misses the freeze gets pushed to 7.3. The release lead for 7.2 is Matt Mullenweg, and the release party for Beta 1 is scheduled for 15:00 UTC today — so if the download is not live the moment you read this, it will be within the window.

What’s Actually Changing in WordPress 7.2

The 7.2 roadmap is explicit about one thing: everything on it is “being actively pursued, but doesn’t necessarily mean each will make it into the final release.” Treat the list below accordingly — confirmed items first, hedged where the core team is still deciding.

1. Ipsum: A New Default Theme — and a New Naming Era

WordPress 7.2 is expected to ship Ipsum, a minimal blogging theme named after lorem ipsum placeholder text. The interesting part is not just the theme itself — it is the first default theme since 2010 without a year in its name. Going forward, default themes will have their own names and change when the design calls for it, not when the calendar does, following direction from Matt.

Ipsum is designed as a minimal blog theme built around a blank canvas. Theme development is led by Maggie Cabrera and Carolina Nymark. For theme developers, a new default theme is the reference implementation for the block editor’s current capabilities — worth installing on a test site even if you never switch a live site to it, just to see what current best practice looks like.

2. Notes Get a Suggestion Mode — Real-Time Collaboration Stays Out (Again)

Notes — the block commenting feature that shipped in WordPress 6.9 — sits near the top of the 7.2 roadmap. The plan: a suggestion mode that lets collaborators propose edits directly in a post so the author can accept or reject each change, plus emoji reactions and a dedicated shortcut in the block toolbar. Roadmap author Anne McCarthy described the suggestion workflow as a big step forward for collaborating directly with others.

Conspicuously absent: real-time collaborative editing. It was pulled from 7.0, punted during 7.1, and is now intentionally off the 7.2 roadmap — the third consecutive major release where the centerpiece of Phase 3 of the Gutenberg roadmap has not made the cut. “Collaborative editing is intentionally not on the roadmap for 7.2, even as work continues alongside this release cycle,” McCarthy wrote. “As in 7.1, it’s clear more time is needed for a number of architectural decisions, and rather than list it here only to pull it later, it’s being left off entirely.”

If you were waiting for Google-Docs-style live co-editing in WordPress: keep waiting. If you review other people’s drafts, suggestion mode is the feature to test.

3. The Secrets API: WordPress Finally Gets a Concept of a Secret

This is the change security-conscious developers have wanted for years. Right now WordPress has no native concept of a secret — every plugin that needs an API key writes it to the options table in plaintext, because that is the only option. Those credentials then ride along in database dumps, backups, and staging clones. Plugins like Site Kit and WooCommerce payment gateways built their own encryption over the years, but there has never been a shared standard.

The proposed Secrets API — put forward by contributor Eric Mann, who is also release manager for PHP 8.3 and 8.4 — would add a small set of core functions:

wp_set_secret()
wp_get_secret()
wp_delete_secret()

Encryption is always on and cannot be disabled. As Mann puts it: “An API that can be configured to store plaintext is an options API with a misleading name.” His motivation is current: “This was survivable when the average site held a Mailchimp key and a reCAPTCHA secret. AI service integrations have made credentials both more numerous and far more expensive to lose: a leaked model-provider key is a metered spend liability.”

Set expectations correctly: the 7.2 plan is groundwork only — the API would be available through WP-CLI at first, with a management screen expected in 7.3. It will not change anything in your dashboard this release. But if you build or manage custom plugins that store API credentials, this is the API to start planning around.

4. Safer Credentials: Application Passwords Get Hardened

Alongside the Secrets API, application passwords — the tokens that let external apps connect via the REST API without your main login password — are getting attention:

Email notification when a new application password is created. An open core ticket with an accepted patch would email you automatically, the same way WordPress already emails you when your main password or email address changes. This closes a real gap: today, an attacker with admin access could quietly add an application password and keep API access even after you reset your login.
Better detection of non-HTTPS and local environments.
Protection against dangerous default_role values.
SameSite cookie attribute support.

Also on the table: a proposed sudo mode that would require you to re-authenticate before highly privileged admin actions even while signed in. That one is still “under consideration” — do not plan around it yet.

Practical step for this week: audit the application passwords you already have. Check Users → Profile → Application Passwords for each user, note the last-used dates, and revoke anything you do not recognize before the new notifications arrive.

5. The Database Change That Could Bite You: NO_BACKSLASH_ESCAPES

From 7.2, WordPress adds NO_BACKSLASH_ESCAPES to the SQL modes it switches off for its own database connection — alongside modes it already strips like STRICT_ALL_TABLES, TRADITIONAL, and ANSI. The server’s global setting is untouched; only WordPress’s own session changes.

What the mode does: it makes MySQL/MariaDB treat the backslash as an ordinary character inside strings instead of an escape character. With it on, \' no longer escapes a quote and \\ gets stored as two backslashes. WordPress does not work reliably with it on, so from 7.2 core cures those hard-to-find bugs on servers where the mode is enabled.

For the vast majority of sites this is a no-op — host maxinodes.com checked their servers on 11 October and none used the mode. Check your own code only if it opens its own mysqli or PDO connection, sets sql_mode itself, extends wpdb, or escapes values with addslashes(). The dev note documents a db.php drop-in escape hatch via the incompatible_sql_modes filter — a last resort, not a recommendation, since core warns it may not work correctly with the mode on.

6. wp_kses Is Being Rebuilt on the HTML API

WordPress’s HTML sanitizer wp_kses() — a decade-old chain of regular expressions and string processing — is being rebuilt on the HTML API, WordPress’s own standards-compliant parser (tracked as ticket #66208, landing via PR #13271). The new implementation is faster, less memory-hungry, and parses HTML structurally instead of scanning text for patterns — fixing long-standing edge cases like script content surviving tag stripping as plain text.

What changes for you: the function signature stays the same, so most sites, plugins, and themes need no changes. But the new parser normalizes the HTML it returns, removes the contents of <script> and <style> elements, and rejects some malformed SVG, MathML, and comments. If your code sanitizes HTML and then compares, hashes, caches, or snapshot-tests the result, output may no longer match byte-for-byte. There is a temporary escape hatch while you audit:

// Temporary only: fall back to the legacy kses parser.
add_filter( 'wp_kses_force_legacy_parser', '__return_true' );

Treat that filter as a stopgap, report breakages on the Trac ticket, and use the core team’s parser-testing tool to check your HTML. One hedge: the rebuild is targeting 7.2 or 7.3 depending on what testing turns up — so test it in the beta, but do not assume it is final.

7. Admin Modernization: Dashicons Out, Extensible Editor In

The roadmap continues the long modernization of wp-admin:

Replacing Dashicons in the admin bar and menu with modern icons — the icon font has been fixed and unextendable for years, so this is overdue.
A more extensible Site Editor, plus continued DataViews/DataForms iteration including a DataForm-based post inspector.
Accessibility work: more accessible admin notices and automated testing through axe-core.

The editor side is busy too: a planned Description List block, the Table of Contents block moving to server-side rendering, keyword search for the Icon block, custom block states, form elements in Global Styles, expanded responsive style states, dynamic galleries, a redesigned media inserter for large libraries, and performance work replacing script/style concatenation with prefetching alongside better responsive image handling. The visual revisions experience introduced in 7.0 keeps being refined.

8. What’s Deliberately Not in 7.2

Sometimes the most important release note is what is missing:

AI stays out of core. AI features — Abilities, the MCP Adapter, Connectors — are being built in the official AI plugin, with a deliberate gate: proven adoption first, then consideration for core inclusion. Nothing merges until it has demonstrated traction in the wild. For anyone running WordPress where audits matter, this means the 7.2 upgrade introduces no new AI surface area into the codebase.
Real-time collaborative editing is off the roadmap (see above).
The React 19 upgrade is listed on the roadmap but unlikely to fully land in 7.2 — do not assume it.
A renewed attempt at an “On This Day” dashboard widget, after it was deferred from 7.1. It may or may not make the freeze.

How to Test the WordPress 7.2 Beta Safely

Here is the practical workflow for the next seven weeks.

Step 1: Back up before you touch anything

Confirm you have a current, restorable backup of both files and database before installing any beta software or testing plugin. If your host provides automatic backups, check the actual restore point date instead of assuming it is recent. Otherwise run a manual backup with UpdraftPlus or Duplicator and download a copy off-site — not just on the hosting account.

Step 2: Never test a beta on production

Betas do not install themselves — you have to opt in — and that is by design. Clone a current copy of your site to a staging subdomain or local environment. The seven-week beta window exists precisely so regressions get found somewhere disposable.

Step 3: Install the beta three ways

Option A — the Beta Tester plugin (easiest). On your staging site, install the WordPress Beta Tester plugin, choose the “Bleeding edge” channel, and update. The dashboard updater will offer the beta.

Option B — WP-CLI (for developers). On a test install only:

wp core update --version=7.2-beta1
wp core version

Option C — WordPress Playground (fastest). Spin up a disposable Playground instance with the beta loaded — no server, no setup, nothing to clean up afterwards. Perfect for a quick look at the Ipsum theme or the suggestion-mode UI.

Step 4: Click through with intent

Do not just log in and admire the dashboard. Test what 7.2 actually touches:

The block editor: create, edit, and publish with your theme, especially if it has heavy style overrides or custom blocks.
Notes and suggestion mode with a second user account — accept and reject proposed edits.
Forms and anything that sanitizes HTML — run it past the new wp_kses() parser if your code hashes or caches sanitized output.
Anything touching the database directly — check it against the NO_BACKSLASH_ESCAPES change.
Admin screens and the admin bar with your plugins active, watching for icon or layout regressions.
Enable WP_DEBUG and fix your own deprecation notices during the beta rounds, not after RC1.

If you hit errors, enable and read the debug.log — its line format tells you exactly which file and function is responsible.

Step 5: Report what you find

Beta feedback is the whole point. File regressions on Trac with clear reproduction steps, and if the wp_kses() rebuild affects you, run your markup through the core team’s parser-testing tool and report breakages there. Feedback during the beta weeks can still shape the release; after the RC1 string freeze in mid-November, only bugs get fixed.

Step 6: Know when to actually update

For production sites: not on 8 December. Major releases get minor follow-ups for the edge cases beta testing misses; updating a week or two after final — with a fresh backup — is the boring, correct move. If you maintain a plugin or theme, RC1 (17 November) is your real deadline: test against it, then update your “Tested up to” header so users know you are ready. The recent WordPress 7.1.3 security release is a reminder of why the routine of testing before updating matters.

Should You Care About WordPress 7.2?

If you are a site owner who never touches code: modestly. Ipsum is a theme you will probably never switch to, and most of 7.2’s work is invisible infrastructure. But the security groundwork — the Secrets API, application password emails, safer credential handling — is the foundation your plugins will build on in 2027, and AI staying out of core keeps your upgrade path predictable.

If you run an agency or maintain plugins and themes: yes, actively. You have roughly seven weeks. The two changes most likely to surprise you are the wp_kses() rebuild and the NO_BACKSLASH_ESCAPES session change — both are the kind of thing that passes every visual test and fails a checksum. Beta 1 week is when your feedback can still change the release.

WordPress 7.2 Beta 1: What’s Coming and How to Test It Safely (2026)