The February 4, 2026, WordPress Developers Chat agenda just dropped, and it confirms what I’ve been suspecting: we are moving toward a massive architectural shift. While WordPress 6.9.1 is out as a standard maintenance release, the real “meat” of the discussion is focused on the road to version 7.0. Specifically, the breakthrough in WordPress 7.0 Client-Side Media is finally moving from experimental territory into a testable core feature.
If you’ve ever dealt with a client on a cheap shared host whose site hangs every time they upload a 10MB JPEG, you know the bottleneck isn’t just the PHP memory_limit. It’s the server-side processing overhead of GD and ImageMagick. WordPress is finally addressing this by offloading the heavy lifting to the visitor’s browser using WebAssembly (WASM).
WASM, VIPS, and Worker Threads
Adam Silverstein provided a critical update on the Client-Side Media feature. The core team has landed the wordpress/worker-threads package, which is a game-changer. This package allows WordPress to run libvips—a high-performance image processing library—directly in a browser worker thread. Furthermore, because this runs in the background, it won’t lock up the UI thread while resizing thumbnails.
This isn’t just a “shiny new tool.” It’s a performance refactor that could reduce server-side CPU usage by over 80% during media uploads. However, as any senior dev will tell you, offloading to the client introduces a new race condition: we have to ensure the processed sub-sized images and metadata are synced correctly back to the server before the attachment is finalized. We’ve already seen a deep dive into these WordPress 7.0 developer features, and the complexity is real.
Implementing Client-Side Logic
While the internal API is still evolving, the logic revolves around the new @wordpress/upload-media package. Instead of the server receiving a giant original file and grinding to a halt creating five different sizes, the browser handles the transformation. Here is a conceptual look at how a developer might interact with this async processing flow:
/**
* Conceptual JS for Client-Side Media Processing
* Using the new worker-threads architecture.
*/
import { processImage } from '@wordpress/upload-media';
const handleFileUpload = async ( file ) => {
try {
// Offload resizing to a background worker thread
const subSizes = await processImage( file, {
widths: [ 150, 300, 1024 ],
format: 'webp'
} );
console.log( 'Client-side processing complete:', subSizes );
// Ship the processed blobs to the REST API
await bbioon_upload_to_wp( file, subSizes );
} catch ( error ) {
console.error( 'Processing bottleneck detected:', error );
}
};The AI Client and WP 7.0 Roadmap
Another major point for discussion is the proposal from Felix Arntz to merge the WP AI Client into Core 7.0. This aligns with the broader goal of building an AI infrastructure directly into the ecosystem. If you haven’t kept up, I previously wrote about the WP AI Client roadmap and why it’s critical for future-proofing your plugins.
Specifically, the 7.0 Release Squad is already focusing on bug scrubs to ensure that these massive merges don’t break legacy sites. It’s a messy process, but having a dedicated squad for a milestone release this early is a good sign for stability. For those interested in the technical minutiae, the official tracking issue on GitHub is where the real work happens.
Look, if this WordPress 7.0 Client-Side Media stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway for Developers
WordPress 7.0 is shaping up to be more of a platform shift than a simple update. Between WordPress 7.0 Client-Side Media offloading processing to WASM and the potential AI Client merge, the “Core” is becoming leaner on the server and smarter on the front end. Consequently, if you aren’t testing these features now, you’ll be debugging them in production come release day. Check out the Pascal Birchler post for a deeper dive into the VIPS implementation.
