WordPress 7.0 is close, and the AI contributor team is polishing the last pieces of the WordPress 7.0 AI Integration. I’ve been following these meetings closely, and I want to talk about how the core-ai team is handling credentials. It’s messy. It’s also a mess we can work with, once you understand the architectural trade-offs being made right now.
The team is targeting May 19 for the AI Plugin 1.0.0 release, the stable companion for early adopters of 7.0. If you’ve been pasting API keys into ten different third-party plugins, this release is meant to end that with a central hub at Settings > Connectors.
Security and the Connector Approval “experiment”
One of the hardest questions on the WordPress 7.0 AI Integration roadmap has been how to stop a random plugin from grabbing your stored OpenAI or Anthropic keys. The answer shipping in V1 is a “Connector Approval” flow. It blocks plugin access by default until an admin manually approves that plugin.
Is that a bulletproof security layer? No. A malicious plugin can still reach into the database and pull credentials directly, because WordPress doesn’t have a real per-plugin sandbox yet. What it does add is “practical friction.” It draws a privacy boundary where site owners can see which features are burning tokens and which might be sending sensitive site data into an LLM’s training history.
I went deeper on the technical hurdles of this framework in my post on the WordPress 7.0 AI framework and the connector approval catch.
Enterprise logging: custom tables over post meta
I’ve seen too many sites grind to a halt because a dev logged high-velocity data, like API requests, into wp_postmeta or wp_options. So I’m glad the core team agreed on a custom database table for AI request logging. They’re also truncating context to keep the database from bloating, which is good news for anyone running WordPress at scale.
If you’re building a custom provider, don’t fall back to the old way. Use the new standard. Here’s the reasoning behind moving AI logs out of meta:
<?php
/**
* Logic for custom logging table creation in WP 7.0
* Using dbDelta ensures we don't nuk the table on every update.
*/
function bbioon_create_ai_log_table() {
global $wpdb;
$table_name = $wpdb->prefix . 'ai_request_logs';
$charset_collate = $wpdb->get_charset_collate();
$sql = "CREATE TABLE $table_name (
id bigint(20) NOT NULL AUTO_INCREMENT,
request_time datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
provider_id varchar(50) NOT NULL,
token_count int(11) DEFAULT 0,
is_cached tinyint(1) DEFAULT 0,
truncated_prompt text NOT NULL,
PRIMARY KEY (id),
KEY provider_id (provider_id)
) $charset_collate;";
require_once ABSPATH . 'wp-admin/includes/upgrade.php';
dbDelta( $sql );
}
This keeps your wp_postmeta clean and makes cost analysis (tracking cached vs. non-cached tokens for Anthropic, say) much faster to query. For the wider infrastructure changes, see how WordPress 7.0 AI infrastructure is killing custom glue code.
Versioning philosophy: the WordPress way
One last technical note: the team is dropping strict Semantic Versioning (SemVer) for the AI components in favor of “WordPress-style” versioning. Anything marked as an “Experiment” comes with no promise of future compatibility. If you’re building production-critical workflows on the Connector Approval PR, expect breaking changes as things settle in 7.1.
The WordPress 7.0 Field Guide is expected to land alongside RC4. Read it as soon as it’s out. If you find technical errors in the Connectors API implementation, the window to get them fixed is closing fast.
If this WordPress 7.0 AI Integration work is eating your dev hours, I can handle it for you. I’ve been wrestling with WordPress since the 4.x days.
My takeaway
Don’t wait for the final release to test your plugins against the new wp_ai_client_prompt(). The architecture is stable enough to develop against now. If you haven’t looked at the MCP Adapter or the new Abilities registration yet, you’ll be behind on release day, so get them onto a staging site and start testing.
