WordPress 7.2 roadmap: sudo mode, Secrets API, Gutenberg Notes and the release squad

#Who leads the WordPress 7.2 release

Matt Mullenweg is the Release Lead of the WordPress 7.2 Release Squad, according to the 7.2 release page. The same page lists the rest of the squad:

The release cycle overlaps with a short leadership dispute at Automattic, the company Mullenweg runs. On 10 September 2026 Automattic said he was on leave and that CFO Mark Davies would lead the company as interim CEO. On 12 September a company spokesperson told CMSWire that Mullenweg was chairman and CEO with the full support of the board, and Automattic later put his absence at 33 hours and 20 minutes without explaining the leave. His role in the WordPress open source project did not change during those days: WordPress Executive Director Mary Hubbard stated that he remained the leader of the project (WebHosting.Today).

The release team makes and communicates release decisions and collects community input. Weekly developer chats take place in the #core channel of the Making WordPress Slack on Wednesdays at 15:00 UTC.

#Gutenberg Notes in WordPress 7.2

Notes are already in core. WordPress 7.1 shipped inline notes on selected text, rich text in note bodies, @mention autocomplete and email notifications for mentioned users, according to the Notes iteration issue for 7.2. The roadmap names three additions for 7.2.

With Notes in 7.2, editorial teams should be able to:

• Propose an edit in suggestion mode, which the author then accepts or rejects.
• Add emoji reactions to notes for quick feedback.
• Add a note from the block toolbar, because the option is hard to find today.

As of the 30 September update to that issue, suggestion mode sits behind an experiment in nine pull requests that had not yet had a full review, emoji reactions were carried over from 7.1 and moved to a new emoji picker, and the toolbar shortcut pull request was approved. A separate 7.3 tracking issue collects work that will not fit, so check the Beta 1 dev notes before promising suggestion mode to an editorial team.

#Real-time collaboration in WordPress 7.2

Real-time collaborative editing is not part of 7.2. The roadmap leaves it out while architectural decisions are settled. Real-time collaboration was removed from WordPress 7.0, and on 18 September 2026 Chris Zarate proposed a server-aware approach. Today browsers merge edits directly and send the result when someone saves. Under the proposal, every update passes through WordPress, which records who made it, checks authorization, merges it and stores the result, then sends peers the changes they lack or raises a conflict for review. Browsers would no longer exchange updates with each other.

The post says the exploration is early and not ready for core. Three candidate sync engines (Yjs-server, Distributed Editing and Intent log) live in the gutenberg-sync-engines repository as an exploratory plugin. Hosting is the open cost: merging on the server adds load, frequent polling is more expensive on low-resource plans, and a WebSocket transport would need a daemon running outside the PHP worker pool, managed by the host.

#What is sudo mode in WordPress 7.2

As the web adapts to automated scanning and sophisticated session-hijacking scripts, traditional administrator authentication is no longer sufficient. If a malicious script or attacker intercepts an active administrator’s cookies or session token, they gain unrestricted access to the entire site.

The roadmap lists sudo mode for 7.2: re-authentication before highly privileged actions. The name comes from the Unix sudo command. A stolen session cookie alone would then not be enough to run a privileged action, because the action asks for the credentials again.

Which actions will be gated is not public yet. The roadmap says a proposal and a call for collaboration will follow, and no sudo mode proposal had been published on make.wordpress.org/core when we checked on 12 October 2026. Until it lands, the useful preparation is an inventory: list the custom admin screens and REST endpoints in your plugins that change users, roles and capabilities, files or security settings, because those are the flows a re-authentication step would sit in front of.

#WordPress 7.2 Secrets API for API keys

Storing sensitive credentials (such as Stripe API keys, Mailchimp tokens, or custom database logins) has historically been an architectural vulnerability in WordPress. For over two decades, developers had no choice but to hardcode keys into wp-config.php or save them as un-encrypted options in the wp_options table.

Eric Mann’s Secrets API proposal of 25 August 2026 targets 7.2 with a first-class store for credentials. Its problem statement is concrete: plaintext keys in the options table end up in database dumps, backups, staging clones and CLI output, and plugins that encrypt their own keys each do it differently. AI integrations raise the cost of a leaked key further.

