WordPress 7.0 shipped on 20 May 2026 under the release name Armstrong, six weeks later than the date on the original 2026 schedule, and it is the most consequential core release for agencies since the block editor. The headline is that core can now talk to generative AI models. The detail that matters more is that core now defines how a plugin is supposed to talk to them, which quietly changes what every plugin on the site is allowed to assume about its own territory.

For an editor, the visible changes are modest. There is a command palette, a tidier dashboard, a font management screen and better revisions. For anyone who maintains sites professionally, the important changes sit underneath the admin: a credential store in the options table, a registry of things the site can do, and a REST surface that lists them. None of it is optional, because it arrives with core rather than with a plugin somebody chose.

This is the practitioner’s read. What actually landed, what was pulled twelve days before release and why, what the update will and will not break, and what to say to a client who has just read a headline about AI going into WordPress.

Should you update? Yes, but go to 7.1 rather than stopping at 7.0. WordPress 7.1 shipped on 19 August 2026 and 7.0 has four maintenance releases behind it. The AI features are inert until an administrator saves a provider key under Settings then Connectors, so the update on its own sends none of your content anywhere. The real risk in this update is ordinary plugin and theme compatibility, not the AI.

What Actually Shipped in WordPress 7.0

The release is named after Louis Armstrong, following the project’s convention of naming major versions after jazz musicians. The release announcement credits more than 875 contributors and over 420 enhancements and fixes.

The list of what landed is short enough to be useful. Core gained an AI Client, a provider-agnostic PHP interface for sending prompts to generative models. It gained a Connectors screen under Settings, where an administrator stores provider credentials. It gained the JavaScript half of the Abilities API, whose PHP half had already shipped in 6.9.

On the editorial side there is a command palette on Ctrl+K or Cmd+K, a modernised dashboard, a dedicated font management page, visual scrubbing through revisions, and new Heading, Breadcrumbs and Icons blocks alongside a lightbox slideshow for galleries.

What did not land was the feature the whole release had been built around. Real-time collaborative editing was removed twelve days before launch. That absence, and the reason behind it, tell you more about the current state of core than the feature list does.

Why the date moved

The release was originally scheduled for 9 April 2026. It slipped to 20 May because collaborative editing was not ready and the project would not ship it as it stood. The path forward post is explicit that the delay existed “to allow more time to address testing feedback about the implementation of real-time collaboration”, and the cycle went back into beta while keeping release candidate version numbers for technical reasons.

That is unusual. A major release returning to beta after reaching RC is a strong signal, and it was the right call.

The AI Client: Core Ships the Abstraction, Not the Model

The single most important architectural fact about WordPress 7.0 is that core does not include an AI model, an API key, or a relationship with any vendor. The AI Client dev note states plainly that “WordPress Core does not bundle any AI providers directly”.

What core ships is a consistent PHP interface. A plugin calls wp_ai_client_prompt(), which returns a WP_AI_Client_Prompt_Builder object, chains configuration such as using_temperature() or using_model_preference(), and finishes with generate_text() or generate_image(). Errors come back as WP_Error, requests go through the WordPress HTTP transport, and the whole thing is wired into the hooks system.

The practical effect is that a plugin author no longer writes an HTTP client, a retry loop, a key storage screen and a settings page for every model vendor. They describe what they want and core routes it.

That is a genuine reduction in duplicated code. It is also a centralisation of trust, which is the part worth thinking about before you switch anything on.

What a connector is

A connector is the registered relationship between your site and an external service. In 7.0 the only connector type is AI providers, and there are three flagship provider plugins covering Anthropic, Google and OpenAI, each installed separately.

The Connectors API dev note describes how credentials resolve. A key can come from an environment variable, a PHP constant, or a database setting, checked in that order, with option names following the pattern connectors_ai_{$id}_api_key.

One detail deserves attention from anyone responsible for a site. The dev note says API keys stored in the database “are not encrypted but are masked in the user interface”, with encryption tracked as follow-up work. If you set a key through the admin screen, it sits in wp_options in plain text, and every backup of that database now contains a billable credential.

What this means if you do not write code

For a site owner the change is simpler than it sounds. Nothing generates, summarises or rewrites anything until two things are true: a provider plugin is installed, and somebody has pasted a working key into Settings then Connectors.

Until then the AI Client is a dormant library. Updating to WordPress 7.0 does not send your posts to a model, does not create an account anywhere, and does not incur a bill.

What it does do is lower the barrier for the next plugin you install. A plugin that previously had to ask you for a key can now find one already configured on the site and use it. That is convenient, and it is exactly the thing to write a policy about before it happens by accident.

The Abilities API and Why Plugin Design Changes

The Abilities API is the piece that will still matter in three years, and it has nothing inherently to do with AI. It is a registry. A plugin registers a named unit of functionality with wp_register_ability(), in the form namespace/ability-name, with a human-readable description, JSON Schema for its inputs and outputs, an execute callback and an optional permission callback.

