WordPress 6.9.1 just hit the servers yesterday, and while everyone is busy celebrating another successful maintenance release, my eyes are glued to the WordPress 7.0 Roadmap. If you are a developer still wrestling with the quirks of the block editor, you need to pay attention to what’s coming next, because the shift we’re seeing in Core right now is tectonic.
I’ve been doing this for over 14 years, and I’ve seen my share of “revolutionary” updates that ended up being just more bloat. However, the recent Dev Chat on February 4, 2026, revealed some architectural decisions that actually have me excited—and a bit cautious. Specifically, we’re looking at a formal proposal to merge the WP AI Client into Core and some serious performance work regarding client-side media.
The WP AI Client in the WordPress 7.0 Roadmap
The headline act of the WordPress 7.0 Roadmap is undoubtedly the WP AI Client merge proposal. This isn’t just a “helper” plugin; it’s an attempt to create a standardized foundation for AI interactions within the CMS. As I’ve argued before, the risk here is creating a fragmented ecosystem where every plugin brings its own LLM implementation.
Therefore, having a provider-agnostic layer in Core is a pragmatist’s dream. It means we could eventually swap out OpenAI for a local Ollama instance or an AWS Bedrock endpoint without refactoring every custom block we’ve built. Specifically, the discussion is currently hovering around the lack of a formal feedback timeline—something @jorbin noted—so if you have thoughts on how this Hook should behave, now is the time to jump into Trac ticket #64591.
VIPS and Worker Threads: The Performance Play
One of the most technical “war stories” I have involves a client site crashing because 10 editors decided to upload 4K images simultaneously, saturating the PHP-FPM pool. The WordPress 7.0 Roadmap addresses this via “Client-Side Media.”
The team just landed the wordpress/worker-threads package. This is a game-changer. It allows WordPress to run libvips—a low-memory image processing library—directly in a worker thread. Instead of the server doing the heavy lifting during the wp_handle_upload process, we can offload processing. Furthermore, this moves us closer to a world where image optimization happens before the bytes even hit your expensive 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: More Than Just Notes
Lastly, we need to talk about realtime coordination. We’ve seen “Notes” in 6.9, but the 7.0 vision is much broader. Think Google Docs-style collaboration within the Gutenberg editor. Consequently, this will likely require a robust implementation of WebSockets or a very sophisticated heartbeat polling mechanism. If your hosting environment is still stuck on legacy Apache configs without proxy support, you’re going to hit a bottleneck very soon.
Look, if this WordPress 7.0 Roadmap stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Senior Dev Takeaway
The transition to 7.0 isn’t just another version number. It’s the point where WordPress stops being a “blogging tool” and starts acting like a modern application framework. Between client-side processing and native AI, the barrier to entry for “simple” development is rising. Don’t get left behind debugging legacy PHP when the industry is moving to worker threads and LLM orchestration.
“},excerpt:{raw:
