Client-side media processing: Invalidate media after upload#76121
Closed
andrewserong wants to merge 1 commit intotrunkfrom
Closed
Client-side media processing: Invalidate media after upload#76121andrewserong wants to merge 1 commit intotrunkfrom
andrewserong wants to merge 1 commit intotrunkfrom
Conversation
…mage block has fresh data on the media item
andrewserong
requested review from
aaronrobertshaw,
adamsilverstein,
ramonjd,
swissspidy,
talldan and
tellthemachines
andrewserong
added
[Type] Bug
|
Size Change: +158 B (0%) Total Size: 6.87 MB
ℹ️ View Unchanged
|
andrewserong
added
the
Backport to WP 7.0 Beta/RC
This was referenced Mar 4, 2026
github-project-automation
bot
moved this to 🔎 Needs Review
in WordPress 7.0 Editor Tasks
Member
|
Invalidation should happen in onSuccess callbacks as part of the media upload queue, not in a separate hook somewhere else. See swissspidy/media-experiments#971 for some context |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Contributor
I'm curious - what makes it not applicable? In my testing the invalidation there is still called. The files must be uploaded to the server somehow. |
Contributor
Author
Oh, I might have missed something here, but in my testing, the invalidation wasn't being called when the final upload success happens, so it feels like the
Yes, this does seem like the better way to go about it. I'll take another look into this, but yesterday I wasn't able to get it working, it feels like we might be missing an In any case, thank you both for the feedback! I'll do some more digging. |
Contributor
|
The original mediaUpload is called here: gutenberg/packages/upload-media/src/store/private-actions.ts Lines 778 to 797 in 3d919e0 So that's how the existing invaldiation is triggered, but I guess that doesn't do what it's supposed to? It seems to gets called once per uploaded file. I have trouble reproducing the issue tbh, so maybe I'm doing something wrong. |
Contributor
Author
Which browser are you testing with? If you can't see the bug, I'm suspecting that client-side media processing isn't running in your env. Currently only Chrome works with client-side media processing. One way to test, is when you upload an image, look in the network tab to see if there are requests to the
This is a tricky one, but there is a gap somewhere here. I'll try out an alternative, but I think any fix is going to be a little awkward given how everything's wired up. I'm still digging and looking into an alternative, but I think this is the issue:
Anyhoo, I mostly wanted to jot down those notes before I break for lunch. I'll give this another try after lunch — I think I can get something working by plumbing down an And apologies if none of the above made sense, my understanding here is a little flimsy 😄 |
Contributor
In Chrome. I can see that there are calls to |
Contributor
Would |
Contributor
|
Here's a screen recording of my attempt to repro: Kapture.2026-03-05.at.10.44.05.mp4 |
Contributor
Author
|
Thanks for testing! What happens @talldan when you go to the settings tab? Do you see the dropdown of image sizes? That's the main thing to tell whether or not the bug is present. |
Contributor
No I don't see it, so I guess I can repro. 👍 That's pretty subtle! |
Contributor
Author
Yeah, for many cases this'll be a fairly subtle bug (probably why we didn't catch it sooner!). The real time you notice it is if you're creating a hero-like full width image to span the whole viewport. With this bug, it's effectively treating the large (1024px) size as the real size of the image block, so it appears to be low-res with no way to change it to full size until you reload the page. I'd say that for lots of use cases it might not be that noticeable, but for folks creating image heavy posts or portfolio pages it'll probably be more obvious. In any case, I'll keep digging in! I might try opening an alternative PR to this branch, but I'll see how I go. |
talldan
approved these changes
Mar 5, 2026
Contributor
There was a problem hiding this comment.
The fix works well. With Beta 3 looming it might be pragmatic to merge the fix for users and then refactor the code to a different solution in a follow-up.
I'll mention Core data: improve handling of media/attachment entities. I think media REST API calls should ideally be handled in core data with invalidation built-in. I'm not entirely sure how client side media changes the picture though.
Contributor
Author
Thank you! I've just whipped up an alternative in #76173 if you get a chance to look at that as an alternative: I don't mind at all merging this one in and following up with #76173 (or alternatives) quickly, so that we can get a fix in for Beta 3. I'll leave this open for an hour just in case there's feedback we should go with the alternative, otherwise I'll look to merge this in 🙂 |
Member
|
That new PR definitely looks better to me, though not sure about the mediaUploadOnSuccessKey part. Feels odd having to add a separate key for that. |
Contributor
Author
It is a bit odd, but we don't (yet) have a better way to plumb it down. With that key private, it'll be safe to remove in follow-ups, though. Right now my aim is to land #76173 instead of this one. I'm just waiting for #76124 to be merged first (once performance tests finish), then I'll give it a rebase. |
Contributor
Author
|
Closing in favour of #76173. Thanks again for all the discussion and testing, folks! |
github-project-automation
bot
moved this from 🔎 Needs Review
to ✅ Done
in WordPress 7.0 Editor Tasks
andrewserong
removed
the
Backport to WP 7.0 Beta/RC
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Part of:
When the client-side media processing feature is active, invalidate media items in the core data store, so that their data can be freshly fetched.
This fixes a bug where if you upload an image to an image block to the post editor on trunk, the block editor thinks it's an external image until you reload the editor.
Why?
While testing the client-side media processing feature, I noticed that in the post editors if I go to upload to an image block directly, that after upload, the block thinks the image is an external image and not a real image uploaded to the site. This appears to be because now that sub-sized images are generated on the client (#74566) the image block will update prematurely with an
idbefore it has access to all the different size and media_details information.In the existing logic for server-side media processing, we invalidate the cache here, however that approach isn't applicable for the client-side media processing feature — in this case, we have a store that keeps track of the items in progress, and so we need a different approach to invalidate when items are emptied out of the queue.
Similar to how we have a
useUploadSaveLock()hook for watching the upload media store in the editor package to handle watching for unlocking / locking the post, this PR attempts a similar approach for invalidating the cache of uploaded items.How?
useInvalidateMediaAfterUpload()hook that effectively only does anything if the client side media processing feature is activeTesting Instructions
On trunk while running Chrome (so the client-side media processing is active):
With this PR applied
Screenshots or screencast
Before
2026-03-04.15.28.23.mp4
After
2026-03-04.15.27.19.mp4