-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Reuse mediaUpload filter for new media modal by wrapping it in a class component #73225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
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. |
|
Size Change: -322 B (-0.01%) Total Size: 2.49 MB
ℹ️ View Unchanged
|
|
While I think this is reasonable as a next step, we're working towards upgrading to React 19 at some point. and this means no class components, this won't be the only place impacted though. |
React 19 hasn't dropped class components, but yeah, it looks like they're urging folks to migrate to function components so future-proofing is a good call. What's the alternative for backwards compatibility? Is there a shim that makes a functional component work with Do filter callbacks like Otherwise, assuming that we can't update every plugin that requires class extension, what about a deprecation notice? |
We probably need to deprecate that behavior, it's not really clear why we require these components to be class components. |
Some plugins are extending the MediaUpload class component through the I think that in order to avoid creating a new filter, we could just wrap this in a class for now and perhaps add a deprecation notice or something? |
Yes, this works for me. |
|
Deprecation notice added! This is now ready for a final review. |
andrewserong
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, this feels much tidier 👍
Testing well with the AMP plugin active, with and without the experiment, using image, audio, file blocks in the post and site editors, and setting featured images.
LGTM! 🚢
| 'core/editor/components/media-upload', | ||
| () => { | ||
| deprecated( 'Extending MediaUpload as a class component', { | ||
| since: '19.9', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, whoops, missed this while testing. Should this be 6.9?
Or, since 7.0 with deprecated in 7.2? (I.e. which version will be deprecating in, and which version will it be removed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that number's way off, it was meant to be Gutenberg release 😅 but yeah it makes more sense for it to be core version.
What?
Follow-up to #71944, on @youknowriad 's suggestion: we should be able to reuse the
editor.MediaUploadfilter for the experimental media upload modal as long as we wrap it in a class component to avoid the kind of breakage addressed in #70648.I tested this by installing the AMP plugin and switching the class wrapper in this PR to a function. The image block I was testing with errored. I then switched back to the class wrapper and all worked well.
I didn't test with any other plugins; I'm not sure which others may be expecting a class component here. If anyone knows of other plugins to test with, please leave a comment here!
Testing Instructions