Provider API keys stored by the WordPress AI plugin are moving toward encryption, and if you maintain a pile of client sites, that change deserves an afternoon before summer. The plugin’s release cadence is also slowing from bi-weekly to monthly, and both land in the weeks before WordPress 7.1 reaches Beta 1 on July 15. The team published the full weekly summary on make.wordpress.org, and the encryption section is the part I’d read twice.
A 1.0.1 maintenance release went out, and monthly milestones follow: 1.1.0 in late June, 1.2.0 in late July. An experimental pull request from @dkotter that encrypts keys programmatically was cleared to merge on purpose, so the team can gather real-world feedback fast. The stated fallback is to refactor or roll the code back into a dedicated encryptor class inside the plugin before the 7.1 core freeze.
What the team decided
Merging an experiment to learn from production is a different rhythm than core’s usual debate-then-freeze. The reasoning in the summary is that community feedback arrives much faster after a release than in a pull request thread, and nobody can meaningfully test key storage from a GitHub issue. I think that’s the right trade here. Plaintext keys in wp_options have been a complaint since the plugin appeared, and a reversible experiment that surfaces problems within a month beats a perfect design argued over for a quarter.
The dates around it matter too. The tentative 7.1 cycle targets Beta 1 on July 15 and the final release on August 19, during WordCamp US. Anything the AI team wants in core has to be finalized before that six-week window closes at Beta 1, which is why the encryption work is happening now rather than after 7.0 settles. If you skipped the 7.0 groundwork, what the 7.0 AI client changed for plugins is still the best primer.
How to check sites before the WordPress AI plugin encrypts keys
Start with versions and update settings
First, find out which sites run the plugin and at what version, because a monthly cadence means each update carries more change per event. If you disable auto-updates on client sites, which I usually do for anything touching payments or AI providers, you now choose when encryption arrives instead of WordPress choosing for you.
Find where the keys live
Second, inventory the options table. The plugin stores provider settings somewhere in wp_options, and the encryption change will rewrite how those values are stored and read. I don’t know the exact option names PR #560 touches without reading it, so treat the pull request as the source of truth. In the meantime, a broad search surfaces candidates:
wp plugin list --fields=name,version,status
wp option list --search='*api_key*' --fields=option_name,autoload
wp option list --search='ai_*' --fields=option_name,autoloadNote the autoload column. Keys that autoload get read on every request, and a migration that changes their format is the kind of thing you want to watch on staging rather than on a live store mid-sale. Remember this only covers the plugin’s own connector settings. Other AI tools on the same site keep their own keys, and those stay plaintext until their authors do the same work.
Run the update on staging first
Third, when 1.1.0 or 1.2.0 ships, update staging and test one provider call. Format migrations tend to fail in one of two quiet ways: the key reads back empty and the feature silently stops, or an object cache keeps serving the old value after the row changed. Both look like a broken feature from the outside and neither leaves a loud error. The simplest check I know is to run a generation from the editor after the update, then look at the provider’s usage dashboard to confirm the request landed.
The Connectors field registry matters for PHP-first shops
The quieter item in the same meeting may matter more over time. @andrei_lupu opened an issue in the Gutenberg repository proposing a declarative, server-side PHP registry so connector providers can register their own settings fields beyond the standard URL and API key inputs. That’s needed for self-hosted setups like Llama, where you configure a base URL, a model name and limits instead of pasting a vendor key.
The argument in the issue is one I’ve felt on client work: you can already inject custom layout through React components, but that drags a JavaScript build chain into what should be one PHP file. If the registry lands the way it’s described, adding a provider becomes a small declarative block you can review. The team is treating it as a forcing function toward standardized settings fields in 7.1, which would stop plugins from injecting unvalidated scripts into core interfaces. For store owners who want models running on their own hardware, this is the piece that makes self-hosted endpoints first-class.
The bottleneck is review, and it’s open
The summary is honest about the people problem: @flixos90 is stepping back and @jason_the_adams is stretched thin, so the PHP repositories are short on active maintainership. @jeffpaul’s answer is practical. Merging reviewed work deploys nothing until a release is tagged, so contributors should test and review pull requests aggressively, and he’ll help find a committer for validated community PRs. If you’ve been meaning to contribute, code review on those repos is the most useful hour you can spend there right now. The named gaps for 7.1 are streaming data support, sound generation, and native embeddings infrastructure.
One more detail worth knowing if you touch MCP tooling: the MCP adapter repository bumped its minimum requirement to WordPress 6.9, which drops older library dependencies and leans on the core Abilities API. If a client site still runs an older branch and you rely on MCP features, that’s your upgrade nudge.
What I’d put on the calendar
- Late June: AI plugin 1.1.0, first monthly milestone.
- July 15: WordPress 7.1 Beta 1, the deadline for AI work aiming at core.
- Late July: AI plugin 1.2.0, second milestone.
- August 19: WordPress 7.1 final, during WordCamp US.
Plan a staging pass a day or two after each plugin release, and read the notes, specifically the encryption PR’s status. As the 7.0 hotfix release showed, WordPress has been shipping fixes as plugin updates too, so this calendar is denser than the four lines above suggest.
If you’re unsure whether a client’s store is ready for the key format change, this is the kind of work I do: versions, storage, a staging pass, and a short written note on what to expect from each milestone. It’s a small job now and a support ticket later.
The question I still have is how the migration will run: lazily, re-encrypting a key the first time it’s read, or as a one-time routine when the plugin updates. It matters for stores with persistent object caches and for staging copies cloned from production, where half-migrated data could sit in the cache for days. That single detail decides whether updating on staging first is a good habit or a hard requirement.
