WordPress 7.0, named Armstrong after Louis Armstrong, was released on 20 May 2026. It is the biggest core release in years: an AI client built into WordPress itself, the first serious admin redesign since 2013, and a headline feature that was pulled twelve days before launch.

Three weeks on is the right time to write about it. The launch-day posts are all changelog, and the interesting question for anyone who owns a site rather than contributes to core is duller: does any of this change what I have to do on Monday.

Mostly, no. But there are two things worth acting on, and one worth understanding now because it sets the direction for the next few years.

The AI client, and what it does not do

This is the part most widely misreported, so it is worth being precise.

WordPress 7.0 adds an AI Client to core: a provider-agnostic interface that lets plugins talk to generative AI models through one standard set of functions, rather than every plugin author writing their own integration against OpenAI or Anthropic separately.

That is infrastructure, not a feature. Installing WordPress 7.0 does not put an AI button in your editor, does not generate anything, and does not send your content anywhere. WordPress does not contact an AI provider unless you have connected one and installed something that asks it to.

The optional experimental plugin from the core team is where the visible features live at the moment, things like generating image alt text or drafting an excerpt, each opt-in and triggered by hand. I would not install it on a client site yet.

Why the Abilities API is the significant bit

Alongside the AI client sits the Abilities API, and here is the detail almost every summary gets wrong: it did not arrive in 7.0. It shipped in WordPress 6.9, back in 2025, as a PHP registration system with REST endpoints, letting a plugin declare “here is a thing I can do, here is what it takes in, here is what it gives back” in a machine-readable way. What 7.0 added is the client-side half, so abilities can run in the browser as well as on the server.

If you only remember one thing from this release, make it this one, because it is the piece with the longest shadow. For twenty years, the only way for outside software to do something useful with a WordPress site was to be a plugin, or to drive the REST API and hope the endpoints existed. The Abilities API is an attempt at a common vocabulary: a standard way for a plugin to publish what it can do, so something else, an automation tool, an AI agent, a browser extension, can discover and call it without bespoke integration work for every combination.

Whether that becomes the standard or another well-intentioned API nobody adopts, I genuinely do not know, and anyone telling you confidently either way in June 2026 is guessing. What I can say is that it now shapes how I scope custom plugin work, because registering a bespoke feature as an ability costs almost nothing on top of building it and may be worth a lot later.

For a normal business site today it means nothing at all. That is fine. Infrastructure usually means nothing until it does.

Connectors, and the one thing I would check

WordPress 7.0 adds a Connectors screen under Settings, where API keys for external services live in one place instead of scattered across a dozen plugin settings pages. Anthropic, Google and OpenAI ship as featured connectors. Enter a key once and every compatible plugin can use it.

Centralising credentials is the right design. It also means a single screen in wp-admin now holds keys to paid third-party accounts, which changes the shape of the risk if someone gets administrator access.

WordPress looks for a key in an environment variable or a PHP constant before it uses one saved through that settings screen, and given the choice I put credentials in wp-config.php or the server environment. A database gets copied into staging, backups and exports far more casually than a config file does.

If you connect a provider, treat that key like a payment credential, and take it as a prompt to go through a security hardening pass properly.

The admin changes people will actually notice

This is the part clients ring about, because it is the part they can see.

The admin has a new default colour scheme called Modern, with better contrast and typography, and screens now transition rather than snapping between page loads. Nothing has moved, but it looks different enough that someone who logs in twice a month will notice. If you look after sites for other people, a two-line email before you update saves a phone call after it.

The Command Palette is the change I have got the most use out of. Press ⌘K or Ctrl+K anywhere in the dashboard, or click the icon in the admin bar, and you get a search box that jumps you to screens and actions. It existed in the site editor before; now it is everywhere, and it is the one new thing I would actually show a client.

Two others are worth knowing. Font management now has a dedicated page and works with block, hybrid and classic themes, where the old font library only served block themes. And revisions are now visual: you scrub through versions and see what changed, with markers rather than a wall of red and green text.

