The February 4, 2026 WordPress Developers Chat agenda is out, and it lines up with what I have been expecting: a large architectural change is on the way. WordPress 6.9.1 shipped as a routine maintenance release, so most of the agenda is about the road to 7.0. The part worth reading twice is WordPress 7.0 Client-Side Media, which has moved out of experimental territory and into a testable core feature.
If you have ever had a client on cheap shared hosting whose site stalls every time they upload a 10MB JPEG, you know PHP’s memory_limit is only half the story. The other half is the processing overhead of GD and ImageMagick on the server. WordPress is pushing that work out to the visitor’s browser with WebAssembly (WASM).
WASM, VIPS and worker threads
Adam Silverstein gave the update on Client-Side Media. The core team has landed the wordpress/worker-threads package, which is the piece that makes the rest possible. With it, WordPress can run libvips, a fast image processing library, inside a browser worker thread. Because that runs in the background, resizing thumbnails no longer freezes the UI thread.
This is a performance refactor, and it could cut server CPU during media uploads by more than 80%. Offloading to the client also buys you a new race condition to worry about: the processed sub-sized images and their metadata have to land back on the server before the attachment is finalized. I went through the rest of the WordPress 7.0 developer features earlier, and none of this is simple.
Implementing client-side logic
The internal API is still moving, but the logic sits on the new @wordpress/upload-media package. Rather than the server taking a giant original and grinding through five sizes, the browser does the transformation. Roughly how the async flow looks from a developer’s side:
/**
* 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 the 7.0 roadmap
The other big item is Felix Arntz’s proposal to merge the WP AI Client into core for 7.0, which would put AI infrastructure in WordPress itself rather than in a plugin layer. I covered the WP AI Client roadmap before, and why plugin authors should care.
The 7.0 Release Squad has already started bug scrubs so these merges do not break older sites. Scrubs are tedious work, but a dedicated squad this early in a milestone release is a decent sign for stability. The tracking issue on GitHub has the detail if you want it.
If this WordPress 7.0 Client-Side Media stuff is eating your dev hours, I can take it off your hands. I have been wrestling with WordPress since the 4.x days.
Where this leaves developers
WordPress 7.0 looks less like an update and more like a change of platform. With WordPress 7.0 Client-Side Media handing image processing to WASM, and the AI Client possibly merging too, core gets lighter on the server and heavier in the browser. Test these features now or debug them in production on release day. Pascal Birchler’s post on client-side media processing goes deeper on the VIPS side.
