WordPress 7.2 for Plugin Developers: What Changes and What to Test Before RC1

Most of the breaking changes in WordPress 7.2 will cost a well-maintained plugin an afternoon. The change that deserves real engineering time is not a breaking change at all. It is the new Secrets API, and the reason is simple: a plain-text API key sitting in wp_options is a bigger liability for most plugins than anything 7.2 removes.

That is the position this guide takes, and it shapes the order of everything below. First the schedule, so you know how much time you have. Then the Secrets API, because it is where the most value sits. Then the changes that can actually break a plugin: retired script concatenation, a rebuilt wp_kses(), a database session change and the new admin icons. It finishes with the test environment and the test plan we run on any plugin before a major release reaches its first release candidate.

Every technical detail here was checked against the WordPress 7.2 Beta 1 announcement, the Make WordPress Core posts, the developer blog and the relevant commits on 27 October 2026. 7.2 is still in beta, so function names and behaviour can change before release. Where a feature is not yet confirmed for 7.2, the section says so.

WordPress 7.2 release date and beta schedule

WordPress 7.2 is scheduled for release on 8 December 2026, and it is the final major release of the year. Beta 1 landed on 20 October and froze the feature list. The official release party schedule sets every milestone at 15:00 UTC:

The date that matters most is RC1 on 17 November. Before it, a bug report against a beta can still change what ships. After it, you are mostly confirming fixes. If 7.2 breaks something in your plugin and the cause is a regression in core, the beta weeks are the only window where reporting it changes the outcome for everyone.

What changes for plugin developers in WordPress 7.2

Seven changes in 7.2 are worth a plugin developer's attention. Some add capability, some remove old behaviour, and two are not yet guaranteed to land in this release.

The Beta 1 announcement covers the editor features too: responsive controls, text shadow presets, Notes in the margin, client-side media processing in the Media Library and an "On This Day" dashboard widget. Those matter to site builders, but they rarely break a plugin. The sections below stay with the changes that touch plugin code.

The Secrets API: encrypted storage for API keys

The Secrets API gives plugins a standard way to store credentials encrypted at rest instead of in plain text. It is the most useful addition to WordPress for plugin developers in years, and it arrives without breaking anything.

The problem it solves is familiar to anyone who has built an integration. A plugin that talks to Stripe, an SMTP service, WhatsApp or an AI provider needs to keep a key somewhere. The safe option has always been a constant in wp-config.php, but most site owners cannot or will not edit that file. So the key ends up in wp_options as plain text, and from there it travels into every database backup, every staging copy and every SQL dump a support engineer is ever sent. One leaked backup is one leaked key.

The Beta 1 announcement describes the new API as supporting encryption at rest, credential rotation and customisable storage providers. It was committed to trunk under Trac #66187 on 13 October 2026, following the Secrets API proposal published in August. The function-level behaviour below comes from that ticket and a hands-on test of the committed code on trunk, since the official developer note had not been published when this was written.

The key points for a plugin developer:

• wp_set_secret( $name, $value ) stores a value encrypted and returns true or a WP_Error.

• wp_get_secret( $name ) returns one of three things: a WP_Secret object, null if nothing was ever saved, or a WP_Error if a value exists but cannot be decrypted.

• A WP_Secret object does not print its value. Echoing it, JSON-encoding it or dumping it shows a placeholder. Serialising or cloning it throws an exception. The only way to the plain value is $secret->reveal().

• Values are encrypted with libsodium (XChaCha20-Poly1305), and the key that unlocks them is derived from wp-config.php, never stored in the database. A stolen database on its own yields ciphertext.

• Secret names follow a plugin-slug/key-name pattern using lowercase letters, numbers, hyphens and underscores.

• The functions do not check capabilities, because they must work from cron and REST requests. Your settings screen still has to check current_user_can() and a nonce. Core adds a manage_secrets capability you can use.

• There is no admin screen for secrets in 7.2. It is planned for a later release.

The namespace in the name is for organisation, not access control. Any plugin running on the site can read any secret. That is an honest limitation, and it is the right one: the API protects credentials from leaked databases and backups, not from malicious code already running inside WordPress.

How to read and save a key with the Secrets API on any WordPress version

Your plugin will support versions below 7.2 for a long time, so the integration has to feature-detect the API and fall back cleanly. The pattern we use keeps three sources in a fixed order of trust: a constant first, the Secrets API second, the old option last.

