WordPress 7.0 ships provider-agnostic AI client and Abilities API in core

What landed in WordPress 7.0

WordPress 7.0 arrived on 20 May 2026 under the release name Armstrong, roughly six weeks after its originally planned date of 9 April. According to a dev.to write-up, the release credits more than 875 contributors and over 420 enhancements and fixes, and its headline change is that core can now communicate with generative AI models. The more consequential shift, the author argues, is that core now defines how plugins are expected to do so.

The release follows WordPress's convention of naming major versions after jazz musicians, in this case Louis Armstrong. On the editorial side, users get a command palette bound to Ctrl+K or Cmd+K, a modernised dashboard, a dedicated font management screen, visual scrubbing through revisions, and new Heading, Breadcrumbs and Icons blocks alongside a lightbox mode for galleries.

An abstraction, not a model

The central architectural fact is that WordPress did not bundle a model, an API key or a vendor relationship. The core dev note cited by dev.to states that no AI providers ship with core. What ships is a PHP interface: a plugin calls wp_ai_client_prompt(), receives a prompt builder object, chains configuration such as using_temperature() or using_model_preference(), and finishes with generate_text() or generate_image(). Errors return as WP_Error and requests travel through the standard WordPress HTTP transport.

For plugin authors this removes the need to write an HTTP client, retry logic, key storage and a settings page for every vendor. The dev.to author sees genuine deduplication here, but also a concentration of trust in a single central layer that deserves scrutiny before enabling anything.

Connectors and a plaintext key problem

Credentials live in a new Connectors screen under Settings, where an administrator registers a provider. Three provider plugins covering Anthropic, Google and OpenAI are available, each installed separately. A key can resolve from an environment variable, a PHP constant or a database setting, checked in that order.

One detail stands out for anyone maintaining sites: database-stored keys are not encrypted, only masked in the interface, with encryption listed as follow-up work. A key saved through the admin ends up in wp_options in plain text, which means every backup of that database carries a live, billable secret.

The Abilities API

The longer-term change may be the Abilities API, a registry with no inherent connection to AI. Plugins register named units of functionality through wp_register_ability(), supplying a namespaced identifier, a human-readable description, JSON Schema for inputs and outputs, an execute callback and an optional permission callback — typically a capability check such as current_user_can('manage_options'). The JavaScript half of the API shipped in 7.0, alongside the command palette; the PHP half had already arrived in 6.9.

Once abilities exist, other systems can enumerate them: a model can be handed a schema-formatted list of what a site can do and invoke one, and so can the palette. The dev.to author argues this reshapes plugin design, because functionality once reachable only behind a plugin's own admin form, nonce and all, may now be expected to expose a machine-readable contract — a different threat surface and documentation burden.

WordPress 7.1, shipped on 19 August 2026, tightened this registry with validation filters (wp_ability_validate_input and wp_ability_validate_output), an invocation action and a metadata flag controlling whether an ability is discoverable via REST. Its dev note also warns developers not to log invocation input indiscriminately, since it may contain credentials or personal information.

What did not ship

Real-time collaborative editing, the headline feature of the cycle, was removed twelve days before launch. According to the project's path-forward post quoted by dev.to, the schedule slipped specifically to allow more time to address testing feedback on the collaboration implementation, and the cycle returned to beta even while keeping release-candidate version numbers — an unusual move the author considers the right call.

Should you update

The dev.to recommendation is yes, but to 7.1 rather than stopping at 7.0, which has four maintenance releases behind it. Crucially, the AI features stay inactive until a provider plugin is installed and an administrator saves a working key, so updating alone sends no content to any model and creates no account or bill. The practical risk is ordinary plugin and theme compatibility. One consequence worth planning for: a newly installed plugin can now find a key already configured on the site and use it, which is convenient but is exactly the behaviour to set a policy on before it happens by accident.

Why it matters

WordPress powers an enormous share of the web, and whatever core defines becomes the default assumption for its plugin ecosystem. By standardising how sites store AI credentials and describe their own capabilities in machine-readable form, 7.0 moves generative AI integration from a per-plugin problem to a platform-level concern. That lowers the barrier for developers, but it also means every site that updates inherits the trade-offs — plaintext keys in the options table, permission models only as strong as each plugin author's judgement, and a new REST surface listing what the site can do.