DesignSetGo apps
How it works Examples Docs Pricing Blog WP Blocks Install free

Blog /

WordPress 7.0 changed what a plugin can be

By Nealey

WordPress 7.0 shipped on May 20, 2026. Most of the release notes coverage focused on Site Editor improvements and the usual block-editor refinements. The actually load-bearing changes were three APIs that, taken together, rewrite what a WordPress plugin is allowed to assume. I want to walk through them, because the plugin I run is built entirely on top of them, and because I think the implications are still under-priced.

In particular, plugin authors who built BYOK-through-proxy AI features in 2024 and 2025 are about to discover that the architectural floor underneath their pricing model just moved. That’s the part I keep wanting to write about.

The three APIs

Connectors API. Site admins go to Settings → Connectors once, paste in their Anthropic, OpenAI, or Google credentials, pick a default provider, and they’re done. Every plugin that wants to call an LLM inherits that configuration. The plugin author no longer collects keys, no longer stores keys, no longer has to defend a key-storage UI in a security review, because there is no key to store. Structurally, this is the same trick WordPress pulled with wp_mail a decade ago: WordPress Core handles the boring delivery question, and plugins just call.

WP AI Client. A provider-agnostic PHP API for invoking a model. You write wp_ai_client_prompt('summarize this paragraph: …') and the configured Connector picks the provider, formats the request, handles retries, returns the result. Plugin code stops being coupled to any one vendor’s SDK. If a site admin switches their Connector from Anthropic to OpenAI on a Tuesday, every plugin’s AI features keep working on Wednesday with no code change.

Abilities API. The server-side half landed in WP 6.9 (November 2025). The client-side JavaScript half landed in 7.0. An ability is a registered function the site’s AI agent can call, with a typed input schema, a typed output schema, and explicit annotations about whether the call is read-only, idempotent, or destructive. Yoast SEO Premium 27.5 (April 2026) was already shipping abilities like analyze_page_seo, suggest_internal_links, and score_keyword_density before 7.0 even cut. Plugins are no longer just things users click around in. They are surfaces an agent can talk to.

Each one of those three is a noticeable change on its own. The interaction between them is what matters.

What gets removed from the plugin author’s job

If you were building an “AI WordPress plugin” anytime in 2024-2025, you spent a depressing amount of engineering time on questions that had nothing to do with your actual product:

  • Where do we put the API key field? Should we hash it at rest? What if the site is multisite? What if the customer rotates the key without telling us?
  • Which providers do we support? If we ship Anthropic-only, half the audience walks because they prefer GPT. If we add OpenAI, that’s a second SDK to maintain, and a third when Gemini gets popular.
  • How do we charge for inference? Pass-through markup? Subscription with credits? Tokens are unpredictable; nobody likes a metered bill that varies 4x month to month.
  • What’s our support story when a customer’s quota runs out at 11pm on a Friday and their site’s AI features start failing in production?
  • Are we, technically, reselling Anthropic API access? Have we read the commercial terms recently?

Connectors plus WP AI Client deletes that whole list. The site owner brings the keys and the budget. The plugin brings the prompt engineering and the UX. The plugin author never sees the bill, never holds the key, never has the awkward terms-of-service conversation with the upstream provider.

This is the part the industry hasn’t fully metabolized yet. Plugins that built BYOK-through-proxy infrastructure (the user gives you their key, you proxy the request, you keep usage metadata, you charge a subscription that wraps the inference cost plus margin) wrote a lot of code that WordPress Core now does for free. Worse: they kept liability the platform now handles. The architectural justification for the proxy is gone; the only reason to keep it is the subscription revenue it generates, which is exposed as exactly what it always was: a commercial markup on resold API access in a way the upstream commercial terms arguably forbid.

I don’t know when, or whether, Anthropic and OpenAI will tighten enforcement on that. I do know that “the upstream provider could decide our entire revenue model violates their ToS” is a structurally bad place to be, and the architecture that puts you there got cheaper to avoid the day Connectors shipped.