function acme_sync_get_api_key(): string {
	// 1. A constant in wp-config.php is still the strongest option.
	if ( defined( 'ACME_SYNC_API_KEY' ) && ACME_SYNC_API_KEY ) {
		return (string) ACME_SYNC_API_KEY;
	}
 
	// 2. WordPress 7.2 and later.
	if ( function_exists( 'wp_get_secret' ) ) {
		$secret = wp_get_secret( 'acme-sync/api-key' );
 
		if ( $secret instanceof WP_Secret ) {
			$value = $secret->reveal();
			return is_wp_error( $value ) ? '' : $value;
		}
 
		if ( is_wp_error( $secret ) ) {
			// Stored but unreadable. Surface an admin notice.
			// Never fall back to a plain-text copy here.
			return '';
		}
	}
 
	// 3. Older WordPress, or a site that has not migrated yet.
	return (string) get_option( 'acme_sync_api_key', '' );
}
 
function acme_sync_save_api_key( string $key ) {
	// Capability and nonce checks belong in the calling form or route.
	if ( function_exists( 'wp_set_secret' ) ) {
		return wp_set_secret( 'acme-sync/api-key', $key );
	}
 
	return update_option( 'acme_sync_api_key', $key, false );
}

Two details in that code are deliberate.

The WP_Error branch returns an empty string instead of trying the old option. If a site's salts change, every secret becomes unreadable, and silently reading a stale plain-text copy would hide the problem while putting the leaked value back into use. The correct response is a visible notice asking the administrator to re-enter the key.

The null and WP_Error cases are handled separately because they mean different things. null means "never connected", so showing your setup screen is right. WP_Error means "connected, but something is wrong with the encryption keys", and resetting the plugin to its setup screen would confuse the site owner and lose context.

Call reveal() as late as possible, right before the HTTP request that needs the key, and keep the result in a local variable. Do not cache it, log it or pass it through filters. A useful side effect of this design is that every place your plugin touches a credential becomes searchable: look for ->reveal().

Migrating existing keys out of wp_options

Core will not move your plugin's existing options for you. It provides a helper, wp_import_option_as_secret(), which copies an option into a secret, leaves the original option in place and marks the secret as needing rotation. Removing the old option is your job, and it should only happen after you have confirmed the copy reads back correctly.

function acme_sync_migrate_api_key(): void {
	if ( ! function_exists( 'wp_import_option_as_secret' ) ) {
		return;
	}
 
	$legacy = get_option( 'acme_sync_api_key' );
	if ( ! is_string( $legacy ) || '' === $legacy ) {
		return; // Nothing to migrate, or already done.
	}
 
	if ( null !== wp_get_secret( 'acme-sync/api-key' ) ) {
		return; // Never import over an existing secret.
	}
 
	$imported = wp_import_option_as_secret( 'acme_sync_api_key', 'acme-sync/api-key' );
	if ( is_wp_error( $imported ) ) {
		return; // Try again on the next upgrade run.
	}
 
	$secret = wp_get_secret( 'acme-sync/api-key' );
	if ( $secret instanceof WP_Secret && hash_equals( $legacy, (string) $secret->reveal() ) ) {
		delete_option( 'acme_sync_api_key' );
	}
}

Run this from your plugin's upgrade routine, not on every request. The guard against importing over an existing secret matters: a second import moves the current value into the "previous" slot, which is not what you want.

The "needs rotation" flag is the part most developers will be tempted to ignore, and it is the part that matters most. Encrypting a key today does nothing for the plain-text copies already sitting in last month's backups. The real fix is a fresh key from the provider. After migrating, tell your users clearly that they should generate a new key and paste it in, and explain why in one sentence. Site Health lists secrets that still need rotation, so the reminder does not depend on your plugin alone.

WP_SECRETS_KEY, rotation and what the Secrets API does not protect

Three operational details decide whether the Secrets API helps or causes support tickets.

The site key. By default, the encryption key chain starts from the LOGGED_IN_KEY and LOGGED_IN_SALT values in wp-config.php. A dedicated WP_SECRETS_KEY constant overrides that, and Site Health recommends one, because changing the salts (a common step after a compromise) otherwise makes every secret unreadable. The catch is timing: adding WP_SECRETS_KEY to a site that already has secrets changes the site key, and every existing secret then fails to decrypt. Nothing falls back to plain text, which is correct, but the result is still a broken integration. If your documentation tells users to set the constant, tell them to do it before saving any keys.

