WordPress 7.0 AI shipped as plumbing: an AI Client bundled in core, a Connectors API, and a Settings > Connectors screen where you manage provider keys. There is no assistant in core and no button that writes your posts. The WordPress.com announcement covers the release well on the editor and design side, but if you build or maintain self-hosted sites, the part that matters to you is the plumbing.
First, the thing site owners ask about: it is opt-in. Nothing is sent to any provider until someone installs a provider plugin and adds a key. A fresh 7.0 install is exactly as free of AI traffic as the site was before the upgrade.
What WordPress 7.0 AI shipped
Three things landed. The AI Client is a provider-agnostic PHP SDK that core now bundles, so a plugin can send a prompt and get a normalized response back without knowing or caring whether Anthropic, OpenAI or Google answered. The Connectors API registers providers and handles their credentials. The Connectors screen is the admin UI where a site owner installs a provider plugin, pastes a key, and sees which connection is live. The launch providers are Claude, ChatGPT and Gemini, each shipped as its own plugin on the directory.
For plugin authors, the payoff is that you stop handling credentials entirely. Your plugin sends prompts through the client, and the site owner decides which provider answers and pays for it. When no provider is configured, a call comes back as a WP_Error rather than failing silently, and that is the case you build against from the start. The visible features people associate with the release, like title and excerpt generation, live in the separate AI plugin from the WordPress project rather than in core.
That is the good part. Where people go wrong is key storage.
The wrong move is treating Settings > Connectors like every other settings page: paste a production key into the form, save, move on. It works, but the key lands in the database under a connectors_..._api_key option. The Connectors API dev note is blunt about this: keys stored in the database are masked in the UI but not encrypted at rest, and encryption is still an open follow-up ticket. Masked in the UI means the value sits in the options table, readable by anything that can read options, which on a typical store is more code than you would like.
WordPress resolves a key in a fixed order: an environment variable first, then a PHP constant, then the database. On production, use one of the first two.
<?php
// wp-config.php, before the "That's all, stop editing" line.
// Keys resolve in this order: env var, constant, database.
define( 'ANTHROPIC_API_KEY', 'sk-ant-your-key-here' );The Connectors screen shows which source a key came from, so you can tell at a glance whether a site is running on the constant you set or on a key someone pasted into the UI during a demo. I would make that check part of the routine pass on any site where AI features are switched on.
One developer detail: the JavaScript prompt API that accompanies all this is not in core. Per the AI Client dev note, it ships separately, allows arbitrary prompt execution from the browser, and needs a high-privilege capability that defaults to administrators only. That default is sensible, so keep it that way.
Before you turn it on for a client store
A short checklist, in the order I would do it:
- Decide where keys live before you add the first one. Environment variable if the host supports it, constant if not, database on staging only.
- Set a spend limit in the provider dashboard before adding the key. Plugins that use the client spend the site owner’s tokens, and the plugin author never sees that bill.
- Check who can reach Settings > Connectors. It follows admin capabilities, but confirm which of your client’s editors hold admin, because the JS API above runs with that same trust.
- Test on staging with a throwaway key, then issue a fresh one for production. A key that has lived in a staging database has no business being the production key.
Also expect existing plugins to start adopting the client once a key exists on a site. A plugin that quietly sends prompts in the background is spending tokens you only approved indirectly, so the usage dashboard matters as much as the feature list. I wrote about the AI client when it first appeared in the 7.0 betas, and the rollout since then has already needed a hotfix delivered through plugin updates. AI features add a second moving part on top of that.
If you are weighing this for a store or a client site and want a hand deciding what to enable, where keys should sit on your host, or which plugins are safe to let near the client, that is work I do.
Do not enable AI on a busy production store the week after upgrading. Bring up a copy, add one provider, run the normal editing flow, then look at the provider’s usage dashboard. If the number matches what you expected, the plumbing behaves. If it does not, you want to learn that on staging.
