WordPress 7.2 Roadmap: Sudo Mode, a Secrets API, Notes Suggestions, and What Else Is Planned for December

WordPress 7.2 is the last major release of 2026, and on September 18 the core team published the roadmap for it: the list of features contributors are working toward for an early December launch. By WordPress standards it is a security-heavy list. There is a proposed re-authentication step for dangerous admin actions, an encrypted home for the API keys that plugins currently leave sitting in the database, and a round of Application Passwords hardening, next to editor work like suggestions in Notes and two new or newly stable blocks.

This guide goes through what the WordPress 7.2 roadmap actually says, how firm each item is, and what site owners, agencies, and developers should check before Beta 1 arrives in late October. A roadmap is a statement of intent, not a feature list, so everything below is described as planned. The real list of what shipped comes later, with the Field Guide at Release Candidate 1.

TL;DR

• WordPress 7.2 is scheduled for a December 8–10, 2026 release window, with Wednesday, December 9 proposed so it lands at State of the Word. Beta 1 is due October 20–22 and RC 1 November 17–19.
• The roadmap says every item is "being actively pursued" but may not make the final release. Several items (emoji reactions in Notes, the Table of Contents block, React 19, the On This Day widget) were also planned for 7.1.
• Security is the headline: a possible "sudo mode" (only at the initial-work stage), a Secrets API proposal for encrypted credential storage, and Application Passwords hardening that includes blocking dangerous default_role values.
• Notes gets suggestion mode and emoji reactions. Real-time collaboration is intentionally left out of 7.2, and AI features stay in the separate AI plugin.
• New and stabilized blocks: Description List, and a Table of Contents block that moves to server-side rendering. Ipsum is proposed as the new default theme, ending year-based theme names.
• What to do now: audit admin accounts, Application Passwords, and plaintext API keys, then test Beta 1 on a staging copy. Never install a beta on production.

When Is WordPress 7.2 Coming Out?

The roadmap post puts the release in "early December 2026." The official WordPress 7.2 development page on Make WordPress Core is more precise: the final release window is December 8 to 10, 2026, and the August call for release volunteers named Wednesday, December 9 as the proposed date, with the goal of publishing the release at State of the Word. Matt Mullenweg is the release lead.

The official schedule gives each milestone a window of a few days rather than a fixed date.

The roadmap also carries the usual warning, and it deserves more weight than it normally gets: "what's shared here is being actively pursued, but doesn't necessarily mean each will make it into the final release of WordPress 7.2." Plan your testing around the roadmap. Plan your production changes around the Field Guide.

The WordPress 7.2 Roadmap at a Glance

Not every item on the roadmap is at the same stage. Some are polish on features that already exist; others are proposals that haven't landed in code yet. The wording in the roadmap is the best signal of how likely each one is.

Security Changes Planned for WordPress 7.2

For site owners, this section could matter most, and it's also where the roadmap's language is most careful.

Sudo mode: re-authenticate before dangerous admin actions

Once you log in to wp-admin today, your session cookie is the only thing standing between a request and every admin action: installing plugins and themes, creating users, changing settings. Anything that can make your browser send a request while you are logged in, or anyone who gets hold of that cookie, gets all of that too.

Sudo mode, named after the Unix command and familiar from services like GitHub, adds a second check. The roadmap describes it as a feature "which can gate highly privileged administrative actions behind a re-authentication prompt even when you're already logged in." In practice that means typing your password (or passing a second factor) again before something dangerous happens.

WordPress 7.1.1 gave a timely example of why this matters. The flaw Patchstack calls Click2Shell, fixed on September 17, chained cross-site request forgery into selector injection in the theme install and preview flow. It needed only one thing from the victim: a logged-in administrator loading a crafted URL, whether from a phishing email or from an XSS bug already on the site. A re-authentication prompt in front of theme installation is the kind of step that breaks that chain, because a forged request can't type your password (at least outside whatever grace period follows a successful re-authentication).

Now the careful part. The exact roadmap wording is "Initial work is starting on the possible introduction" of sudo mode. Of everything on the 7.2 list, this is the least settled item. The roadmap doesn't say which actions would be gated, how long an elevated session would last, or how it would treat REST API requests made with Application Passwords or commands run through WP-CLI. Those details decide how much protection it adds. The idea itself is old: Eric Mann wrote up a WordPress sudo proposal back in 2014.

