Media Editor Route: Try adding undo/redo and save/cancel actions to the header

[andrewserong]

Part of:

• Media Library: Create a dedicated media editor #72734

What?

In the Media Editor (Route) experiment, add undo/redo/save/cancel actions to the header, and ensure cropping controls are available on mobile.

Note: this isn't the final place for these things! The goal right now is to get them in there so that we can save and update media items in the experiment. We can explore further polishing in follow-ups.

Why?

The Media Editor (Route) has been a fairly minimal scaffold but now that 7.1 is nearly out, I'm doing a few of these PRs to build out parity with the media editor modal and so that we can start to test out this interface as a potential replacement (one day) for the core editor screen. Or at the very least, to verify how this interface is going to feel.

As part of that, I'm also exploring how we can make the media editor a bit more composable for different kinds of layouts/usages. I'm a bit tentative about these changes, so happy to rollback / go in a different direction if this feels off.

How?

This might be too much! But it's a proposal:

• In the route-based version of the editor, flesh out the rest of the UI so that we have undo/redo/reset in the header, alongside save and cancel buttons. And in mobile layout we have image controls in a footer toolbar.
• Split the footerActions out into a dedicated ModalFooter component
• Reduce the reliance on renderFrame props for rendering components in the frame, and instead use sub-components off MediaEditor (following a similar pattern used by DataViews). In this way, the route-based version can compose via MediaEditor.HistoryActions, MediaEditor.HeaderActions, MediaEditor.SaveActions, and MediaEditor.ImageControls.

Testing Instructions

Enable the Media Editor (Route) experiment:

Go to the Media library screen in wp-admin and click on an image or its "Edit" link.

Test out undo/redo/reset and saving / cancelling edits.

❗ Then, smoke test the existing media editor modal in the post editor and make sure I haven't accidentally introduced any regressions!

Screenshots or screencast

Desktop	Mobile

Use of AI Tools

Claude Code (Opus 5), reviewed, guided and nudged by me.

[github-actions]

Size Change: +150 B (0%)

Total Size: 7.73 MB

📦 View Changed

Filename	Size	Change
build/scripts/editor/index.min.js	531 kB	+151 B (+0.03%)
build/styles/editor/style-rtl.min.css	27.2 kB	-2 B (-0.01%)
build/styles/editor/style.css	32 kB	+1 B (0%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 2394067.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/32106613492
📝 Reported tests:

pre-publish panel does not dirty the default category record in /test/e2e/specs/editor/collaboration/http-only/collaboration-taxonomy-record-dirty.spec.ts, passed after 1 failed attempt.

Error: expect(received).toBe(expected) // Object.is equality

Expected: false
Received: true
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/collaboration/http-only/collaboration-taxonomy-record-dirty.spec.ts:111:25

[andrewserong]

This is so that the header undo/redo buttons use the default colors, but the modal footer retains the admin theme color.

So, modal footer:

route-based editor header:

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[andrewserong]

@ramonjd I'm a little hesitant about this one, as I'm not too sure if this is the right direction API-wise (i.e. are we now exposing too much of the internals of the media editor?), but it's an attempt at making the media editor composable for different layouts, with the explicit goal of getting it working for the route-based approach.

Very happy to go in a different direction or scale it right back if this refactor feels too much.

[Copilot]

Pull request overview

Adds composable media editor actions to the route header and responsive mobile toolbar while preserving modal behavior.

Changes:

• Exposes history, header, save, and image-control subcomponents.
• Adds route-level save/cancel and responsive editing controls.
• Extracts modal footer composition.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
routes/media-editor/style.scss	Styles shortcut scope and mobile toolbar.
routes/media-editor/stage.tsx	Composes route header and responsive actions.
packages/media-editor/src/components/media-editor/index.tsx	Adds contextual action subcomponents.
packages/media-editor/src/components/media-editor-modal/style.scss	Updates modal action styling.
packages/media-editor/src/components/media-editor-modal/index.tsx	Extracts and composes the modal footer.
packages/media-editor/CHANGELOG.md	Documents the API changes.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ramonjd]

Thanks for getting this PR up so we can test things.

Overall I think the buttons work better in the header, and it's an experiment. Let's just try things out.

scale it right back if this refactor feels too much.

What were you thinking?

In the beginning I had in mind a scenario in which we'd expose generic components so the library (or whatever) could compose its own layout.

That way we wouldn't end up in a situation where a component, e.g., the modal's footer layout, is half-owned by two implementations.

This is still important, but I don't think we should worry about it too much yet. We don't know what the final modal layout will be, let alone the media library 😄

[ramonjd]

This seems out of place. Does the layout check belong here or in renderFrame()? I see the isNarrow && isImage check already there.

Reason why, if someone tries to render <MediaEditor.ImageControls /> in a wide layout, nothing happens, right?

From what I can see, we could remove layout from MediaEditorFrameContextValue to shrink the shared context.

Might be missing something.

[andrewserong]

From what I can see, we could remove layout from MediaEditorFrameContextValue to shrink the shared context.
Might be missing something.

Nope you're not missing something! I think this is just an artifact of me moving things around a bit too much and I lost track of the logic and that I'd already added the layout checks in renderFrame for the route and ModalFooter for the conditional rendering of ImageControls.

I think we still want an internal check for these controls for isImage so that the consumer doesn't have to worry about too many conditions of their own, but let me know if it still feels smelly.

I've pushed an update in 4bea041 that removes layout from the MediaEditorFrameContextValue 👍

[ramonjd]

Oh I use really long image file names too for no reason at all...

Kapture.2026-08-19.at.11.22.25.mp4

[andrewserong]

What were you thinking?
In the beginning I had in mind a scenario in which we'd expose generic components so the library (or whatever) could compose its own layout.

Earlier on in this PR I didn't refactor quite so much, but stuffed additional props into the renderFrame callback. It felt code-smelly so I pressed on and added the sub-components as we currently have in this PR (so MediaEditor.HistoryActions and so on). This latter approach is still a refactor, but it sort of goes half way to your idea of separately exported components.

So I guess my question was: does this in-between state feel okay for now? Having slept on it, I quite like it for now as it seems to work pretty well for our two examples of using the media editor so far, but as you say, it doesn't preclude us from further carving things up further down the track if we want dedicated/fully separate components.

This is still important, but I don't think we should worry about it too much yet. We don't know what the final modal layout will be, let alone the media library 😄

I was thinking the same, glad we're on the same page!

Oh I use really long image file names too for no reason at all...

Yep, the header will need some further polishing for sure! I'd like to play around with a back button there, too, to match the post editor (along with truncating the filename 😄)

[manzoorwanijk]

Can we please declare @wordpress/base-styles as a dependency in routes/media-editor/package.json?

[andrewserong]

Sure! I'll follow-up. Thanks for flagging @manzoorwanijk!

[andrewserong]

Follow-up here: #81845