The proposed design:

• Encryption is always on. Each secret gets its own data key, wrapped by a master key, which the site key wraps in turn (envelope encryption). There is no plaintext mode and no constant to switch encryption off. The cryptography uses libsodium, with sodium_compat as the fallback.
• The default store is the options table, holding only ciphertext with autoload=no, excluded from options.php and the REST settings endpoint. A dedicated constant is the preferred key source; sites without one fall back to a key derived from the existing salts.
• External stores plug in through a drop-in. A secrets.php drop-in exposes two separate extension points: storage (for example HashiCorp Vault or AWS Parameter Store) and keyring (a KMS or HSM).
• It fails closed. When the backend is unreachable, the call fails with no local fallback. Values are write-only: there is no export.

#Secrets API functions in WordPress 7.2

wp_set_secret( string $name, string $value ): bool|WP_Error
wp_get_secret( string $name, string $version = WP_Secret_Version::CURRENT ): WP_Secret|null|WP_Error
wp_delete_secret( string $name ): bool|WP_Error
wp_import_option_as_secret( string $option, string $name ): bool|WP_Error

wp_get_secret() returns a WP_Secret object, not a string. The value comes out through reveal(), and fingerprint() gives an identifier that is safe to log. The object masks itself in logs, var_dump() and error output, and refuses serialization. The function returns null when the secret does not exist and a WP_Error when it exists but cannot be decrypted. Names are namespaced by convention as plugin-slug/secret-name.

Two capabilities guard the store: manage_secrets and manage_network_secrets. On multisite a network root key derives per-site subkeys, and site and network secrets use separate functions with no implicit fallback between them. Rotation is operator-driven with two version slots, CURRENT and PREVIOUS, and a hook fires on every write with the actor, the timestamp and the old and new fingerprints.

There is no filter on the retrieval path, on purpose: a filter would let any plugin intercept credentials, so hosts plug in through providers instead. The proposal is also explicit about its limits. Any code running inside WordPress can call wp_get_secret(), and the plugin slug in a secret name is not authenticated, so the API does not isolate one plugin’s secrets from another’s. What it removes is plaintext keys in dumps, backups and staging copies.

For agencies and developers building modern WordPress integrations (including AI agent integrations where API keys are heavily utilized), the Secrets API provides a standardized framework that brings WordPress security closer to enterprise standards.

#How to migrate plugin API keys to the Secrets API

The proposal ships no admin screen in 7.2: a settings screen is deferred to 7.3. WP-CLI support is in scope for 7.2, so that credentials stop appearing in shell history and process lists, but the command names are not decided yet (it is one of the open questions in the post). The proposal plans a feature plugin first and a core patch with the same API after it.

In plugin code, migration is a deliberate step per option through wp_import_option_as_secret(), not an automatic sweep. Imported secrets are flagged for rotation, because the old plaintext value has already travelled into every backup taken so far. A version-safe read for a plugin that has to run on 7.1 and 7.2 looks like this:

$name = 'my-plugin/stripe-key';

if ( function_exists( 'wp_get_secret' ) ) {
	$secret = wp_get_secret( $name );
	if ( null === $secret && get_option( 'my_plugin_stripe_key' ) ) {
		wp_import_option_as_secret( 'my_plugin_stripe_key', $name );
		$secret = wp_get_secret( $name );
	}
	$key = $secret instanceof WP_Secret ? $secret->reveal() : '';
} else {
	$key = (string) get_option( 'my_plugin_stripe_key', '' );
}

The signatures come from the proposal and can change before Beta 1, so keep the function_exists() guard and the old path for sites on 7.1. The proposal does not say whether the import removes the original option, so check the dev note before deleting anything. Once the key lives in the Secrets API, rotate it at the payment or API provider.

#Why hosts object to the Secrets API proposal

The comment thread under the proposal shows where the design is still contested. Chris Reynolds of Pantheon wrote that Pantheon runs an external secrets store with read-only access from applications, asked whether read-only providers are in scope and how plugins should handle the WP_Error a write would return, and noted that platform stores which need plaintext conflict with the drop-in model. Ryan McCue of Altis opposed the proposal as written and argued that WordPress should only read secrets, with encryption left to external HSMs.