Rotation. Each secret keeps two slots, current and previous. Saving a new value moves the old one into the previous slot, so you can switch providers' keys without downtime: try the new one, fall back to the previous while the provider catches up, then call wp_retire_secret_version() to remove the old value. Nothing retires it automatically, because core cannot know when your provider stopped accepting it.

What it does not protect. The API is a hardening layer, not a sandbox. It protects against leaked database dumps, SQL injection that reads wp_options, staging copies and keys appearing in debug output. It does not protect against a malicious plugin, an administrator who can run arbitrary code, or anyone who holds both the database and wp-config.php, such as a full-site backup archive. For sites where you control the server, a constant or an environment variable is still the stronger option. The Secrets API exists for the large majority of sites where the administrator pastes the key into a settings screen.

Hosts can also replace the storage entirely through a secrets.php drop-in, moving credentials into a managed vault. If that store is read-only, saving fails, so check wp_secrets_provider_is_writable() before showing an editable key field.

Script and style concatenation is retired: what breaks

WordPress 7.2 no longer concatenates admin and login-screen scripts and styles through load-scripts.php and load-styles.php. Every script and stylesheet is now printed as its own tag, and the two loader files respond with 410 Gone without loading WordPress.

Concatenation made sense when browsers opened few connections per host over HTTP/1.1. It had also been a long-running source of bugs, from ignored SCRIPT_DEBUG settings to duplicated inline styles. Core turned it off by default earlier in the cycle and began prefetching the assets of the next admin screen instead. The commit that retired it landed on 19 October under Trac #57548, the day before Beta 1.

For most plugins, nothing changes. The breakage is concentrated in three patterns:

1. Linking to the loaders directly. Some plugins copied a load-scripts.php or load-styles.php URL from an admin page's source years ago to style a dialog, a preview window or a setup screen. Those requests now get a 410, so the page loses its styles or scripts. The commit notes that around 45 plugins in the directory still do this.

2. Relying on held output. A few plugins set the do_concat property to true, or return false from the print filters, so core holds markup back and the plugin prints it elsewhere. Items are now always printed immediately, so this no longer works.

3. Using the print filters for their return value. print_head_scripts, print_footer_scripts, print_admin_styles and print_late_styles are now applied through apply_filters_deprecated(). Callbacks still run, with a deprecation notice, but their return values are ignored.

Other things keep working. Defining CONCATENATE_SCRIPTS has no effect any more because nothing reads it, so plugins that set it to false are fine. The deprecated properties are still declared, so reading them raises no notice. script_concat_settings(), _print_scripts(), _print_styles(), in_default_dir() and WP_Dependencies::get_etag() are deprecated but still callable, with a notice.

How to find concatenation dependencies in your plugin

A single search across your codebase tells you whether any of this applies. Run it from the plugin's root directory:

grep -rnE "load-(scripts|styles)\.php|CONCATENATE_SCRIPTS|do_concat|print_html|script_concat_settings|_print_(scripts|styles)\(|print_(head|footer)_scripts|print_(admin|late)_styles|in_default_dir" \
  --include=*.php --include=*.js --include=*.html .

Then sort each match into one of three buckets:

• A loader URL in a template, dialog or inline HTML. Replace it. In a page that runs inside WordPress, enqueue the handles you need with wp_enqueue_script() and wp_enqueue_style(). In a standalone page that prints its own document, call wp_print_scripts() and wp_print_styles() with the handles instead.

• do_concat set to true, or a print filter returning false. Rewrite the logic. If you were capturing markup to move it, enqueue in the right place instead, or use the script_loader_tag and style_loader_tag filters to adjust individual tags.

• Everything else (setting do_concat to false, reading default_dirs, defining CONCATENATE_SCRIPTS). This works, but clean it up when convenient, since the code no longer does anything.

Bundled third-party code deserves a look too. A match inside a vendor SDK is still your plugin's problem once it ships in your zip. If you want a quick picture of how many active plugins on a client site might be affected by changes like this, our WordPress Plugin Risk Report lists what a site runs and how recently each plugin was maintained, which is usually the best predictor of who will fix things in time.

wp_kses() on the HTML API: sanitised output will look different

wp_kses(), the function behind wp_kses_post() and most HTML sanitisation in WordPress, is being rebuilt on the HTML API. The progress report targets 7.2 or 7.3, depending on what testing turns up. It is not guaranteed for this release, but if it lands, the output of sanitised HTML changes in ways your code can notice.

The interface stays the same. What changes is the shape of the result:

