Gutenberg 23.4 Lands Resilient Media Uploads

The most expensive image upload I have ever seen was not the largest file. It was a 12 MB JPEG that failed on the third floor of a London office, three minutes before a press embargo lifted. The author hit publish, the upload timed out, the browser threw a generic error, and we lost the featured image on the lead post of a launch we had spent eight weeks preparing. Twenty years in, that pattern has not really changed: an unreliable WiFi cell, a draft in flight, no retry, no breadcrumbs.

This week’s Gutenberg 23.4 quietly does something about it. Not with a marketing headline, not with a new AI button — with the part of the editor most users never see until it fails. The upload queue now pauses when the network drops, resumes when it returns, retries with exponential backoff, and refuses to push very large images through the client-side processing pipeline that would otherwise lock up a tab. That is the kind of fix that earns trust, slowly, with editors who have been burned.

I am writing this from the agency seat, not the contributor seat. So the question I care about is the practical one: which of these changes can I rely on in production this week, which ones do I still need to keep an eye on, and where does the editor experience genuinely improve for the kind of newsrooms and shops we run.

What is actually new

Gutenberg 23.4 shipped on June 17, 2026, summarized by ramonopoly on Make/Core in the What’s new in Gutenberg 23.4 post. The release sits squarely inside the Client Side Media iteration for WordPress 7.1 tracking issue, which is currently at 23 of 33 tasks completed and explicitly targets resilient uploading, HEIC support, Ultra HDR preservation, and concurrent-upload performance.

The headline media change is “Upload Media: Add retry with exponential backoff and network resilience,” which lands as PR #76765 in the changelog. In plain terms: the upload queue now distinguishes between a server-side failure and a network-layer drop, holds the queue when the device goes offline, and resumes when connectivity returns instead of asking the author to re-pick the file. Failed transfers are retried with growing back-off intervals, so you stop hammering a flaky cell with the same 8 MB JPEG every two seconds.

The companion change is “Gate very large images out of client-side processing.” Since WordPress 7.0 graduated client-side image compression to core using WebAssembly and wasm-vips, the editor has been resizing images in the browser before sending them up. That is great until a phone hands you a 60 MP HEIC and the tab freezes. Gutenberg 23.4 puts a ceiling on what the WASM pipeline will try to chew through, and falls back to server-side processing above that ceiling. Upload-progress snackbars now also show batch counts, so an author dropping in twelve photos can see how many are done and how many are queued behind a stuck file.

Underneath all of that there is the real-time collaboration thread, which matters for the WordPress 7.1 cycle in a way that is easy to miss. After RTC was pulled from 7.0, Gutenberg 23.4 lands a separate document persistence endpoint (PR #78891), forces the collaborators overlay to re-render when the block tree changes (PR #78636), prevents slower polling filters from starving the connection (PR #78811), and fixes the CRDT typing race and the Yjs undo manager. The Hosting team’s call to test RTC with real customers runs until WordPress 7.1 Beta 1 on July 15, and these are the patches that need eyes on a live host.

One more thing that will surface for plugin authors: React 19 is back behind an experimental flag in this release. After Gutenberg temporarily reverted the React 19 upgrade earlier in June, 23.4 lets you opt in via /wp-admin/admin.php?page=experiments-wp-admin so you can validate your block code against the new runtime before it ships as default in 7.1.

Why it matters for WordPress and WooCommerce people

If you run a content-heavy site — a newsroom, a magazine, a course platform — the upload queue is part of your editorial workflow whether you think about it or not. Authors drop files in batches. They work on shared WiFi at events, on trains, on hotel networks. Every retry, every “are you sure you want to leave this page” prompt, every featured image that quietly never saved, costs you trust with the editors who are supposed to love your CMS. Network-resilient uploads are the unglamorous compound interest of editor experience.

For WooCommerce store owners the same change has a different shape. Product photography uploads run in batches of dozens, often from a phone walking around a warehouse. The author behind the catalog is rarely a developer. A queue that survives a dropped 4G handover and tells you which of fifteen images is still pending is the difference between a usable Friday afternoon and a re-do. The large-image gate is also important here: phones routinely produce 50+ megapixel files now, and trying to client-side resize them all has been a real cause of browser tabs going unresponsive in catalog work.

For agencies running multisite or hosted platforms, the gating decision is the one to plan around. Once a very large image is pushed to server-side processing, the load lands on PHP and Imagick (or, increasingly, on the proposed libvips image editor backend). That is fine if your hosting tier has the headroom. If you are running on lean shared hosting with a strict memory_limit, this is the moment to check that fallback path will not start failing silently on big DSLR uploads.

What I would do (or not do) about it

I would install the Gutenberg plugin on a staging environment this week and put it in front of the two or three editors on your team who upload the most. Watch what happens when they drop a folder of phone photos and then close the laptop lid. That is the test that matters. The bug you find will not be a bug — it will be a workflow expectation you and the editor never made explicit.

I would not enable the React 19 experimental flag on a production site. The whole point of the flag is that core wants third-party block authors to validate before it becomes the default in 7.1. If you maintain a block library, do that validation now and file issues — that is the most useful thing a plugin author can do this month. Production sites should wait.

If you have a real editorial team, I would also seriously look at the Hosting team’s call to test RTC. The 23.4 patches are exactly the kind of network-layer fixes that need exposure to messy real-world conditions before Beta 1 on July 15. Joining the outreach effort costs you very little and gives you early visibility into the feature your team will eventually be asked about anyway.

The one thing I would not do is over-promise to clients on the strength of a Gutenberg point release. 23.4 is a confidence-building release, not a feature-flag launch. Communicate it as “the editor handles flaky networks better now” rather than as a transformation. The transformation is the cumulative direction of WordPress 7.1, and it is showing up exactly where it should — in the parts most users only notice when they break.

Twenty years in, the boring fixes still win the trust battle. Resilient media uploads are exactly the boring fix we needed.