There is an architectural shift going on in WordPress AI Plugin Development that deserves more attention than it is getting. If you have been reading the contributor meeting notes, you have seen it: the MCP (Model Context Protocol) client is being pulled out of a Composer package and turned into a normal WordPress plugin.
I have watched this play out a dozen times on legacy codebases. You reach for Composer because it feels like the modern choice, and in the WordPress ecosystem you land in dependency hell. Two plugins require different versions of the same library and the site goes down. That is why the team is converting the MCP client into a standard plugin, to keep those version conflicts and race conditions out of the picture.
Refactoring the Abilities API and exception handling
The Abilities API is getting one of the more important fixes in the pipeline. Trac #65058 covers catching exceptions thrown by ability callbacks. Anyone building custom AI tools already knows how unpredictable LLM responses are, and an unhandled exception bubbling up out of a callback gets you a white screen of death.
Here is a stripped down version of how core should be handling these callbacks during WordPress AI Plugin Development:
<?php
/**
* Naive approach vs. Robust Exception Handling
*/
// The "Dangerous" way
function bbioon_risky_ability_callback( $args ) {
$data = some_external_api_call( $args['id'] );
return $data->result; // If API fails, this throws a notice/error.
}
// The "Standardized" way proposed for the Abilities API
function bbioon_safe_ability_callback( $args ) {
try {
$data = some_external_api_call( $args['id'] );
if ( ! $data ) {
throw new Exception( 'External API returned no data.' );
}
return $data->result;
} catch ( Exception $e ) {
// WordPress should catch this and log it without killing the process
error_log( 'AI Ability Error: ' . $e->getMessage() );
return new WP_Error( 'ability_failed', $e->getMessage() );
}
}Connectors and the DISALLOW_FILE_MODS gotcha
Weston Ruter flagged a real bottleneck on sites with read-only file systems. Set DISALLOW_FILE_MODS to true and the current Connectors screen can lock users out completely, which matters because that setting is standard on enterprise hosting. The fix in progress preloads REST API responses so the UI still works when the filesystem is closed.
If you are testing any of this, my WordPress AI Connector Plugins testing guide has more on the 7.0 roadmap.
Block recognition strategy for AI agents
Turning raw HTML into structured Gutenberg blocks is one of the things AI keeps getting wrong. The proposal is to expose block metadata through the REST API or WP-CLI, so the model reads a dictionary generated from the source code instead of guessing from documentation.
That beats leaning on regex or brittle HTML parsing. Hand an agent a JSON schema of block attributes and the generated content gets noticeably more accurate. My WordPress 7.0 AI Client overview covers how this fits with the rest of core.
If this WordPress AI plugin development work is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days.
What this means for your builds
AI 0.8.0 is a stabilization release, not a feature release. The direction is standardized APIs like Connectors and Abilities, and away from Composer for anything core depends on. For developers and site owners that means fewer surprises. If you need tight control over where AI features show up on your site, watch the LLM off-switch ticket.