Eric Mann replied that a read-only provider can turn the setter into a no-op and that hosts will be able to swap in a stronger provider, with an AWS Secrets Manager example in his secrets-api repository. A pull request to wordpress-develop (#13759) addresses the host provider concerns. Five open questions remain in the post, among them whether two version slots are enough and which WP-CLI commands come first.

For a plugin author the practical consequence is that wp_set_secret() may fail on a managed host by design. A settings form that saves a key must show the returned error instead of assuming success.

#Application Passwords changes in WordPress 7.2

The security section of the roadmap also lists Application Passwords hardening: UX improvements, an email notification when a new application password is added, fixes to environment detection, safer handling of default_role, and SameSite cookie support. The work is tracked in Trac tickets #66009, #63927, #57388, #46744 and #37000. Hardened HTML processing on top of the HTML API completes the security list.

Application passwords are the credential most REST API integrations use, so the notification gives a site owner a signal when someone adds one without their knowledge.

#Other features on the WordPress 7.2 roadmap

Ipsum, the new default theme, is a minimal blog theme built as a blank canvas, with dotted underlines, a handful of type sets and style variations that recolour the whole page, images included. Every colour and style combination meets WCAG AA contrast, according to Henrique Iamarino’s introduction post. It also ends year-based names for default themes. The code is on GitHub for testing, and the team describes the timeline as tight.

AI work continues in the AI plugin, with no guarantee that it lands in core: more abilities (experimental read-only coverage for media, taxonomies and comments), an MCP Adapter updated to the current MCP specification and distributed through the plugin directory, agent identities with auditable permissions, and streaming responses in the PHP AI Client.

In blocks and APIs the roadmap lists a Description list block for <dl>, <dt> and <dd>, keyword search in the Icon block, a data-wp-html directive and a router in the Interactivity API, and server-side rendering for the Table of Contents block so it can become stable. The React 19 upgrade has largely landed in Gutenberg but is unlikely to ship fully in 7.2.

In the admin, DataViews and DataForms get server-registered views, fields and actions, and the post inspector is being replaced by a DataForm. Error messages become easier to diagnose and get a copy button, and a rebuilt Site Editor foundation lets plugins register their own screens. On performance, script and style concatenation is being replaced by prefetching (Trac #57548), alongside work from the Enhanced Responsive Images plugin.

#WordPress 7.2 release schedule

David Baumwald published the WordPress 7.2 release party schedule on make.wordpress.org on 6 October 2026. Every milestone starts at 15:00 UTC.

Beta 1 is the point where core contributors switch to testing and bug fixing and dev notes start to appear. RC1 brings the Field Guide, a hard string freeze and the release branch. After feature freeze only bug fixes are committed, with regressions first.

Install Beta 1 on a staging copy of your site on 20 October and repeat the plugin and theme tests on RC1 (17 November), so conflicts show up on staging before 8 December.

#How to test the WordPress 7.2 beta

There are two documented routes. The WordPress Beta Tester plugin, found under Tools, Beta Testing (Settings on multisite), switches the built-in updater from the default Point release channel to Bleeding edge (trunk) or to beta and RC packages. On the command line, wp core update accepts --version=nightly or a path to a downloaded zip file. Take a backup first and keep betas off production.

What to test follows from the roadmap: plugins that store API keys in options, custom admin flows that change users or files, editorial workflows that rely on Notes, and child themes if you plan to move a site to Ipsum.

#How to prepare your site for WordPress 7.2

WordPress 7.2 represents one of the most structurally significant updates of 2026. The combination of collaborative editor workflows and hardened backend security primitives means agencies and developers must begin preparing their custom setups now.

At WPPoland, we are already preparing our headless Astro setups and serverless MCP integrations to consume the new Secrets API and adapt to Sudo Mode re-authentication flows.

Are you looking to secure your enterprise WordPress installation or migrate your custom plugins to the new 2026 core standards? Contact our core development team today for a custom migration plan.