WordPress 7.0 is out. The marketing teams are celebrating a “landmark release,” but the people working under the hood know there’s more to it. The WordPress AI development architecture we’ve been following in the experimental plugin is finally landing in core trunk, and it’s having growing pains. I’ve seen major releases break site headers and wreck checkout flows, but building a native AI layer is a much bigger job.
This week’s AI contributor meeting fell on launch day. While everyone else looked at the new UI, the team was stabilizing version 1.0.0 of the companion plugin and arguing about the Abilities API. If you build products on top of 7.0, understand what “Abilities” is: a machine-readable map of what a WordPress site can actually do, and more than just one more API.
Refactoring for scale: the Abilities API bottleneck
One of the stories from the meeting is about Issue #21. The team is starting to plan for very large scale. The question is how to register, filter, and discover hundreds or even thousands of concurrent abilities without creating a database bottleneck.
In earlier versions we could maybe get away with “vibe checking” registration logic. In WordPress AI development, a “Find Ability” discovery workflow has to be fast. If every AI request kicks off a heavy discovery cycle, your server’s TTFB (Time to First Byte) will suffer. The current proposal is to organize discovery inside the companion plugin first, then move it to core trunk in 7.1.
Hook-based initialization vs. explicit registration
There’s also a refactor in PR #159 worth watching if you write plugins. Plugin experiments are moving away from explicit register() methods and toward standard init hooks. It sounds like a small “best practices” cleanup, but the point is to avoid race conditions when several plugins try to use the same AI primitives.
<?php
/**
* The "Naive" way we were doing it in early experiments.
* This often led to race conditions with other AI connectors.
*/
class Bbioon_AI_Old_Way {
public function register_feature() {
// Explicit call that might happen too late or too early.
$this->init_connector();
}
}
/**
* The "Senior" way: Moving to standard hook-based routines.
* This is the direction for WordPress 7.1.
*/
class Bbioon_AI_Standard_Way {
public function __construct() {
add_action( 'init', [ $this, 'bbioon_initialize_ai_primitive' ], 10 );
}
public function bbioon_initialize_ai_primitive() {
// Register abilities here when the environment is ready.
}
}
Secrets management and C2PA authenticity
Security is the big unresolved issue in WordPress AI development. We’ve all seen plugins keep API keys in plain text in the wp_options table. A new exploratory PR (#560) builds a dedicated Secrets Management API. It exposes get_secret and set_secret with no UI, and serves as a testing ground for 7.1.
There’s also a push for content provenance using the C2PA spec. WordPress 7.0 will do more than store AI-generated images in the media library: it will keep their manifest metadata. That way, when an image gets optimized, the standard attachment routines don’t quietly throw away the provenance trail. It adds load on the server, but media verification in 2026 depends on it.
If WordPress AI development work is eating your dev hours, I can take it off your plate. I’ve been wrestling with WordPress since the 4.x days.
What to watch in the 7.1 cycle
The 7.1 roadmap is already taking shape, and the focus is “streaming data support.” If you’ve built a chatbot and watched a user wait 10 seconds while the server assembled the full response, you know why. Native streaming is the feature 7.0 testers have asked for most. For more on how these tools are being built, see my notes on future-proofing AI features and on AI agents via MCP. The architecture is being decided now, so don’t wait for 7.1 to ship before you pay attention.
