Client-side media processing: Invalidate media after upload#76121
Open
andrewserong wants to merge 1 commit intotrunkfrom
Open
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. |
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