Media: Invalidate entities when new media is uploaded #70405
Merged
Conversation
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
|
Size Change: +114 B (+0.01%) Total Size: 1.85 MB
ℹ️ View Unchanged
|
|
Oh, there's one other case that I forgot about, which is the media modal in the editor. You can upload via there and it also doesn't invalidate entities. I've pushed a commit to fix this. There's not much to hook into, so I've made it so that whenever the media modal is closed the cache is invalidated. |
|
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. |
|
(failing e2e tests are from a WordPress core change - convo here) |
ramonjd
approved these changes
Jun 15, 2025
44ca1e7 to
0ec6ebe
Compare
|
I rebased. An e2e fix was merged overnight. |
| originalOnClose?.( ...onCloseArgs ); | ||
| }; | ||
| return <MediaUpload onClose={ onClose } { ...rest } />; | ||
| } | ||
|
|
There was a problem hiding this comment.
Would we ever want to use MediaUpload without the cache invalidation? Wondering if it could be added directly to the MediaUpload component instead of in this wrapper. Or do we want to avoid media-utils having a core-data dependency?
There was a problem hiding this comment.
I think the test is that packages that don't depend on a server or WordPress backend like the block editor.
The media utils package README however, says the following:
This package is meant to be used by the WordPress core. It may not work as expected outside WordPress usages.
So might be kosher?
There was a problem hiding this comment.
I think I lean toward keeping the cache invalidation happening here within the editor package as that's where we have the filter to include the MediaUpload component. It's within the editor context where we expect the invalidation to happen, so arguably it's up to editor to make sure that's the case, whereas possibly media-utils shouldn't be too concerned about what's happening outside of itself?
Wondering if it could be added directly to the MediaUpload component instead of in this wrapper.
My understanding is that the goal of the MediaUpload component is to try to be a pretty thin bridge between a React component (with a common interface for drop-in media libraries) and the core media library, so I'd probably avoid adding too much in the way of block-editor logic to that package.
0ec6ebe to
7fb9cdf
Compare
|
Flaky tests detected in 7fb9cdf. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/15722139228
|
chriszarate
pushed a commit
to chriszarate/gutenberg
that referenced
this pull request
Jul 1, 2025
* Invalidate media entity when new media is uploaded * Add comment * Also invalidate getMediaItems when closing the media library ---- Co-authored-by: talldan <talldanwp@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
This was referenced Jul 18, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
Fixes #70397
This is a pragmatic attempt at a fix, in the smallest possible way, but there are still some remaining problems, which I'll document.
All this does is call
receiveEntityRecordswith thetrueinvalidateCacheflag whenever themediaUploadutil creates entities.This
mediaUploadutil is used pretty widely, so this fixes the majority of issues with cache invalidation, but there are still quite a lot of other problems that I've discovered. I can log these as separate issues:Inserter Media
When you upload a new image in the block editor canvas, the image doesn't immediately show up in the inserter, a user still needs to close and reopen the Media category.
I think this is because these 'inserter media categories' bypass
useSelectand thegetEntitiyRecordsselector, so they're not implemented in a reactive way. They instead call thegetMediaItemsresolver viaresolveSelectfrom an async function, so it 'pulls' from the core-data rather than have core-data 'push' to it:gutenberg/packages/editor/src/components/media-categories/index.js
Lines 150 to 152 in 8586e63
gutenberg/packages/editor/src/components/media-categories/index.js
Lines 127 to 139 in 8586e63
Widget Editors
The widget editors don't use the
editorpackage, they have their own separate implementation ofmediaUpload. I haven't addressed it as it seems like low hanging fruit. For a start those editors don't actually implement the Inserter 'Media' tab properly (it always shows 'No results found'), and so it's possible the missing cache invalidation doesn't cause any bugs for users in those editors.Image Block Cropping Tools
If you try cropping/editing an image using the image block's tools, this bypasses the
mediaUploadfunction that I'm augmenting in this PR. It has its ownapiFetch. The implementation has some red flags, like the way it uses a restricted import:gutenberg/packages/block-editor/src/components/image-editor/use-save-image.js
Lines 4 to 6 in 8586e63
It's also not possible to import from core-data in the block editor package, so cache invalidation isn't possible. These tools likely need their WordPress API usage extracted from the block editor package to a block editor setting.
Testing Instructions
Also try repeating the above steps, but instead of dragging images into the canvas: