It's out. After a delayed launch, a last-minute feature removal, and weeks of "will it / won't it" energy from the community — WordPress 7.0 "Armstrong" officially went live on May 20, 2026.
I covered the pre-release picture in detail earlier in this article — WordPress 7.0 — Let's Dive!. Now that the build is actually in people's hands, this is the post-release breakdown — what shipped, what it feels like in practice, what broke, and what you should do before touching the update button on a production site.
🎺 Why "Armstrong"?
Every WordPress major release gets named after a jazz musician. This time it's Louis "Satchmo" Armstrong — a fitting pick for a release built around giving individual builders more expressive power and their own set of tools to work with.
Armstrong didn't just play jazz — he rewired how the whole genre thought about itself. He took something collaborative and orchestral and made space for individual voice and improvisation to lead. There's a parallel to what WordPress 7.0 is trying to do architecturally: instead of AI being a monolithic, vendor-locked thing bolted on, it becomes a platform where you bring your own model, your own workflow, your own expression.
Also worth flagging: this is the 30th major WordPress release since 1.0 "Miles" shipped in January 2004. More than 900 contributors were involved, with close to 280 of them contributing to a WordPress release for the first time. That's a meaningful number.
🤖 AI in Core — The Real Headline
Let me frame this honestly before we get into the details: WordPress 7.0 doesn't make your site "do AI" automatically. If you update to 7.0 and don't configure anything, your site will feel identical to 6.9. No AI widget, no content generator, nothing.
What 7.0 does is lay down the infrastructure layer — the wiring — so that AI becomes a consistent, stable, vendor-neutral part of how WordPress works going forward. Think back to when the REST API landed. The power wasn't in day one; it was in what the ecosystem built on top of it over the next few years. This is that moment for AI.
Here's the architecture:
WP AI Client
A new communication layer built into Core that any plugin or theme can call to send prompts to an external AI model. The calling code doesn't need to know which model is on the other end — it just talks to the Client, and the Client routes it. This eliminates the pattern of every AI plugin bundling its own SDK and managing its own API keys.
Abilities API (PHP)
A contract system for AI-powered capabilities. A plugin registers what it can do — summarise content, generate an alt text suggestion, rewrite a paragraph — in a way that both humans navigating the UI and machine agents can discover and invoke. This is the piece that makes 7.0 feel agentic rather than just AI-adjacent.
Client-Side Abilities (JavaScript)
The same Abilities concept, now accessible in the browser. There's a built-in UI component and a command palette hook, meaning abilities surface in the editor itself — not buried in settings pages. Developers building editor-integrated AI features will appreciate this a lot.
The AI Plugin (Separate & Optional)
The AI Client on its own generates nothing. To get actual output — image generation, title suggestions, excerpt drafts, alt text — you install the separately distributed AI plugin. It sits on top of the Client and Abilities API and activates the generation features. Purely opt-in.
AI Abilities API surfaced inside the editor — tools appear where you're actually working.
🔌 Connectors — Quick Overview
The Settings → Connectors screen is the user-facing piece of the AI infrastructure, and it solves a genuinely frustrating problem: credential sprawl.
Before 7.0, if you ran multiple AI-powered plugins, you were probably entering the same API keys multiple times across multiple settings panels. Different plugins, same credentials, no coordination. It was messy. 7.0 fixes this at the platform level.
You enter your API key once per provider on the Connectors screen. Any plugin that speaks the AI Client API inherits that connection automatically — no extra configuration, no duplicate keys. Three providers ship ready to connect out of the box: OpenAI, Anthropic (Claude), and Google (Gemini). You're not locked into any of them, and the architecture supports custom providers too.
Settings → Connectors — one screen, one set of credentials, everything that speaks AI Client just works.
The vendor neutrality angle matters here. There's no partnership deal pushing you toward one model. Your API keys stay yours. If the AI landscape shifts in two years (it will), you swap a provider connection — you don't rebuild your plugin stack.
📌 Deeper dive incoming: Connectors is a topic that deserves its own full article — including a video walkthrough of setting up each provider, how to configure multi-provider setups, and which plugins are already building on top of this. Coming soon. Follow along so you don't miss it.
🖥️ The Dashboard Refresh — Long Overdue
Spending a day in the new wp-admin and then opening 6.9 in another tab felt like time travel. The gap is more noticeable than I expected.
New visual foundation
Tighter spacing, a cleaner colour palette, smoother view transitions between screens. Nothing revolutionary in isolation, but together they make the admin feel like a product that was designed rather than accumulated. If you spend hours a day in the dashboard, this compounds.
⌘K / Ctrl+K — Command Palette
This is my personal favourite addition in the entire release. Hit the shortcut from anywhere in wp-admin and a fuzzy-search overlay opens. Type a post title, a settings screen name, a command — you're there instantly. No sidebar, no menu hierarchy, no clicking through three levels. Once it's in your muscle memory you'll miss it in every other CMS you touch.
Hit ⌘K from anywhere in the dashboard — fuzzy search, instant navigation, zero clicking.
Font Library — All themes, one place
Managing fonts previously meant something different depending on whether you were in a block theme, a hybrid theme, or a classic theme. There was no single consistent answer. 7.0 gives you a dedicated Fonts page that works across all three — install a font, upload one, or remove ones you don't need. All in one place, for the first time.
One fonts page. Doesn't care what kind of theme you're running.
Visual Revisions — Actually Usable Now
Revisions in previous WordPress versions showed you a text-based diff. Red lines, green lines. Trying to figure out whether the layout had changed — not just the words — was nearly impossible. The new revisions interface shows visual markers along a scrubber. You can see what the page actually looked like at each save point and restore from there.
Revision history you can actually navigate — scroll, see, restore.
🧱 Four New Blocks
Breadcrumbs
Genuinely surprising this took until 7.0, but here we are. A native Breadcrumbs block with theme.json support and compatibility across all block themes. Goodbye Yoast breadcrumb shortcodes and custom template functions for this specific use case.
Icons
A block that pulls from the @wordpress/icons library and lets you drop UI icons inline — inside callouts, feature lists, service grids. Saves you the "embed an SVG manually or install another plugin" decision on every new site.
Gallery — Lightbox Mode
The Gallery block now has a built-in lightbox and slideshow that activates on click. This was one of the most commonly plugin-dependent features in the editor. It's native now.
Heading — Refined
Less visible, but if you build themes you'll notice: cleaner markup output and more granular per-heading-level style control. Fewer overrides needed in your stylesheets.
🎨 Editor & Design Tools
Per-Block Custom CSS
You can now write CSS for a single block instance right inside the Advanced panel of the block sidebar. Not a global style, not a child theme rule — CSS scoped to that specific block on that specific page. It's one of those features where the moment you use it you'll wonder how it wasn't there before.
Responsive Visibility Controls
Show or hide any block based on device size — mobile, tablet, desktop. Customise where the breakpoints sit. This has been handled by page builders and premium plugins for years; it's now part of Core.
Block-Based Menu Overlay
The mobile nav overlay is a block canvas now. Add whatever you want — multiple columns, a branded header, custom close button, anything your design calls for. The days of the plain sliding menu being un-editable without custom code are done.
Patterns as Single Units
Patterns in the editor now behave as cohesive single objects rather than a loose collection of blocks that could accidentally get broken apart. You can still detach and edit individual elements, but the default is clean, predictable, and much less frustrating on complex layouts.
🛠️ Developer Changes Worth Your Attention
PHP-Only Block Registration
This is my favourite developer addition in the release. You can register a block entirely in PHP — no npm, no webpack, no block.json build step. The Block API picks it up automatically. The barrier for shipping a simple block just dropped significantly for PHP-first developers and plugin authors who've been avoiding the block editor because of the toolchain overhead.
Site Editor as an Extensible Platform
The Site Editor now has proper routing and route validation, plus a new wordpress/boot package that lets plugins register their own custom pages inside the Site Editor shell. It's no longer a closed set of screens — plugins can build native-feeling experiences inside it. This is going to reshape how complex plugins approach their UX over the next year or two.
Interactivity API — watch() and data-wp-watch
Two additions that make reactive block development meaningfully cleaner. watch() lets you subscribe to state signal changes; data-wp-watch is the DOM directive counterpart. If you've built interactive blocks and ended up writing convoluted workarounds to respond to state without a full re-render, these exist specifically for that problem.
Block Bindings — More Control
The new block_bindings_supported_attributes filter lets you explicitly declare which attributes on your custom blocks are eligible for Pattern override. Cleaner, more intentional than the previous behaviour.
Scripts Can Declare Module Dependencies
The script loading system now lets traditional wp_register_script() scripts declare dependencies on ESM modules. It's a small but important step in the ongoing migration toward native browser modules without breaking backward compatibility.
WP-CLI 3.0 Ships Alongside 7.0
Two new command groups: wp block for read-only block entity access, and wp ability for interacting with the AI Abilities API from the command line. If you're building automations or running site audits, these are going to be useful early.
OPCache in Site Health
Tools → Site Health → Info → Server now shows your PHP OPCache status. One less reason to go digging through cPanel or hosting dashboards when diagnosing a performance issue.
Iframed Editor Auto-Detection
When every block on a page declares Block API v3, the editor automatically switches to iframed rendering. This resolves a persistent class of CSS bleed issues between admin styles and editor styles that developers have been working around for years. Old blocks on old API versions? No change — backward compatibility is maintained.
⚠️ Things That Will Break — Check Before You Update
| What | Action Required |
|---|---|
| PHP 7.2 / 7.3 | Upgrade PHP before updating WordPress |
add_theme_support( 'html5', array( 'script' ) ) |
Remove this — script loader handles it natively now |
Author link title attributes |
Gone by default; use new $use_title_attr param where needed |
| Patterns in fully editable mode | Default is now contentOnly — mark content attributes with "role": "content"
|
| backbone.js, Requests, PHPMailer, CodeMirror | All updated — verify any direct integrations |
❌ The RTC Situation
If you read the pre-release article, you already know this — but for anyone coming in fresh:
Real-time collaborative editing did not make it into 7.0.
It was removed twelve days before launch. The reasons were technical and legitimate: concurrent editing sessions were causing race conditions in the sync layer, memory pressure wasn't where it needed to be, and fuzz testing kept surfacing bugs that didn't have clean fixes. Shipping it anyway would have been a mistake the scale of WordPress's user base tends to punish harshly.
The collaborative foundation is still there — block-level Notes, the commenting system, the presence infrastructure. The multi-user simultaneous editing part moves to a feature plugin for extended community testing before attempting another Core merge. WordPress 7.1 (August 2026) is the next candidate window, but no firm commitment has been made yet.
I wrote about the full RTC removal in the pre-release update if you want the longer version.
🚀 How to Update Safely
For existing production sites: hold for one to two weeks. The plugin ecosystem needs time to release compatibility updates, and the combination of your specific theme, plugins, and hosting setup is never quite what the testing matrix covered.
For new sites you're spinning up right now: skip 6.9 entirely. Start on 7.0.
Checklist before you touch anything:
- Take a full backup — files and database. Actually verify it downloaded.
- Confirm your PHP version — 7.4 minimum, 8.2 or 8.3 strongly recommended
- Update plugins and themes on a staging copy before touching Core
- Run the WordPress 7.0 update on staging and test your critical flows
- Push to production once staging is clean From the terminal:
# Update Core
wp core update --version=7.0
# Run the DB upgrade (important after major releases)
wp core update-db
# Flush rewrite rules
wp rewrite flush
💬 Where Does 7.0 Actually Land?
Stepping back from the feature list — what is WordPress 7.0 as a release?
It's a foundations release. The AI layer, the Connectors architecture, the extensible Site Editor, PHP-only blocks — none of these are flashy "look what you can do today" features. They're decisions about how WordPress should work for the next few years. And most of those decisions look right to me.
The AI infrastructure in particular is the kind of thing that will age well. Provider-agnostic, opt-in, built on a proper API surface. The kind of foundation that gets quietly more valuable as the ecosystem builds on top of it.
Losing RTC as the headline took the wind out of the launch narrative somewhat. But honestly, a rushed collaboration feature on 43% of the web would have been far more damaging than a delay. The core team made a hard call and made the right one.
The Command Palette is the thing you'll feel every single day. The visual revisions scrubber is the thing your clients will finally understand. The AI Connectors screen is the thing that will matter most in twelve months.
Welcome to the Armstrong era. 🎺
📡 What's Coming Next
This post opens a series of dedicated 7.0 deep-dives:
- 🔌 Connectors Deep Dive + Video Walkthrough — setting up OpenAI, Claude, and Gemini; multi-provider patterns; real plugin integrations (coming very soon)
- 🧱 PHP-Only Block Registration — Hands-On — building a real block without writing a line of JavaScript
- ⚡ 7.0 Performance in the Real World — benchmarks across major hosting environments
- 🔮 WordPress 7.1 Preview — what RTC might actually look like when it ships in August 🔔 Follow me on dev.to to catch each one as it drops.
Research sources: WordPress.org Official Release, Make WordPress Core, WordPress Developer News, Make WordPress CLI
Top comments (0)