Two things follow from that:

• Don't wait for it. The steps that reduce session-riding risk today still apply: a separate browser profile used only for wp-admin, no clicking email links while logged in there, fewer administrator accounts, and logging out when you're done.
• Two-factor authentication doesn't cover this gap. 2FA protects the login form. After you're logged in, the session is what counts, and that's exactly the gap sudo mode is meant to close. Keep 2FA on anyway; our WordPress two-factor authentication guide covers setup.

A quick way to see who could be targeted this way is to list every administrator on the site:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Every account on that list is one that a crafted link could use. If someone doesn't need full admin rights to do their job, give them a lower role.

A Secrets API for plugin API keys

WordPress has no built-in place to store a credential. When you paste an API key into a plugin (a payment gateway, an email API, an AI provider, an analytics service), it usually ends up in the wp_options table as plain text, and the few plugins that encrypt their keys each do it their own way. So every database export, backup, staging clone, and SQL injection bug that can read options is also a potential key leak.

A proposal published on Make WordPress Core on August 25, also by Eric Mann and now on the 7.2 roadmap, would give plugins a proper API for this. It notes that AI integrations raise the stakes, because a leaked model-provider key is a running bill for whoever finds it.

The proposed functions look like this. These names come from the proposal and may change before 7.2 ships:

// Proposed Secrets API (Make/Core proposal, August 2026). Not in core yet.
wp_set_secret( 'myplugin_api_key', $api_key );   // bool or WP_Error

$secret = wp_get_secret( 'myplugin_api_key' );    // WP_Secret, null, or WP_Error
if ( $secret instanceof WP_Secret ) {
    $client->authenticate( $secret->reveal() );   // plaintext only at the point of use
}

wp_delete_secret( 'myplugin_api_key' );

// Helper for moving an existing plaintext option into encrypted storage.
wp_import_option_as_secret( 'myplugin_api_key_option', 'myplugin_api_key' );

How the proposal works:

• Encryption is always on, using libsodium (with sodium_compat as a fallback). There is no plaintext mode and no constant to disable it, which is what lets a plugin author make a real promise about how a key is stored.
• Envelope encryption. Each secret has its own data key, wrapped by a master key, so rotating the master key means re-wrapping data keys rather than re-encrypting every secret.
• Ciphertext only in the options table, with autoload off, hidden from options.php and the REST settings endpoint, and managed through new manage_secrets and manage_network_secrets capabilities.
• The master key comes from a dedicated constant (recommended) or, as a fallback, from the existing LOGGED_IN_KEY and LOGGED_IN_SALT.
• Two version slots, current and previous, for rotation without downtime. Retiring the old slot is a deliberate operator action, not a timer.
• WP-CLI support is in scope, partly so keys stay out of shell history and process lists on shared servers.
• Hosts can plug in through a secrets.php drop-in that changes where ciphertext lives (a vault service, say) and what wraps the master key (a key management service).
• It ships as a feature plugin first, with the same functions core would get, so code built against the plugin keeps working after merge.

The proposal is also clear about what it does not do: "If a secret lives in the WordPress database and a function exists to decrypt it, then any code running as WordPress can obtain that secret." A malicious or compromised plugin can still read your keys. What the Secrets API protects is data at rest: database dumps, backups in cloud storage, SQL injection bugs that read the options table, compromised read-only replicas, and screens or exports that show option values to the wrong person. Those are common ways keys leak, so it's a real improvement, just not a defense against code running inside WordPress.

Three practical points that the headline coverage tends to skip:

1. Nothing changes until your plugins adopt it. Core offering an API doesn't encrypt keys that plugins already stored. Each plugin has to move its own credentials over, which is why the proposal includes an import helper.
2. Staging copies may not be able to read production secrets. If the master key comes from a constant or from salts, a staging copy with a different wp-config.php won't be able to decrypt the secrets in the database it cloned. That can be a good thing (staging shouldn't send real emails or charge real cards) or a confusing one (integrations stop working on staging for no obvious reason). Decide which one you want before it happens.
3. Be careful with salt rotation. The proposal notes that in Site Kit's existing approach, rotating salts breaks stored credentials, and it handles rotation in core by re-wrapping keys. A tool that simply rewrites the salts in wp-config.php won't know to do that. Once the feature plugin is out, check how your secrets are keyed before you regenerate salts after an incident.