What gets added

Abilities are the more interesting half, because they’re net-new capability rather than removed work.

Before WP 6.9, “AI in WordPress” meant a chat box in wp-admin or a button on the post editor that called a model. The plugin owned the surface. The user typed at the plugin. If the site had three “AI plugins” installed, the user had three different chat boxes that didn’t talk to each other.

After Abilities, the user types at the site and the site’s agent figures out which plugin (or plugins) to call. Yoast registered SEO abilities. WooCommerce is registering commerce abilities. A weather plugin can register weather abilities. The user asks “which of my posts need internal-link improvements” and the agent pulls Yoast’s suggest_internal_links. The user asks “show me the orders that need fulfillment from this week” and the agent pulls Woo’s list_pending_orders. The user asks “draft a follow-up email to Tuesday’s leads” and the agent composes Yoast plus Woo plus a transactional email plugin in one move, without the user knowing that’s what happened.

Plugins stop being destinations. They become verbs.

If you ship a plugin, that is the surface to be on. The marketing site is fine, the plugin directory listing is fine, but the long-run discovery and stickiness now lives in being the thing the site’s agent reaches for when it needs to do X. Search-based discovery is going to matter less every quarter. Agent-based discovery is going to matter more.

What this implies for our pricing model

DesignSetGo Apps is built on this whole stack. We do not collect API keys. We do not pay for inference. The harness we charge for (system prompts, tools, validators, autofix loop, critic, registry) is pure orchestration over the WP AI Client surface. When we tell a customer that their app’s AI features will keep working when they swap Connectors, that’s not a feature we wrote, it’s a property of the platform.

Plugins that haven’t moved to this architecture are still operating on the old assumptions. Some of them have signed Anthropic commercial agreements that scale poorly. Some of them are reselling API access in ways that didn’t matter when there was no platform alternative and start mattering as soon as there is. Some of them are absorbing inference cost on free-tier users in a way that breaks at any reasonable scale. None of those are sustainable when the user has a Connector configured natively and a competing plugin uses it.

I’d love to say I planned this. I didn’t, exactly. I started building DSGo a year before 7.0 was finalized, hedged on AI features for most of that year, and waited to see which way Core was going to swing. When Connectors landed in trunk and the dev note went up, the path got obvious. The earliest version of our AI bridge predates wp_ai_client_prompt by about three months and is approximately a worse, custom version of the same idea; we ripped it out and replaced it with the Core call as soon as that was usable.

What to do if you ship a WordPress plugin

A short, opinionated list:

  1. If your plugin calls an LLM, route through wp_ai_client_prompt and require WP 7.0. Drop your bespoke key-storage UI in the same release. Tell users they configure providers at Settings → Connectors. The transition is a couple of weekends, not a quarter, and the alternative is being structurally worse than your competition forever.
  2. Pick one user-facing capability your plugin owns and register it as an ability. Even one. The point is to be on the surface when the site’s agent starts looking around for tools to call. The first two abilities are the hardest because the model is unfamiliar; the tenth is a five-minute commit.
  3. Write input and output schemas like you mean it. The agent picks tools based on signatures and descriptions. A vague description is the new SEO miss. “Returns information about the user” is the kind of thing the agent skips over; “Returns the current logged-in user’s display name, email, role, and registered capabilities” is the kind of thing the agent reaches for.
  4. If your plugin’s value is “we figured out how to call OpenAI for you,” your moat just evaporated. Find the next layer up. Vertical specialization, prompt engineering, validation, integration with other plugins via Abilities. Pick something that’s not in WP Core’s job description.

I’d add a fifth, more general one: read the dev notes. WordPress’s release process is unusually generous with explanation. The Connectors and AI Client dev notes spend pages on the second-order effects, and most plugin authors don’t read them carefully because they’re long and the immediate “what do I have to change in my code” is short. The second-order effects are where the strategy lives.

Where to read the primary sources

Nealey

Keep reading

More from the blog.