The official documentation shows the permission callback as an ordinary capability check, for example returning current_user_can( 'manage_options' ). That is the whole security model, and it is only as good as the plugin author’s judgement.

Once abilities exist, other things can enumerate them. A model can be handed a list of what this specific site can do, in schema form, and can call one. So can a client-side command palette, which is why the JavaScript half of the API landed in the same release as the palette.

The design consequence for plugin authors is real. A feature that used to be reachable only through your own admin screen, with your own nonce and your own form, is now something you may be expected to expose as an ability with a machine-readable contract. That is a different threat surface and a different documentation burden.

What changed in 7.1

WordPress 7.1 tightened the registry rather than expanding it. The 7.1 abilities dev note adds validation filters wp_ability_validate_input and wp_ability_validate_output, an action wp_ability_invoked that fires at the start of execution, and a public metadata flag controlling whether an ability is discoverable over REST at /wp-json/wp-abilities/v1/abilities.

That dev note also carries the sentence every logging plugin author should read. The invocation hook receives raw, unnormalised input, and developers “should avoid logging input indiscriminately, because it may contain credentials, personal information, or other sensitive data”.

Real-Time Collaboration and the Table It Needed

Collaborative editing is built on Yjs, a conflict-free replicated data type, with a sync provider abstraction. Core ships an HTTP polling provider by default, chosen over WebSockets because it works on any host, and plugins can swap the transport through a filter.

The problem was never the merge algorithm. It was where the sync data lived. The original implementation persisted it in post meta, which is the obvious choice in WordPress and the wrong one for data that changes several times per second.

Post meta writes fire cache invalidation. With an editor open, sync data was being written continuously, so every write cleared cached queries for that post. In practice a single person editing a page could keep the site’s persistent object cache flushing for the duration of the session.

That is a good general lesson about post meta. It is a key value store attached to the cache lifecycle of the content it hangs off, and it is fine for attributes that change when the post changes. It is not a scratch space for high-frequency state.

The measured fix, and the decision

Contributors tested storage strategies across eight hosting environments. The performance analysis concluded that a dedicated table backed by transients was around 52% faster than the existing implementation, and a plain dedicated table around 37% faster. With a persistent object cache present, both transient-backed strategies dropped to a single database query per dispatch.

The custom table with transients was chosen. Then, on the same day, the feature was pulled.

The removal notice cites “concerns around surface area, race conditions, server load, memory efficiency, and recurring bugs found through fuzz testing”, and says the decision was made “in service of shipping a stable and reliable WordPress 7.0 release for our users”.

Where it stands now

It did not ship in 7.1 either. The 7.1 field guide states that real-time collaborative editing “received extensive testing and feedback during the WordPress 7.1 cycle, but it is not enabled in the final release”.

Notes, which is the related but separate feature for leaving block-level comments, did ship and was improved in 7.1 with rich text formatting and @ mentions. If a client asks for Google Docs style co-editing in WordPress, the honest answer today is that Notes covers the review workflow and simultaneous typing is still not in core.

The Admin Changes and the Tickets They Generate

Two changes will produce support requests, and neither is a bug.

The command palette on Ctrl+K or Cmd+K is genuinely fast once learned, but Ctrl+K is the keyboard shortcut for inserting a link in many editors, and some users will report that link insertion has broken. It has not; focus context decides which handler wins.

The modernised dashboard is the larger one. Any client whose staff were trained on screenshots now has out of date training material, and any plugin that injected markup into admin screens by assuming particular classes or DOM structure may render oddly. This is cosmetic rather than functional, but it arrives on the day of the update, on every site, for every user, which makes it the most visible part of the release to the people who are not developers.

Budget an hour per client for a short written note with new screenshots before you update anything. It is cheaper than the same explanation given fifteen times by email.

The Compatibility Question That Actually Matters

The version numbering suggests a breaking release. The PHP requirements do not. As the PHP support clarification sets out, the minimum supported PHP version is 7.4 since WordPress 7.0, and the minimum recommended version remains 8.3. Support for PHP 7.2 and 7.3 was dropped in this release.

The clarification also retired the old “beta” label for newer PHP versions, and records full support for PHP 8.5 in WordPress 6.9 and 7.0.

The gap between supported and sensible is the point. PHP 7.4 reached end of life in November 2022, so a site that only just clears the minimum is running an interpreter that has had no security fixes for close to four years. If your hosting is still on 7.4 in 2026, the WordPress version is not your most urgent problem.

Breakage in practice follows a predictable pattern. Abandoned plugins fail first, particularly anything that manipulates the admin DOM or the editor iframe. Custom themes with hard-coded admin styling look wrong. Page builders that ship their own React bundles are the usual source of white screens in the editor, and they are also usually the fastest to patch.

A concrete update procedure

Stage it. Clone production, including the database, to an environment that is not indexable and not sending email. Nothing below is worth doing on a live site.

Record the baseline. Note the PHP version, the plugin and theme list with versions, and the current WordPress version. Take screenshots of the two or three admin screens the client uses daily.

