Media Editor: Try a media editor mode in the editor #73808
Conversation
andrewserong
added
[Feature] Media
|
Size Change: +24.9 kB (+0.97%) Total Size: 2.6 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in a4c5e69. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20088225567
|
…a items and metadata directly
andrewserong
force-pushed
the
try/media-editor-state-within-the-editor
branch
from
8405da3 to
6878c4c
Compare
|
Just pinging a few folks I've been chatting with about the idea of introducing a media editor. This PR isn't ready for a proper review, but I wanted to gauge a general sense of whether injecting this into the FYI: @youknowriad @tellthemachines @ramonjd @talldan @aaronrobertshaw I'll continue chipping away at this, but happy for any early feedback. |
youknowriad
left a comment
youknowriad
left a comment
There was a problem hiding this comment.
The main downside of this PR is that you'll be forced to load all the blocks and dependencies (which potentially is a lot of MBs) when you want to load the media editor. I agree there's something nice with having the same API as the regular Editor component though but I'm very hesitant of this approach.
|
Thanks for getting this started @andrewserong
I understood from the PR description that it demonstrates the workflow, but the eventual objective was some kind of Could a lazy import then help in that case? The caveat to all this is that we don't have much of an idea how a media (and media metatdata) editor fits into the UX of the editor yet. I think it needs some design. Also, I'm not sure about loading blocks? Does the media editor care about blocks? |
Yes, the idea in this PR was to first introduce these things as part of
Totally. The entrypoint I went with for this PR was simply to add an "Edit media" button to the block toolbar, but I'm sure there's lots of other ways we could do it. For now, the idea I had in mind was to try to make things feel fluid from the perspective of "I'm in the editor and would like to edit this photo" rather than beginning from wp-admin. But there'll be lots of stuff to explore!
Thanks for the feedback! Did you have any other approaches in mind for how it might ideally work? No worries if not of course, but I always like hearing your thoughts on these matters 🙂 I think an alternative PR to try to this one, to see how it'd all feel, would be to create a separate package and load up the media editor in a similar(ish) way to how we have the site editor separate from the post editor. It'll create a cleaner separation of concerns, but potentially a little more duplication. That said, this PR has heaps of conditions that aren't easy to reason about, so it really might be a better thing all around to make it a bit more separate. I'll be AFK for five days or so after today, so I won't get back to any feedback immediately, but I'll happily either try out more ideas in this PR, or start an alternative PR to try out a separate Thanks everyone! |
|
To be really clear I really like the back and forth between "media" and other editable elements that the current PR offers (onNavigateToEntity...). And this would be harder to achieve with a separate package / editor (not impossible). The main downside though remains the same, if you want to just open the "media editor" kind of in isolation, you may be forced to load the blocks and such. I'm not sure I measure how much of this is a trouble or not. Also, could be a non issue if the "attachment" editors needs blocks in any way. The potential alternative would potentially be an "Editor" package that acts as a "router" kind of per post type and only loads the blocks... if needed (sounds great on paper, but probably not a small project :P) |
That's my favourite part, too, that it can actually feel quite slick if we get it working right.
This is an interesting one. Off the top of my head I have a couple of ideas:
In any case, all just ideas for now! If / when we settle on a path forward that we like, we can always try landing things behind an experiment. In the shorter-term, I'll give a bit more thought to how we can build things in a reusable way. |
Thanks, folks. That's where my brain was going. Like a package that exports all this stuff, ready to be consumed by any editor or other package. |
…age, and see how that feels
|
Alrighty, I've pushed a change in d5704a1 that inches toward this idea by moving the media-specific bits that we can into a I think the next thing for me to try, keeping in the spirit of this being a proof of concept, will be to try out adding a completely separate route (perhaps using the dedicated font library as inspiration: #73630). I'll continue hacking on this idea, but something that I really liked about #73630 as a point of inspiration, is that the font library itself lives in global-styles-ui and there is a separate My plan will be to continue on with this being the "kitchen sink" PR for these ideas, as it's helpful to try it all out in one place. If / when we land in a good place with it, we can split it out into separate, more polished PRs if it looks too unwieldy. Also, while I'm hacking on this with Claude, things will likely look a little messy / strange as I'm not looking at the code in too much detail just yet. That said, do feel free to continue to drop any ideas anyone thinks worth pursuing here, and I'll take a look. For now, I'll keep hacking on the ideas here and see how it all might look. |
I think this is a good direction indeed. What's the API for that package though? I'd love for this package to be considered as the same level of abstraction compared to what "block-editor" is for blocks. In other words something like: <MediaEditorProvider value={media} onChange={updateMedia} settings={settings}>
<MediaPreview />
<MediaControls />
</MediaEditorProvider>Would something like this make sense? (A WordPress agnostic media editor package). I do think we need to think this properly before committing too much though. |
Would something like this make sense? (A WordPress agnostic media editor package). I like that idea. We need to handle attachment post types as well to deal with the metadata, so would it make sense to wrap it in Or maybe the dataview attachment item modal could work here, passed down via context 🤔 |
If it's a WP agnostic package we can't use entity provider, but the "value" prop and "onChange" should be enough to be able to read/edit the object |
I like this idea. If we manage to do it right, I'd love it if we could create a media-editor package that someone could one day use to build an Electron app for a dedicated (yet simple) image / media editor, a bit like how Block Notes is built using capacitor on top of the block-editor package. I wouldn't consider it the first goal of this work per se, as the WordPress / Gutenberg use case is the primary one, but I really like the idea of it being fairly general purpose. I'm imagining it would then be up to the route and
Indeed. My intention is to continue hacking on the ideas here, and to try things out to see how they feel before attempting to land an approach. I think hooking up a route will help tease apart some of the questions, as that'll give us the two entry points to the media editor and hopefully make it clearer what the shape of the API will need to be. |
What?
A first pass at: #72734
🚧 🚧 🚧 Note: this is a little hacky for now, I'm mostly pinging folks for early feedback on the overall direction, and whether it's a good idea to pursue integrating into the
editorpackage 🚧 🚧 🚧Add a media editor state of the
editorwith the goal that media items (attachments) can be edited directly from a block-editor-like interface, but in an isolated mode, a bit like editing template parts.This PR is designed to simply provide the scaffolding to achieve this — it will just display the media item, and a DataForm for the fields associated with the item.
It'll be up to follow-up PRs to implement cropping, saving, properly locking down parts of the editor UI, etc.
Why?
So that folks who wish to edit a media item can do more than just the inline cropping within the block editor, without having to go all the way out of the block editor.
How?
MediaMetadataPanelinstead of the post panel. There's basically lots of conditionals for this sort of behaviour.Testing Instructions
Switch on the experiment:
Some caveats / things to improve in follow-ups
Screenshots or screencast
2025-12-10.17.13.07.mp4