You can see how exposed you are today without waiting for anything. These commands list option names that look like credentials, without printing their values:

wp option list --search="*api_key*" --fields=option_name,autoload
wp option list --search="*secret*" --fields=option_name,autoload
wp option list --search="*token*" --fields=option_name,autoload

This only catches the obvious names. Many plugins keep their keys inside one serialized settings array named after the plugin, so a clean result doesn't mean there are no keys in your database. If you're curious why the autoload column matters, our article on the wp_options autoload problem explains it.

Application Passwords hardening

Application Passwords let external apps and scripts authenticate to the REST API without going through the login screen. That is what makes them useful, and it's also why one created without your knowledge is a quiet, long-lived way into a site. The Rank Math incident earlier this month showed how one can appear without anyone noticing; our Application Password audit guide walks through checking for them.

The 7.2 roadmap lists five tasks in this area:

• General UX improvements to the Application Passwords screens.
• An email notification when an application password is added, so a new one no longer appears silently.
• A fix for a confusing mismatch: on sites without HTTPS, WordPress says Application Passwords need a development environment, but the code actually requires the environment type local.
• A guard that prevents default_role from being set to dangerous values.
• Support for the SameSite cookie attribute.

The default_role item deserves a closer look. A common move after an attacker finds a way to write site options is to turn on "Anyone can register" and set the default role for new users to Administrator, then simply register an account. Blocking dangerous values for that option closes off a well-worn path. You can check both settings now:

wp option get users_can_register
wp option get default_role

On most sites you want 0 for the first (unless you run a membership or community site) and a low-privilege role such as subscriber for the second. If either one surprises you, treat it as a sign of possible compromise, not just a setting to flip back.

To see which environment type your site reports, which affects whether Application Passwords work over plain HTTP:

wp eval 'echo wp_get_environment_type() . PHP_EOL;'

And to list the Application Passwords on a given user account (replace 1 with the user ID):

wp user application-password list 1 --fields=uuid,name,created,last_used

The roadmap also mentions continued work to harden how WordPress parses and processes HTML. It's less visible than the other items, but HTML handling is where many XSS bugs come from, so it's worth noting.

Editorial and Collaboration Changes

Suggestions and emoji reactions in Notes

Notes, the block-level commenting feature that arrived in WordPress 6.9, is the main editor story for 7.2. The roadmap calls suggestion mode "the centerpiece of this cycle": a reviewer proposes an edit inside the post, and the author accepts or rejects it, much like tracked changes in a word processor. The same work adds emoji reactions and a dedicated block toolbar shortcut for adding a note, with the broader goal of making Notes easier to find and use.

For agencies and content teams, this is the change most likely to alter daily work. Client review rounds that now happen in shared documents or email threads could happen on the actual blocks that will be published. Whether it replaces an editorial plugin depends on what that plugin does beyond suggestions (approval workflows, assignments, notifications), so compare feature by feature before switching.

Keep expectations measured. Emoji reactions and an "apply suggestions" feature were both on the 7.1 roadmap in June, and they're back on the list for 7.2.

Real-time collaboration is not part of 7.2

The roadmap is direct about this: "Collaborative editing is intentionally not on the roadmap for 7.2, even as work continues alongside this release cycle." On the same day, a separate Make/Core post described moving real-time collaboration toward a server-aware design, where changes pass through WordPress on the server instead of syncing directly between browsers, with no target release. If you're planning editorial workflows for next year, don't plan around simultaneous editing arriving in December.

Blocks, Design Tools, and the Default Theme

The Table of Contents block becomes stable

The Table of Contents block has been experimental for a long time. The roadmap's goal is to "take the long-experimental Table of Contents block stable by moving it to server-side dynamic rendering, so the editor and front end share one source of truth for headings." A related change in the Gutenberg plugin already stopped the block from saving its output into post content.

The practical difference is where the list of links comes from. A static block writes its HTML into the post when you save. A dynamic block is built by PHP when the page is requested. That keeps the table of contents in sync with your headings, and on a page-cached site the extra rendering cost is negligible. The trade-off shows up for anything that reads raw post_content straight from the database, such as a custom search index or a migration script: it won't see the table of contents markup, because that markup is no longer stored there. Rendered output through the REST API isn't affected in the same way, since dynamic blocks are rendered for it.