Update WordPress alone first. Leave plugins and themes untouched, then walk the front end, the post editor, the site editor, WooCommerce checkout if present, and any custom admin screens. A failure here belongs to core or to an incompatible extension, and separating that from a plugin update is the whole reason to do it in this order.

Then update plugins in small batches, retesting between batches, so a regression has a short list of suspects.

Check error logs rather than eyeballing pages. PHP notices from a deprecated call do not always render visibly and will fill a log quietly for months.

Leave the Connectors screen empty. Ship the update with no AI provider configured, and treat enabling one as a separate, deliberate change with its own approval. Our WordPress security hardening checklist covers the surrounding controls, and the performance audit guide covers what to measure afterwards.

Governance: What a Connector Is Permitted To Do

Here is the question that the abilities layer creates and that no plugin author can answer for you. A third party plugin can register an ability that reads customer records, exports users, or edits published content, and a model with access to the registry can call it. The permission callback is a capability check, so the model acts with the permissions of whoever is signed in.

If that person is an administrator, the model can do administrator things. That is not a defect in the design; it is the design working as documented. It does mean the decision about which connectors exist on a site is a data protection decision, not an IT preference.

Content in a CMS is rarely just marketing copy. Comments, form submissions, order records and user profiles are personal data, and sending them to an external model is a processing operation you have to be able to justify. The ICO’s guidance on AI and data protection sets out the accountability and transparency expectations, including demonstrating data protection by design and keeping governance proportionate to the use.

The practical minimum for a client site is a short written policy: which connectors are permitted, who may add one, which abilities are exposed publicly over REST, and what the retention position is with the provider. Write it before somebody pastes a key in, because afterwards it is an incident report rather than a policy.

What Is Queued Next

WordPress 7.1 arrived on 19 August 2026 with responsive styling controls in Global Styles, a persistent admin bar across editors, a proper media editing modal, Playlist and Tabs blocks, and the Notes improvements already mentioned. It also completed the move to an iframed post editor, including for sites registering legacy meta boxes, which is the change most likely to expose an old plugin.

WordPress 7.2 is planned as the final major release of 2026. The 7.2 release page puts the final release in the window of 8 to 10 December 2026, with betas from late October. That schedule is planned rather than shipped, and this project has already moved one major release date this year.

Collaborative editing remains the obvious candidate for a future release, but it has now missed two, and nobody should promise a client a date for it.

What This Changes Commercially

Three client conversations change, and only one of them is about AI.

The first is the update conversation. WordPress 7.0 and 7.1 are worth charging for as a managed update with a staging pass, because the iframed editor and the admin redesign genuinely surface old extensions. Selling that as a fixed-price package with a written test plan is more honest and more profitable than absorbing it into a retainer and discovering a broken page builder at 6pm.

The second is governance. Connector policy, ability review and credential handling are billable advisory work that did not exist before May 2026, and they suit an agency far better than they suit an in-house marketing team.

The third is build work. The AI Client removes the boring half of building an AI feature into a site, which lowers the price of the plumbing and raises the value of knowing what is worth building. If you are weighing that against a bespoke build, our comparison of WordPress and custom development covers where the line usually falls, and our notes on WordPress developer rates cover what the work should cost.

Mecanik handles core version upgrades, connector governance and AI feature work as part of our WordPress development and AI integration services. The pattern we see is consistent: the update itself is routine, and the expensive surprises come from extensions nobody had reviewed in three years.

Frequently Asked Questions

When was WordPress 7.0 released and why was it delayed? WordPress 7.0 “Armstrong” was released on 20 May 2026, six weeks after the 9 April date on the original schedule. The delay was to address testing feedback on the real-time collaborative editing implementation, and the cycle returned to beta after reaching release candidate. Collaborative editing was ultimately removed from the release on 8 May 2026.

Does WordPress 7.0 send my content to an AI provider? No. Core ships an AI Client but bundles no AI providers, no models and no API keys. Nothing is sent anywhere until an administrator installs a provider plugin and saves a working credential under Settings then Connectors. Until that happens the AI Client is a dormant library that costs nothing and transmits nothing.

What is the Abilities API for? It is a registry that lets a plugin declare a named unit of functionality with JSON Schema inputs and outputs, a permission callback and an execute callback. Other software, including AI models and the command palette, can then enumerate what a site can do and call it. The PHP half shipped in WordPress 6.9 and the JavaScript half in 7.0.

What PHP version does WordPress 7.0 require? The minimum supported version is PHP 7.4 since WordPress 7.0, which dropped support for PHP 7.2 and 7.3. The minimum recommended version remains PHP 8.3. Since PHP 7.4 reached end of life in November 2022, running only the minimum means running an unsupported interpreter, so treat 8.3 or higher as the real requirement.

Is real-time collaborative editing available yet? Not in core. It was removed from WordPress 7.0 twelve days before release over concerns about race conditions, server load and memory efficiency, and it is not enabled in WordPress 7.1 either. The separate Notes feature, which allows block-level comments with mentions, did ship and covers review workflows rather than simultaneous typing.