WordPress 6.9.1 landed on servers yesterday. It is a maintenance release, so the more interesting reading is the WordPress 7.0 Roadmap. If you are still working around the quirks of the block editor, what is queued up next matters more than the patch you just applied.
After 14 years of this I have sat through plenty of “revolutionary” updates that turned out to be extra bloat. The Dev Chat on February 4, 2026 was not one of them. It surfaced architectural decisions I find genuinely interesting, plus one or two that make me cautious: a formal proposal to merge the WP AI Client into Core, and real performance work on client-side media.
The WP AI Client in the WordPress 7.0 roadmap
The main item on the WordPress 7.0 Roadmap is the WP AI Client merge proposal. It aims at a standardized foundation for AI interactions inside the CMS rather than another helper plugin. As I have argued before, the risk is an ecosystem where every plugin arrives with its own LLM implementation.
A provider-agnostic layer in Core is a pragmatist’s dream. It would let us swap OpenAI for a local Ollama instance or an AWS Bedrock endpoint without refactoring every custom block we have built. The open question in the discussion is the missing formal feedback timeline, which @jorbin pointed out, so if you have views on how this hook should behave, Trac ticket #64591 is where to put them.
VIPS and worker threads: the performance play
One of my better war stories involves a client site going down because ten editors uploaded 4K images at the same time and saturated the PHP-FPM pool. The WordPress 7.0 Roadmap answers that with “Client-Side Media”.
The team just landed the wordpress/worker-threads package, which lets WordPress run libvips, a low-memory image processing library, directly in a worker thread. Instead of the server carrying that load during wp_handle_upload, the processing moves off the request. It also puts image optimization ahead of the point where bytes start costing you cloud storage.
// A conceptual look at how we might check for worker thread support
// in the upcoming 7.0 environment.
function bbioon_check_media_worker_support() {
if ( current_theme_supports( 'client-side-media' ) ) {
// Log a transient to avoid race conditions during testing
set_transient( 'bbioon_vips_active', true, HOUR_IN_SECONDS );
return true;
}
return false;
}Realtime coordination and what it asks of your host
Notes arrived in 6.9, and the 7.0 plan reaches a lot further: Google Docs style collaboration inside the Gutenberg editor. That needs either a solid WebSockets implementation or a much smarter heartbeat polling mechanism. Hosting still stuck on legacy Apache configs without proxy support will hit that wall early.
If keeping pace with the 7.0 roadmap is eating your dev hours, I can take it on. I have been working with WordPress since the 4.x days.
What this means for your stack
7.0 is the release where WordPress stops behaving like a blogging tool and starts behaving like an application framework. Between client-side processing and native AI, the floor for what counts as simple development keeps rising. Worker threads and LLM orchestration are where the work is heading, and more legacy PHP debugging is not a plan for getting there.