If you use a table of contents plugin today, there's no need to rush. Compare the core block after release, especially on long posts with many heading levels.

A new Description List block

The roadmap adds native support for HTML description lists through three static blocks: core/description-list saves as <dl>, core/description-term as <dt>, and core/description-detail as <dd>. Description lists are the correct markup for term-and-definition content: glossaries, product specs, opening hours, or any "label: value" layout that people currently fake with tables or bold text in paragraphs. They also give assistive technology real structure to work with, which bold text in a paragraph doesn't.

Styling: form elements, block states, and more design tools

The design work continues what 7.1 started with responsive and state-based styling:

• Form elements in Global Styles, so common form elements such as buttons and text inputs can be styled consistently from one place. How much of this reaches forms rendered by plugins depends on whether those plugins output the markup that core's styles target.
• Custom states, so you can style the "active" item in interactive blocks, like the current page in a navigation menu, directly from the editor.
• Responsive style states, extending which controls support states, and adding a public API so third-party blocks with custom controls can work with responsive styling.
• Expanded block supports, including backgrounds, dimensions, and position, with more one-off block controls folded into consistent supports.
• View inherited styles. Today, a block whose options are set in Global Styles doesn't show those values in its own settings. This work fixes that, which helps anyone who has inherited a site where "why is this heading blue?" takes twenty minutes to answer.
• Block Editor paper cuts, a broad sweep of small fixes to writing flow, selection, paste, drag-and-drop, and mobile editing.

Ipsum, the proposed new default theme

Ipsum is "the proposal for the next default theme, planned to be bundled in WordPress 7.2," according to the September 16 announcement by design lead Henrique Iamarino. It's described as an intentionally minimal blog theme built as a blank canvas. It also ends the year-based naming tradition: the release squad announcement a week earlier still referred to the default theme as Twenty Twenty-Seven, and default themes will now have their own names instead. The theme is open for testing on GitHub.

For existing sites, a new default theme is not something that happens to you. When core updates, WordPress has historically copied newly bundled themes into wp-content/themes without activating them. If 7.2 bundles Ipsum the usual way, it will show up in your themes list and nothing more. Agencies that keep production installs lean can stop core updates from copying new bundled themes and plugins with a constant in wp-config.php:

// Skip copying newly bundled themes and plugins during core updates.
define( 'CORE_UPGRADE_SKIP_NEW_BUNDLED', true );

The trade-off: Site Health recommends keeping a default theme installed as a fallback in case your active theme breaks, so keep at least one default theme around even with this set.

Admin, Media, Performance, and Accessibility Changes

Admin

• DataViews and DataForms focus on extensibility, with view and form configuration, fields, and actions registered on the server. (The DataForm-based editor inspector has its own call for testing and is a separate topic.)
• An extensible Site Editor built on a new routing foundation, described as already nearing feature parity with the current editor, and designed so plugins can extend it.
• Omnibar updates, including replacing Dashicons with SVG icons in the omnibar that landed in 7.1.
• An error state overhaul, with clearer error messages and a copy button so an error is easier to search for or share with support.
• Navigation editing, making the Site Editor sidebar a more complete place for common menu editing tasks, continuing 7.1 work.
• The "On This Day" dashboard widget, which was punted from 7.1 and is getting another attempt.

Media

• Client-side media processing continues to mature, with a hardened upload pipeline, more supported formats, and performance work. Processing images in the browser moves work away from the server during uploads.
• A redesigned media inserter built for sites with large media libraries, more sources for the dynamic gallery variation, and sorting options for the static Gallery block.
• Better tracking between cropped images and their originals in the Media Editor modal.

Performance: ending script and style concatenation in wp-admin

The roadmap's performance focus is "elimination of script/style concatenation in favor of prefetching and enhanced responsive images." This one matters more to hosts and administrators than the short line suggests.