The feature that was cut, and why it matters

Real-time collaboration, several people editing one post at once with live cursors, was expected in 7.0 for most of the development cycle. On 8 May 2026, twelve days before release, it was removed.

The stated reasons were surface area, race conditions, server load, memory efficiency and recurring bugs found through fuzz testing. It had already been through a redesign of how peers sync changes to each other, and it still was not solid enough. It has not been cancelled: it continues outside core, testable through the Gutenberg plugin.

I think pulling it was the right call, and I would rather core released late than shipped an editor that occasionally eats a post. But what it tells you about planning matters more than the feature. If you were holding off a project because collaborative editing was coming, it is not here, and I would not build a plan around a date nobody has given. It is also a decent argument against updating on release day: a feature can leave a release twelve days out, and things that stay in can still be rough.

PHP 8.3, and what to do if your host is behind

WordPress 7.0 raises the minimum PHP version to 7.4 and drops support for 7.2 and 7.3. The recommended version is PHP 8.3 or greater, with MariaDB 10.11 or MySQL 8.0 as the recommended database.

Minimum and recommended are doing different jobs there. WordPress will run on 7.4, but that version has been end of life for years and gets no security patches from anyone, so running it is a decision about risk rather than compatibility. If your host still has you on 7.4, the release is not the problem. The host is.

Moving up is usually a switch in the hosting panel, and usually uneventful. The thing that breaks is old code: an abandoned plugin, a theme nobody has touched since 2019, or a snippet somebody pasted into functions.php. So do it in the right order. Copy the site to staging, switch PHP there, click through the admin and the front end, check the error log, then do it live. If you cannot easily make a staging copy, that is worth fixing first, and it is the first thing I set up on a maintenance plan.

What it means for a normal business site

Three things, for someone running a site that makes money.

Update, on the normal sensible schedule. Not release day, but not six months from now either, because falling behind on major versions gets expensive to unwind.

Do nothing about AI. Nothing is switched on, there is no setting to disable, and no data is leaving your site. If a plugin vendor advertises AI features built on the core client later this year, judge it on its merits then.

Check your PHP version. That is the only item here with a security consequence attached, and the only one I would put in the diary.

Common questions

Does WordPress 7.0 send my content to an AI company?

No. The AI client in core is an interface for plugins, and with no connector configured and no AI plugin installed, nothing is sent anywhere.

Will WordPress 7.0 break my site?

Probably not, and the likeliest cause if it does is not core but an old plugin, an old theme or an unsupported PHP version. The editor being served in an iframe for newer blocks is the area most likely to surface an issue with older editor plugins, which is exactly what staging is for.

Does the new admin design move things around?

No. It is a new colour scheme, better typography and smoother transitions. Menus and settings are where they were, and the genuinely new thing is the Command Palette on ⌘K or Ctrl+K.

What happened to real-time collaboration?

It was removed from 7.0 on 8 May 2026, twelve days before release, over reliability concerns including race conditions and server load. It is still being worked on outside core and can be tested through the Gutenberg plugin. No release date has been announced for it, and I would treat any date you see quoted as guesswork.

Where I have landed on it

I updated my own sites within a few days and left client sites for a fortnight, which is my default for a major release and had nothing to do with 7.0 specifically. Nothing broke. The Command Palette is the only change that has altered how I work day to day, and the visual revisions are the only one clients have mentioned unprompted.

What I did not do is touch anything AI on a client site, and I am not planning to this quarter. The AI client and the Abilities API are foundations, and foundations are for building on later. Being early with them buys a business site nothing except a maintenance burden.

The thing I did put in the diary is PHP versions. Armstrong is a good release, and the least exciting line in the announcement, the recommended version bump, is the one worth acting on.

If you are not sure what your site is running, that is a five minute answer rather than a project. Tell me what you have got and I will tell you straight.