What Ships in WordPress 7.0
WordPress 7.0 shipped May 20, 2026 without the collaboration features its roadmap had promised for months. For months the release had been billed as the collaboration update: real-time, multi-user editing in the block editor, Google Docs style. Twelve days before launch, Matt Mullenweg pulled it. Fuzz testing had surfaced race conditions, memory pressure, and server-load failures that couldn't be resolved in time for the 41 percent of the web running WordPress. What replaced it is a native AI layer built from three interlocking pieces: the AI Client, the Abilities API, and a Connectors screen under Settings. The release, codenamed Armstrong, closes Phase 3 of Gutenberg's four-phase plan and was built by more than 900 contributors, including over 200 first-timers.
The AI Client is a provider-agnostic interface. It lets core (and any plugin that adopts it) talk to Anthropic, OpenAI, Google, Vercel AI Gateway, or a self-hosted model without writing a separate integration for each. The Abilities API, introduced in 6.9 and expanded in 7.0, gives plugins a standardized vocabulary to describe what they can do: create a post, update a taxonomy term, fetch analytics, run a custom query. Version 7.0 adds a client-side JavaScript package, @wordpress/core-abilities, that discovers server-registered abilities automatically. The Connectors screen provides one place to add, update, or remove AI connections. Anthropic, Google, and OpenAI ship as default providers; the registry is extensible via the wp_connectors_init action.
Beyond the AI triad, 7.0 delivers a modernized dashboard with agentic-AI experiments behind a feature flag, a Command Palette (Cmd-K / Ctrl-K) on every admin screen, block-level custom CSS scoped to individual blocks, a native Icons block with theme-aware color tokens, and Visual Revisions: a slider-driven comparison view with color-coded markers for additions, deletions, and restyles. Notes gains email notifications and a Suggestions mode for editorial review. Server-side block registration arrives with an autoRegister option, eliminating a JavaScript build step for simple blocks. The editor runs in an iframe when all blocks use Block API version 3 or higher, isolating theme styles from the editing surface. PHP 7.4 becomes the minimum runtime; usage of 7.2 and 7.3 had fallen below the project's 5 percent retirement threshold.
Several blocks previewed during the cycle — Tabs, Slider, Dialog, Playlist, Table of Contents — did not ship in core. Real-time collaboration remains testable through the Gutenberg plugin, with a roadmap for broader iteration promised. The AI foundations in 7.0 are what the next generation of plugins will build on.
How the Abilities API Rewrites Integration
The Abilities API landed in WordPress 6.9 on December 2, 2025 as a server-side registry. WordPress 7.0 extended it to the client. The change is structural: instead of every plugin shipping its own OpenAI, Anthropic, or Google integration (each with a settings page, key storage, rate limiting, and tool-calling plumbing), core now provides one canonical way to talk to AI providers. A plugin registers a capability with wp_register_ability() and an OpenAI-compatible JSON schema. The LLM discovers and calls those abilities as tools. It asks WordPress "what can I do here?" and gets back a tool catalogue.
The API has three moving parts. A PHP layer registers, manages, and executes abilities. Automatic REST exposure makes them callable over HTTP when a plugin opts in via meta.show_in_rest. New hooks let developers tap into registration, discovery, and execution. Each ability is a WP_Ability instance: a namespaced name (my-plugin/my-ability), human-readable label and description, JSON Schema input and output, a category, optional permission checks, and an execution callback. REST exposure is disabled by default. WordPress 7.1 added a single meta['public'] flag as a high-level signal that an ability is intended for external clients.
This is not a resource API. The WordPress REST API exposes /wp/v2/posts and /wc/v3/products: CRUD on data objects. An agent using those endpoints must be pre-programmed to know what each endpoint does, what parameters it accepts, and how to chain calls. WPGraphQL improves query flexibility but shares the same limitation: it describes data, not capabilities. The Abilities API describes what can be done — save a memory, search products, draft an email, publish a post — in a machine-readable contract the model can reason over at runtime.
The architectural pattern is discoverability plus execution plus permissioning in one surface. The key goals, per the Core AI team announcement, are discoverability, interoperability, security-first, and gradual adoption. A plugin registers an ability. An agent (running inside the admin, or externally via REST) queries the registry, validates the schema, and invokes the callback. The callback runs with the site's permissions. The plugin author decides what the ability does; core handles registration, discovery, validation, and dispatch.
This replaces the bolt-on model. Previously, a plugin wanting AI-powered features bundled its own provider SDK, stored its own API key, built its own prompt templates, and implemented its own tool calling. Multiple plugins meant multiple API keys, multiple rate-limit implementations, multiple places to rotate credentials, and incompatible tool interfaces. The Abilities API collapses that to one registry, one credential surface (handled by the separate Connector framework), and one tool protocol the model already speaks.
The Reddit thread from the 7.0 launch captures the shift: "No more re-entering API keys in five plugins. No more 'which plugin is burning my tokens?' No more provider lock-in." The SD AI Agent demo built for the release wrote zero provider integration code, zero API key management UI, and zero tool-calling plumbing. It registered abilities and let the model drive.
The pattern generalizes. A plugin can expose 50 SEO abilities with zero UI (an "ability bundle") and any compatible agent can use them. WordPress becomes an AI-orchestratable backend, not a CMS with an AI plugin bolted on. The same shift Slack made in 2016 with apps and Notion made in 2024 with MCP: platform with plugins becomes platform with an interop surface.
Core does not solve everything. The API supplies a contract but no MCP server, no agent-specific OAuth scopes, no rate limits, no audit system. Composition belongs to the caller; core provides registration, discovery, validation, and execution; it does not create a workflow planner from a custom depends_on field. There is no generic approval queue for destructive abilities; the domain application builds one if a refund or deletion needs human confirmation. There is no invoke_external_ability(); a plugin that calls an external service wraps that call in its own ability and owns credentials, timeouts, retries, cost controls, and response validation.
The engineering pattern is clear: standardize the interface between platform capabilities and reasoning engines. Push provider integration, key management, and tool protocol to the platform layer. Let plugins expose domain capabilities as schema-described functions. Let agents discover and compose at runtime. That pattern (registry, schema, discovery, execution, permissioning) ports to any platform that needs to make its functionality legible to an LLM without baking in a single vendor.
Three Groups, Three Different Ripples
The fragmented plugin ecosystem that defined WordPress AI for years is collapsing into a coherent layer; the ripple effects hit three distinct groups in different ways.
Plugin Authors: From Integration Burden to Feature Focus
For plugin developers, the calculus has inverted. Previously, a developer building an AI-powered feature faced three unsustainable options: write a custom API integration from scratch, depend on a third-party SDK of uncertain maintenance, or lock the plugin to a single provider and exclude users of others. Each path carried maintenance debt that compounded with every provider API change. The WordPress AI Client SDK introduces a fourth option: build against a unified interface and let the site owner's configured provider handle execution.
This shift is concrete. A plugin built on the SDK no longer manages credentials; core handles that. It doesn't break when OpenAI updates its API or Anthropic releases a new Claude model; the provider plugins absorb those changes. It works whether the site owner uses OpenAI, Anthropic, Google Gemini, or a community-built provider like Grok, OpenRouter, or Ollama. The Ollama provider is particularly significant: it enables AI features with zero external API costs and no data leaving the server, a requirement for regulated environments. Community developers have already shipped provider plugins for all three, registering with the same SDK interface, validating the design's openness without core blessing.
Early adopters gain a head start on the plugin ecosystem's inevitable acceleration; as infrastructure cost drops, more plugins will add AI capabilities, and those already on the SDK avoid a retrofit.
A plugin built on the SDK works regardless of which provider the site owner prefers. The plugin is not responsible for credential management. The plugin stays current with new models automatically. The plugin can gracefully handle missing provider configurations.
Site Owners: One Configuration, Everywhere
For non-developers running WordPress sites, the change is simpler but no less structural. Install one official provider plugin (Anthropic, Google, or OpenAI), enter an API key once (preferably as an environment variable or PHP constant, not in the database), and every SDK-compatible plugin on the site gains access to that provider's models. No per-plugin configuration. No duplicate credential entry across four different settings screens. No wondering which plugin stores keys where.
The choice of provider is reversible. Switch from OpenAI to Anthropic by deactivating one connector plugin and activating another; compatible plugins follow without reconfiguration. Cost control stays direct: API calls bill to the site owner's own key at the provider's standard rates, with no intermediary markup. Privacy follows the same logic: data goes to the configured provider under the site owner's agreement, not through a plugin vendor's proxy.
Connector Approvals, introduced in WordPress 6.9 and refined for 7.0, add an oversight layer for multi-user sites. Administrators can review and approve which provider credentials and AI capabilities are shared across the installation, a governance feature that matters when content teams, developers, and stakeholders all touch the same site.
Development Teams: Migration as Incremental Adoption
Teams maintaining existing plugins face a migration that rewards incrementalism over rewrites. The Interactivity API's signal change — effect replaced by watch from @preact/signals — is a regression-test trigger, not a search-and-replace task. Blocks using client-side state need runtime smoke tests after the import swap. Router and hydration behaviors shifted in Gutenberg 22.5 and 22.6; teams that pinned assumptions around those updates must re-validate navigation flows.
The higher-leverage change is DataViews/DataForm, a new canonical UI layer for data-heavy admin interfaces. It replaces the one-off React tables and forms that plugin teams have rebuilt repeatedly. The core team's guidance: pilot DataViews on one high-change admin surface first, add compatibility tests around sorting, filtering, and validation, then expand. Avoid full rewrites of stable legacy screens. Run CI matrices against both WordPress 6.9 and the latest 7.0 beta to catch forward-compatibility regressions early.
Both replace brittle DOM manipulation with structured extension points: filters for breadcrumb output across query-loop and custom post type contexts, hooks for overlay styling that align with design systems without forking the Navigation block.
The migration checklist the core team published is pragmatic: audit Interactivity API imports and run runtime tests; pilot DataViews on one admin surface with telemetry; test breadcrumb output across single, archive, CPT, and query-loop contexts; validate navigation overlay UX on mobile and keyboard-only paths; run CI on 6.9 and 7.0 beta. The strategy is incremental adoption plus targeted regression testing. Teams that treat it as a broad rewrite will ship late and break more.
The Debate Over WordPress's AI Approach
When WordPress announced native AI connector APIs for version 7.0, the developer community split into two camps almost overnight. One side celebrated it as the natural evolution of the world's most popular CMS. The other raised alarms about data privacy, runaway costs, and third-party plugins operating without guardrails. That fracture has only deepened since the May 20 launch.
The security camp moved first. Oliver Sild, founder of WordPress security company Patchstack, issued a public warning that the combination of WordPress 7.0's AI infrastructure and the platform's existing plugin vulnerability rate represents a new economic opportunity for attackers. "WordPress 7.0 combined with plugin vulnerabilities equals free AI tokens," Sild wrote on X. "There will be an absolute rush by hackers to steal API keys." His concern isn't theoretical. A November 2025 vulnerability (CVE-2025-11749) in the AI Engine WordPress plugin — used by over 100,000 sites — exposed bearer tokens used by AI agents through the WordPress REST API, allowing unauthenticated attackers to gain administrative access. Days after the 7.0 launch, WordPress core ticket Trac #65303 reported that the new AI integration setup form allows browsers to autofill Anthropic API keys in plain text; meaning anyone with access to an active browser session, a shared computer, or a screen share could see a key directly. Patchstack's 2026 State of WordPress Security report provides the backdrop: the median time to mass exploitation of high-impact WordPress vulnerabilities is five hours, and 46% of plugin vulnerabilities have no developer patch at the time of public disclosure.
The standardization camp sees a different picture. The 7.0 connector API centralizes what was fragmented: one dashboard to manage AI providers, one place to set data policies, one view of total usage across all plugins. A solo developer can add AI-powered features to their plugin with a few function calls instead of building custom integration code for every provider. Site owners choose which AI service handles their requests: the three default connectors ship with 7.0, with WordPress 7.1 slated to open the Connectors page to third-party providers in August. The built-in metering system addresses unpredictable costs, and the whole architecture is opt-in; no site is forced to enable AI.
That tension — standardization versus centralization — runs through every thread. Steve Jones of Equalize Digital suggested the platform may eventually need a more granular permissions model specifying which plugins and themes can access sensitive credentials or services. Matt Mullenweg, Automattic's CEO and WordPress co-founder, said he has personally run WordPress sites for over twenty years without incident and that properly maintained installations are secure. Both positions have merit. The Connectors UI masks stored API keys in the settings screen and REST API responses, but the WordPress options screen still shows them in plain text; encryption for database-stored keys is tracked at Trac #64789 and flagged as a future iteration. For production environments, the guidance is to load credentials through environment variables or PHP constants instead.
Vendor lock-in concerns cut both ways. The connector architecture is provider-agnostic in theory, but in practice the documentation and tooling heavily favor cloud providers. Local and self-hosted AI models remain second-class citizens. Critics argue the AI connector should make open-source models a prominent option, not an afterthought. Meanwhile, the "AI washing" problem looms: with AI capabilities now easy to add, a flood of "AI-powered" plugins will add features not because they're useful but because "AI" is a marketing keyword. Without robust review and enforcement, the WordPress.org plugin directory could become a minefield of plugins that nominally comply with AI data policies but practically cut corners. The default behavior for cost caps is soft enforcement; the plugin gets a warning, but the request still goes through. Community voices have pushed for hard limits: "if this plugin hits its AI budget, stop processing AI requests from this plugin."
Data privacy sits at the intersection of these debates. The connector API provides data routing controls, but what data a plugin sends to the AI service is ultimately up to the plugin developer. Critics argue every plugin that uses the AI connector API should be required to declare, in human-readable language: what data it sends to AI services, why it sends that data, whether the data includes personal information, and whether the user can opt out of AI processing for their data. If a WordPress site processes visitor data through AI, the site's visitors should be informed and given the opportunity to consent or opt out. WordPress.org should invest in comprehensive, non-technical documentation about AI connectors, and the project has discussed a certification program for AI providers that register as connector providers.
The Abilities API classifies registered functions as read-only or read/write, including write operations that can modify content, settings, or user data; auditing which installed plugins expose which abilities (and to what level of access) is a new piece of WordPress security hygiene. The community's verdict isn't settled. What's clear is that WordPress 7.0 forced a conversation the ecosystem had been avoiding: when AI becomes infrastructure, the platform owns the consequences of every plugin's choices. The decisions made in the 7.0 release cycle, about defaults, about enforcement, about education, will influence how millions of sites interact with AI services. The WordPress community has an opportunity to set the standard for responsible AI integration in content management systems. Whether it seizes that opportunity depends on which camp writes the next chapter.
Why Frontier Engineers Should Pay Attention
That same architectural split — reasoning layer here, action layer there, policy layer wrapping both — is the central problem in embedded AI, space avionics, defense edge compute, robotics fleets, and biotech sensor arrays. The CMS just shipped a working reference implementation first.
Research on embedded AI systems describes four layers that cascade into cost, reliability, and time-to-market: device runtime (model execution on constrained hardware), edge orchestration (local coordination, batching, queuing), connectivity and messaging (synchronization with cloud services), and cloud control plane (model registry, deployment orchestration, fleet monitoring, governance). WordPress 7.0 maps cleanly onto this stack. The AI Client handles device-runtime duties: routing prompts to OpenAI, Anthropic Claude, or Google Gemini through a single SDK. The Abilities API is the edge-orchestration layer: scoped tools, authenticated users, confirmation flows, evaluation hooks, audit trails, and safe-failure paths. Connector Approvals implement the governance layer, controlling which provider credentials and capabilities propagate across a site. The pattern is not metaphorical; it is structurally identical.
Frontier teams are solving this now under harder constraints. Synopsys reports that multi-agent workflows powered by AgentEngineer are already improving chip-design productivity 2×, with peaks of 5×, by orchestrating verification agents that read schematics, write regression scripts, and compare live edge data against digital twins. UST's iDEC platform cuts silicon-validation cycle times 50–70%, compressing four-day turnarounds to 48 hours through a closed-loop, agentic pipeline where Claude Code reads pinouts and flags signal-integrity faults. These are not chatbot wrappers; they are the same reasoning-versus-action separation, hardened for environments where a hallucinated netlist means a respin costing millions.
The defense edge makes the stakes explicit. Aitech's A230 Vortex GPGPU supercomputer runs near-real-time pattern-of-life analysis on military ground vehicles, optimizing the OODA loop in contested, disconnected environments. The system cannot phone home for inference; latency, privacy, and connectivity rules force the model onto the device. TinyML deployments on traffic controllers demonstrate the same discipline: 95.5% accuracy, 1-millisecond inference, 1.7 KB peak RAM, 15.2 KB flash. In-sensor and near-sensor computing architectures push compute into the sensing unit itself, cutting latency to 10⁻⁴ seconds and power to microwatts. Every one of these systems needs a governed boundary between what the model suggests and what the actuator does: exactly what the Abilities API formalizes for WordPress.
Cognitive lock-in is the strategic risk that unites these domains. BCG warns that organizations are becoming dependent not just on technology platforms but on AI reasoning processes that shape how they think and operate. The antidote is a governed enterprise intelligence layer that keeps proprietary knowledge, business rules, decision logic, and operational context under local control; while swapping model providers freely. WordPress's Connector Approvals implement this at CMS scale: site owners approve which connectors access which capabilities, and credentials never leak across boundaries. The same pattern appears in Kai Waehner's lock-in matrix and McKinsey's 2026 trust data: teams that standardize on an intermediate model format (ONNX) and a thin compatibility layer per hardware family avoid per-device engineering tax and retain the option to change providers.
Operational patterns converge too. The Inonx design guide for AI embedded systems lists the same countermeasures WordPress 7.0 bakes in: define safe-fail behaviors and offline operation from day one; mix on-device inference with cloud coordination (low-latency decisions local, long-term learning centralized); implement canary deployments and validation in the control plane before fleet rollout; build transactional update patterns with immediate rollback; correlate metrics across device health, edge queue depth, and cloud model version. WordPress's evaluation and audit hooks, confirmation gates, and scoped tool permissions are the web-native expression of these requirements.
It is to recognize that the architectural problem — integrating non-deterministic reasoning into deterministic, safety-critical, regulated platforms without surrendering governance to a model vendor — has a general solution shape.
Working in AI? Zero G Talent tracks the openings: see every open Databricks role, browse AI jobs, openings at Anthropic, and the people building the field.