• Output is normalised. Tags come back lowercase, attributes are double-quoted, the self-closing slash on void elements is dropped and character references are decoded and re-escaped consistently. An <IMG class=x /> input becomes <img class="x">.

• Disallowed script and style elements are removed with their contents. The legacy implementation stripped the tags and left the code behind as visible text.

• Text that only looked like a tag is kept. Input such as "under <$500" used to swallow text; it is now escaped and preserved.

• Incomplete trailing markup is dropped. A fragment that ends mid-tag loses that tail instead of having it escaped.

• Complex SVG and MathML is cut off. Embedded SVG or MathML that needs full tree-aware parsing is rejected from that point onward.

Plugins that only sanitise and output HTML will rarely notice. The risk sits with code that sanitises and then compares the result, such as change detection, cache keys or hashes built from sanitised content, and with unit tests that assert exact HTML strings. The Core team suggests assertEqualHTML() for tests, which compares HTML semantically rather than byte for byte.

There is an escape hatch, add_filter( 'wp_kses_force_legacy_parser', '__return_true' );, which restores the old implementation. Treat it as a way to keep a site running while you fix your code, not as a fix. The report is explicit that the legacy parser will be removed, possibly as early as 7.2.0, and any problems belong on Trac #66208 while there is still time to address them.

NO_BACKSLASH_ESCAPES is now stripped from the database session

From 7.2, wpdb removes the NO_BACKSLASH_ESCAPES SQL mode from WordPress's own database session. The developer note explains why: WordPress escapes special characters with backslashes, and when that mode is enabled on the server, MySQL treats the backslash as a literal character, so escaped queries fail or return wrong data. Some hosts enable it, and the resulting bugs are hard to trace.

For nearly every plugin this is a fix rather than a risk. It only affects WordPress's session, not the server's global settings, and plugins that use $wpdb->prepare() get more predictable behaviour.

If a site genuinely depends on that mode, it can be kept with the existing incompatible_sql_modes filter, but only from a db.php drop-in. WordPress connects to the database before plugins and must-use plugins load, so a filter added in a plugin runs too late. If your plugin opens its own database connection with a separate driver, this change does not touch it, and that connection keeps whatever mode the server sets.

Admin icons, Core icons and deprecated components

The visual changes in 7.2 will not throw errors, but they can make a plugin's admin screens look broken.

Core admin menu and toolbar icons are now SVGs. WordPress 7.2 replaces the Dashicons in the admin bar and sidebar with icons from the WordPress icon library, rendered with wp_get_icon() from 7.1. The Make Core post on the change explains the accessibility reasoning: icon fonts are read inconsistently by screen readers and can vanish in forced-colour modes. If your plugin's admin CSS or JavaScript targets the icon markup of core menu items or toolbar nodes, check those screens. A block's block.json icon slug still falls back to a Dashicon, so block icons are unaffected for now.

Core icons use strokes, not fills. Roughly 330 icons in @wordpress/icons were redrawn as stroke-based SVGs, and each sets fill: none inline. A fill prop or CSS fill rule no longer recolours them; use CSS color instead. The October developer roundup also advises updating @wordpress/icons and @wordpress/components together, because mixing new icons with an older Icon component can drop the merged styles.

Five components are deprecated. Divider, ResponsiveWrapper, Scrollable, ZStack and Elevation in @wordpress/components are marked deprecated since 7.2, with removal planned for 7.4. The suggested replacements are plain CSS (for example aspect-ratio instead of ResponsiveWrapper) and the Separator component instead of Divider. In MediaUpload, unstableFeaturedImageFlow is now featuredImageFlow, with the old name on the same removal path. Nothing breaks in 7.2, but this is the release to schedule the replacement.

Two smaller notes for editor integrations: the post sidebar is being rebuilt on DataForm, and the roundup warns that PluginPostExcerpt may not survive the move. The React 19 upgrade is listed on the roadmap but described as unlikely to fully land in 7.2.

Plugin directory releases now pass an automated security review

Shipping a 7.2 compatibility update now involves one more step outside your code. The WordPress.org Plugins team introduced an automated security review for plugin releases: during the release cooldown, several AI models and Jetpack Scan score each new release. High-risk releases are blocked automatically, and committers receive an email with the findings.

Two practical consequences follow. First, make sure the email address on every committer account is one that somebody actually reads, because a blocked release you do not hear about is a compatibility fix that never reaches users. Second, do not leave your 7.2 update until the week of the final release. Give the release room to be reviewed, and if anything is flagged, room to address it before 8 December. This is one more reason the work belongs in the beta window.