For years, wp-admin has bundled core scripts and styles into combined requests through load-scripts.php and load-styles.php. That made sense when browsers opened a handful of connections at a time over HTTP/1.1. With HTTP/2 and HTTP/3, many small files can load over one connection, and each can be cached on its own. A long-standing Trac ticket (#57548) proposes stopping concatenation in wp-admin and retiring both files. Contributors in that ticket have also pointed out that combined files still compress better and asked for performance data before switching.

What to check before 7.2:

• Your wp-config.php constants. Some sites define CONCATENATE_SCRIPTS to turn concatenation off, sometimes as an old fix for broken admin screens. If concatenation goes away, the constant stops doing anything:

  terminal

  wp config get CONCATENATE_SCRIPTS 2>/dev/null || echo "CONCATENATE_SCRIPTS not defined"

• Server and firewall rules. Rate limits or blocks aimed at load-scripts.php and load-styles.php were a common hardening step after denial-of-service reports about those files in 2018. If those files are retired, such rules stop matching anything, so review them rather than leaving dead config behind.

• HTTP version. If a site is still served over HTTP/1.1, more separate files can make wp-admin feel slower. Most modern hosting serves HTTP/2 or newer, but it's worth confirming. Our article on why WordPress admin gets slow covers the other usual suspects.

The final behavior depends on what lands before Beta 1, so treat this as something to test, not a guaranteed change.

Accessibility and revisions

The accessibility work includes making sure admin notices are announced properly to assistive technology, adding automated axe-core accessibility testing, making it possible to turn off metabox rearranging, and removing the widget accessibility mode. If anyone on your team still uses the classic Widgets screen with that mode on, it's worth checking how they'll work after the change. Revisions work focuses on polishing the visual revisions experience that shipped in 7.0.

What Developers Should Test Before Beta 1

Most of the roadmap is iteration, but a few items can affect custom code:

• React 19. The upgrade was deferred from 7.1 and "work continues to make Gutenberg fully support React 19, with types, ecosystem dependencies, and rendering fixes largely landed." If you maintain custom blocks, or an admin interface that pulls in React libraries pinned to React 18, test them against the latest Gutenberg plugin on staging now. This is the item most likely to break things quietly if it lands.
• Responsive styling for third-party blocks. A public API is planned so blocks with custom controls can work with the responsive styling mode added in 7.1. If you ship blocks with their own design controls, this is the item to watch.
• The Interactivity API, which is getting a data-wp-html directive and a supported way to observe client-side page transitions through the router.
• Server-registered DataViews and DataForms configuration and the extensible Site Editor, if you build admin screens or add to the Site Editor.
• The Secrets API feature plugin, if your plugin stores credentials. The proposal lists open questions, including whether the version slots are enough and which WP-CLI commands matter most, and feedback before Beta 1 is what shapes the final API.
• The Table of Contents block, if you filter its output or rely on it being saved in post content.

On AI, the roadmap sets a clear bar: "AI features must first demonstrate clear adoption and practical value before being considered for Core." Work on more abilities, MCP support, embeddings and semantic search, streaming responses, and related items continues in the AI plugin, not in 7.2 core.

Which WordPress 7.2 Features Were Already Planned for 7.1?

This is the most useful context for reading any WordPress roadmap. Several items that look new on the 7.2 list were planned or considered for 7.1.

That isn't a criticism. With fixed release dates, features that aren't ready move to the next release instead of holding up the date. It does mean the roadmap is the wrong document to plan production work around. The 7.2 Field Guide, due with RC 1 on November 17–19, tells you what actually shipped.

How to Prepare Your Sites for WordPress 7.2

Now through mid-October: clean up what 7.2 touches

These steps are useful whether or not every roadmap item ships:

• List administrators and remove or downgrade accounts that don't need full rights.
• Audit Application Passwords on every admin account and revoke any you can't explain.
• Check users_can_register and default_role.
• Find plugins storing API keys in plain text, and note which vendors you'll want to adopt the Secrets API.
• Check wp-config.php for CONCATENATE_SCRIPTS and your server config for rules about load-scripts.php.
• If you build custom blocks, test them against the current Gutenberg plugin for React 19 issues.

October 20–22 (Beta 1): test on staging, not production

Beta releases are for testing only. The 7.1 Beta 1 announcement said it plainly: do not install or run a beta on production or mission-critical sites. Make a staging copy and test there. On MagicWP, one-click staging creates that copy from the dashboard.

On the staging site, you can switch to the beta two ways. With the WordPress Beta Tester plugin, the 7.1 Beta 1 instructions used the "Bleeding edge" channel with the "Beta/RC Only" stream. With WP-CLI, the 7.1 cycle used this pattern:

# Run on a staging copy only. Confirm the exact version string in the 7.2 Beta 1 announcement.
wp core update --version=7.2-beta1
wp core version

Then test the things that actually run your business: checkout, forms, logins, your editorial workflow, any custom blocks, and anything that uses an external API key.

November 17–19 (RC 1): read the Field Guide

The Field Guide lists what made it and what didn't, along with developer notes. Compare it against this article. Anything missing from it is not in 7.2, whatever the roadmap said.

December 8–10: update production on your schedule

Release day isn't a deadline. Take a fresh backup (see how MagicWP backups work), confirm your key plugins support 7.2, and update when you're ready. After 7.1 shipped on August 19, a widely used caching plugin caused fatal errors on WordPress 7.1 for many sites. A few days of patience after a major release is a sensible default, but don't sit on the point releases that follow: WordPress 7.1.1 carried 11 security fixes.

Frequently Asked Questions

When will WordPress 7.2 be released?

WordPress 7.2 is scheduled for a December 8–10, 2026 release window, with Wednesday, December 9 proposed so it can launch at State of the Word. Beta 1 is scheduled for October 20–22 and Release Candidate 1 for November 17–19. These are official target windows from Make WordPress Core, and like every WordPress schedule they can move if the release squad finds blocking issues late in the cycle.

Will sudo mode definitely be in WordPress 7.2?

No, it isn't certain. The roadmap says "initial work is starting on the possible introduction" of sudo mode, which is the most tentative wording on the whole list. It would ask administrators to re-authenticate before highly privileged actions even while logged in. Which actions it covers and how long an elevated session lasts haven't been published. Check the 7.2 Field Guide at RC 1 to see whether it made the release.

What is the WordPress Secrets API?

The Secrets API is a proposed core feature that gives plugins a standard way to store credentials such as API keys in encrypted form instead of as plain text in the options table. It uses libsodium with a master key from a dedicated constant or from existing salts. It protects keys in database dumps, backups, and SQL-read bugs, but not from malicious code running inside WordPress. It ships as a feature plugin first.

Will WordPress 7.2 include real-time collaboration?

No. The roadmap says collaborative editing is "intentionally not on the roadmap for 7.2," although work continues. A separate proposal published the same week describes moving real-time collaboration to a server-based design, with no target release. What 7.2 does plan for collaboration is suggestion mode and emoji reactions in Notes, the block-level commenting feature added in WordPress 6.9.

Will Ipsum replace my current theme?

No. Ipsum is proposed as the new default theme for fresh installs. When core updates, WordPress has historically copied new bundled themes into your themes folder without activating them, so your site keeps its current theme. If you don't want new bundled themes copied during updates, the CORE_UPGRADE_SKIP_NEW_BUNDLED constant prevents it, though keeping one default theme installed as a fallback is still a good idea.

Should I install the WordPress 7.2 beta on my live site?

No. Beta releases are for testing only, and WordPress's own beta announcements tell you not to run them on production or mission-critical sites. Create a staging copy, install the beta there with the WordPress Beta Tester plugin or WP-CLI, and test your key workflows. Report anything that breaks through the official channels so it can be fixed before the final release.

Is AI being added to WordPress core in 7.2?

Not directly. The roadmap says AI features "must first demonstrate clear adoption and practical value before being considered for Core." Planned AI work, including more abilities, MCP support, embeddings and semantic search, and streaming responses, continues in the separate AI plugin. That keeps experimental features optional for sites that don't want them.

Will WordPress 7.2 break my plugins or custom blocks?

It's too early to say, because the final feature list isn't set until RC 1. The areas most worth testing are React 19 support in the block editor, changes to the Table of Contents block's rendering, Site Editor extensibility, and the planned end of script and style concatenation in wp-admin. Test on staging from Beta 1 onward and check your plugin vendors' compatibility notes before updating production.

Conclusion

The WordPress 7.2 roadmap is heavier on security than most: a possible sudo mode, a Secrets API proposal that would finally give API keys an encrypted home, and Application Passwords hardening, plus suggestions in Notes, a stable Table of Contents block, and a new default theme. It is also a roadmap, not a release, and several of its items have already slipped once. Read it as a guide to what to test, and wait for the Field Guide in November to know what's actually in the box.

The useful work starts now: audit admin accounts, Application Passwords, and stored keys, then put Beta 1 on a staging copy in late October. If you'd rather not build that testing loop yourself, MagicWP's managed WordPress hosting includes one-click staging, daily off-site backups, and automatic core updates with rollback, so a major release like 7.2 can be tested before it touches your live site.