WordPress 7.2 Beta 1 came out on October 20, and the final release is scheduled for December 8, 2026. The official announcement leads with what editors will see: responsive design controls, text shadows, Notes in the margin. That’s fair. Most people who use WordPress use the block editor.
This post reads the same release from the other side: what changes underneath, what it means for developers and for sites built the classic way, and what’s worth testing in the seven weeks before it ships.
The changes that matter most to developers
A Secrets API
This is the one I’m most interested in. Right now, every plugin that talks to an outside service (payments, email, analytics, AI) stores its API keys however it likes. Usually that means plain text in wp_options, readable by anything that can read the database: a SQL injection, a leaked backup, a malicious plugin.
WordPress 7.2 adds a standard way to store credentials, with encryption at rest, support for rotating keys, and pluggable storage providers, so a site could keep its secrets somewhere other than the database. We just watched the Rank Math PRO backdoor go after every secret the web server could reach. A shared, well-reviewed home for credentials is overdue.
Two caveats. An API only helps once plugins adopt it, and that will take years. And encryption at rest protects against stolen data, such as a leaked database dump, not against code already running on your server, which can call the same API to decrypt. It raises the bar. It doesn’t replace keeping attackers out. The details are on Trac #66187, and Beta 1 is the time to read them and comment.
Admin scripts and styles stop being concatenated
For years, WordPress has bundled admin JavaScript and CSS into a few large combined files. In 7.2 it loads them individually, so browsers can cache each one separately, and it adds prefetching that loads the next likely screen’s assets in advance.
That’s a real performance win, and also the change most likely to break something quietly. Plugins that depend on script loading order, on the old load-scripts.php behavior, or on assets being present because something else pulled them in, may misbehave in the admin, and that kind of breakage tends to show up as console errors and half-working screens, not obvious crashes. If you maintain a plugin with admin screens, open them all on 7.2 with the browser console open (Trac #57548).
Media processed in the browser
Client-side media processing now reaches the Media Library. Images can be resized, compressed and converted in the browser before they’re uploaded, which takes load off the server and helps hosts with weak image libraries.
It also changes where your image pipeline lives. If you rely on server-side hooks to generate sizes, convert formats or optimize uploads, test what arrives on the server now. Is it the original, or something the browser already converted? Does your optimizer plugin process it twice? Sites with strict format rules (this one only accepts WebP for featured images) should check what the browser produces by default.
The API work: Abilities, Interactivity, HTML
- The Abilities API gains new ways to access and query WordPress data, aimed at integrations, automation and AI tools. That’s useful, and it’s also a new door into your content. When an AI tool or integration asks for access, check which abilities it gets and whose permissions it runs with.
- The Interactivity API can now render trusted HTML and manage reactive navigation. “Trusted” is doing a lot of work in that sentence. If you build interactive blocks, be careful about which HTML you mark as trusted.
- The HTML API and block supports get more reliable markup processing.
Random content redirects
There’s a new dedicated URL that sends visitors to a random post. It’s a nice touch for discovery. It’s also a new public endpoint, so check how your caching layer, SEO plugin and security rules treat it. A URL that returns a different redirect every time isn’t something you want cached.
For classic sites
Most of 7.2’s headline features live in the block editor and Site Editor: responsive controls, text shadows, Global Styles filters, navigation management, Notes, the new DataForm-powered block inspector. On a site like this one, where the editor is a plain HTML window, none of that appears.
What classic sites do get:
- The admin changes: faster loading and prefetching, plus Dashicons replaced with the WordPress icon library in the admin bar and sidebar. If your theme or plugin styles admin menu icons by targeting Dashicons classes, that CSS may stop matching.
- The Secrets API and client-side media processing, which don’t depend on the block editor.
- An “On This Day” dashboard widget that surfaces posts from the same date in past years. Harmless, and on a news site, a handy prompt to update old articles.
How to test it, safely
WordPress’s own instruction is the first rule: don’t run a beta on production. This is exactly what a staging site is for. Copy production to staging, then update staging to the beta:
wp core update --version=7.2-beta1Or use the WordPress Beta Tester plugin with the “Bleeding edge” channel and “Beta/RC Only” stream. For a quick look with no setup at all, WordPress Playground runs 7.2 Beta 1 in the browser, but that’s a clean install, not your site, so it won’t catch your problems.
A short checklist for a developer’s first pass:
- Every admin screen your plugins add, with the browser console open
- An image upload, then a look at what actually landed in
uploads/ - Your custom admin CSS, especially anything that targets menu icons
- Any integration that stores API keys, with an eye on whether it should move to the Secrets API
- Your theme’s front end, if it uses blocks, against the new style and design tool changes
If something breaks, report it in the Alpha/Beta support forum or, with clear steps to reproduce, on Trac. Beta 1 is when a bug report is cheapest to fix. Seven weeks from now it will be shipping to millions of sites.