How to set up a WordPress 7.2 test environment

The fastest useful setup is a staging copy of a real site with your plugin configured as a customer would have it, upgraded to the latest 7.2 beta. A clean install catches fatal errors. A realistic one catches the problems your users will actually report. Never install a beta on a production site.

The Beta 1 announcement lists four ways to get 7.2:

• The WordPress Beta Tester plugin. Choose the "Bleeding edge" channel and the "Beta/RC Only" stream, then update from Dashboard, Updates.

• WP-CLI. wp core update --version=7.2-beta1, replacing the version string with the latest beta as each one is released.

• A direct download of the beta zip.

• WordPress Playground, which runs the beta in your browser with no setup. It is ideal for a first look, and its new terminal can run PHP and WP-CLI commands against the live instance.

Test on at least two PHP versions: the lowest your plugin supports and the newest your users run. WordPress itself has required PHP 7.4 or later since 7.0, which dropped support for PHP 7.2 and 7.3. Turn on WP_DEBUG and WP_DEBUG_LOG so deprecation notices from the concatenation changes are written to the log rather than missed.

Keep a second environment on 7.1 alongside it. Several checks below compare output between versions, and a side-by-side diff is far quicker than reasoning about what changed.

A test plan for WordPress 7.2 compatibility

A plugin that activates without a fatal error on 7.2 has passed the smallest possible test. Before RC1, we work through this list for every plugin we maintain:

1. Activate, deactivate and upgrade. Activate the plugin on 7.2, then run your upgrade routine from the previous release with real data, and confirm the debug log stays clean.

2. Run the concatenation search. Use the search command above and resolve every loader URL and every reliance on held output.

3. Open every admin screen. Load each settings page, dialog, preview window and setup wizard with the browser's network panel open. Any request to load-scripts.php or load-styles.php returning 410 is a bug.

4. Diff sanitised output. Push a set of real HTML fixtures through wp_kses_post() on 7.1 and on 7.2, and compare the results. A quick way with WP-CLI is wp eval 'echo wp_kses_post( file_get_contents( "fixture.html" ) );' on each install. Then repeat the run with the HTML API parser forced on, in case it lands.

5. Re-run your test suite. Pay attention to assertions on exact HTML strings and switch them to semantic comparison where the difference is cosmetic.

6. Exercise every query path. Run search, filters and any custom SQL with values containing quotes and backslashes, and confirm the results match 7.1.

7. Check the admin visually. Look at any screen where your CSS touches core menu items, the toolbar or icons, and check icon colours in both light and dark admin colour schemes.

8. Search for deprecated components. Look for Divider, ResponsiveWrapper, Scrollable, ZStack, Elevation and unstableFeaturedImageFlow, and plan their replacements before 7.4.

9. Prototype the Secrets API. Wire the getter, setter and migration into a branch, test all three return types, and test what happens when the site key changes.

10. Report anything that looks like a core regression on Trac or in the Alpha/Beta support forum, with steps to reproduce, while there is still time to fix it.

Each of these, along with pass criteria and a readiness score, is in the printable worksheet below, so a team can split the work and tick it off plugin by plugin.

When to update "Tested up to" and ship

Update the "Tested up to" header in your readme.txt once you have tested against RC1, not before. Raising it during the beta tells users you have tested a version that may still change. Leaving it until after 8 December means that, from the day 7.2 ships, your plugin's directory page warns users it has not been tested with the latest major release.

A sensible sequence looks like this:

• During the betas: fix anything the test plan finds, and ship those fixes in a normal release. Fixes that work on both 7.1 and 7.2 do not need to wait for anything.

• At RC1 on 17 November: rerun the plan against the release candidate and raise "Tested up to" to 7.2.

• Before 8 December: ship the release that includes the updated header, leaving time for the automated security review.

The Secrets API is a separate track. Because it is purely additive and feature-detected, you can ship the getter and setter as soon as 7.2 is released, then run the migration in a later version once you are confident in it. There is no reason to rush a credential migration into the same release as a compatibility fix. If you build integrations for clients, this is also a good moment to look at how your plugins handle credentials more broadly, and our guide to WordPress plugin development covers the settings, security and release practices that make changes like these routine. For a plugin that needs this work done properly and quickly, our WordPress plugin development service covers compatibility updates and Secrets API migrations.