Cover block: add media editor modal by ramonjd · Pull Request #79258 · WordPress/gutenberg

ramonjd · 2026-06-17T07:27:54Z

What?

Maybe fixes #15696

Adds a Crop toolbar button to the Cover block when it uses an editable image attachment.

The button opens the existing media editor modal, allowing image edits such as crop, rotate, and flip without adding Cover-specific transform controls.

The button is hidden when the Cover block is using a video, embed, featured image, temporary upload/blob URL, content-only mode, or when the media editor modal is unavailable.

Kapture.2026-06-17.at.15.45.41.mp4

Why?

This offers an alternative to adding a custom flip control to the Cover block. Reusing the shared media editor keeps image editing behavior centralized and avoids introducing Cover-specific image transformation UI.

Testing Instructions

Create or edit a post.
Add a Cover block.
Choose an image from the Media Library.
Select the Cover block.
Confirm a Crop button appears in the block toolbar.
Click Crop.
Confirm the media editor modal opens.
Apply an edit, such as flip, rotate, or crop.
Save the edit.
Confirm the Cover block updates to use the edited image.
Add or switch the Cover block to a video or embedded video.
Confirm the Crop button is not shown.

github-actions · 2026-06-17T07:36:24Z

Size Change: +315 B (0%)

Total Size: 8.6 MB

📦 View Changed

Filename	Size	Change
`build/scripts/block-library/index.min.js`	324 kB	+315 B (+0.1%)

_{compressed-size-action}

github-actions · 2026-06-17T08:01:44Z

Flaky tests detected in 20c97a3.
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/27734463835
📝 Reported issues:

[Flaky Test] does not dirty related template parts or navigation menus when rendered in the post editor #79294 in /test/e2e/specs/editor/blocks/navigation-passive-rendering.spec.js

jasmussen · 2026-06-17T09:20:17Z

Honestly this looks compelling to me, happy to try it. This is a deduplication of concerns, focusing on a single and good solution. I'm here for it.

github-actions · 2026-06-17T09:20:29Z

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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @vonloxx.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: vonloxx.

Co-authored-by: ramonjd <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: jasmussen <[email protected]>
Co-authored-by: paaljoachim <[email protected]>

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

andrewserong

Great idea! In practice this feels really nice to me, and it gives much more control while interacting directly with the cover block, without having to go out to the media library:

2026-06-18.10.51.59.mp4

Just left a comment about the label for the crop, but the other question I had is whether we should recompute the overlay color and isDark? It's a little messy currently in the Cover block code as there's a useEffect for managing it, but it only fires when the featured image setting is enabled, and otherwise the logic exists in the callbacks. IMO not a blocker to landing if it looks like a rabbit hole. The main edge case here is if someone is cropping away really bright or really dark areas of an image that would result in flipping the values 🤔

Overall, though, this looks like a good improvement — it adds useful functionality, but it's also very safe to remove again if it proves confusing for users as it doesn't alter how the Cover block itself works.

andrewserong · 2026-06-18T00:57:22Z

+						<ToolbarButton
+							ref={ editMediaButtonRef }
+							icon={ crop }
+							label={ __( 'Crop' ) }


Because the Cover block isn't just about the background image itself, should we be slightly more specific with the label? I.e. Crop image or Crop background image?

The crop button sits next to the "Full height" button which affects the outer wrapper of the Cover block itself, so it's possible someone might think that they could use the Crop button to change the size of the block itself (where they'd really want to be using width / height controls)

ramonjd · 2026-06-18T01:15:38Z

Thanks @andrewserong

The main edge case here is if someone is cropping away really bright or really dark areas of an image that would result in flipping the values

I haven't actually tested this PR a lot yet 😄 just the happy path, so thanks for pointing this stuff out!

Initially, I'd class that as a feature really, but if getMediaColor() is doing some automagic computation then it might be worth triggering it again when the image changes. I'll take a look.

andrewserong · 2026-06-18T01:31:04Z

Initially, I'd class that as a feature really, but if getMediaColor() is doing some automagic computation then it might be worth triggering it again when the image changes. I'll take a look.

It can be a bit tricky these things sometimes as this case is "a media item already exists and a user is performing a crop" so it might wind up being that we want the simpler approach anyway. Again, not a blocker if you reckon it's better to leave it off for now!

ramonjd · 2026-06-18T01:45:38Z

It can be a bit tricky these things sometimes as this case is "a media item already exists and a user is performing a crop" so it might wind up being that we want the simpler approach anyway

Good point. I'm not sure which direction to go on this one - if the overlay color changes too much it might be unexpected. I'll have a looksy anyway, but if it works out to be too spaghetti, I'll mark it as a follow up.

…hance media update handling with average background color calculation and overlay color management.

ramonjd · 2026-06-18T03:27:30Z

+						: {} ),
+				};
+
+				if ( newUrl ) {


I kept the change targeted to the new media editor update path rather than refactoring the existing Cover media-selection logic. I tried the latter first, but wasn't confident about it affecting existing flows.

Maybe a follow up to unify, but it'd be a behavioral refactor so I'm not sure I'd want to make this PR more complicated.

There's a fair bit going on, e.g., overlay color, isDark, isUserOverlayColor, undo persistence, and sometimes dim ratio so any shared helper could trigger unintended side effects.

Keeping it contained to this flow sounds wise, then 👍

andrewserong

Thanks for the updates, this is looking good to me! Stress tested with some artificial images that are made up of solid black and white areas, and after a crop, the dark mode and overlay color is set correctly 👍

2026-06-18.15.25.00.mp4

Not pictured: a user selected overlay color is also preserved as expected.

Only other question I had was whether we should or shouldn't be resetting the focal point, too. We currently don't reset it after updating to the new crop. Because some folks might adjusting flip but not cropping other dimensions, I think I lean slightly toward not mutating that value when a crop occurs, but it's hard to know what a user might expect. For that one, I reckon we could revisit if we find that users are struggling with it.

LGTM, I think this is a nice feature addition 🚀

ramonjd · 2026-06-18T05:34:25Z

I think I lean slightly toward not mutating that value when a crop occurs, but it's hard to know what a user might expect

Good question. I thought about it, but decided against it too. It's a user action that requires some effort, so I'd hope it'd be expected that changing the image dimensions will affect the focal point.

And either way: reset or no, the value will have be changed again manually.

I mean, you're right: it's hard to know exactly what's expected here. I guess we'll find out 😄

Thanks again for testing 🙇🏻

Add media editor entry point to Cover block

1764740

ramonjd requested review from andrewserong and jasmussen June 17, 2026 07:27

ramonjd self-assigned this Jun 17, 2026

ramonjd requested review from ajitbohra and fabiankaegy as code owners June 17, 2026 07:27

ramonjd added [Type] Enhancement A suggestion for improvement. [Block] Cover Affects the Cover Block - used to display content laid over a background image labels Jun 17, 2026

github-actions Bot added the [Package] Block library /packages/block-library label Jun 17, 2026

andrewserong reviewed Jun 18, 2026

View reviewed changes

Update Cover block controls to specify 'Crop background image' and en…

20c97a3

…hance media update handling with average background color calculation and overlay color management.

ramonjd commented Jun 18, 2026

View reviewed changes

Comment thread packages/block-library/src/cover/edit/block-controls.js

andrewserong approved these changes Jun 18, 2026

View reviewed changes

ramonjd merged commit 64c7500 into trunk Jun 18, 2026
43 of 46 checks passed

ramonjd deleted the try/add-image-editor-modal-cover-block branch June 18, 2026 05:35

github-actions Bot added this to the Gutenberg 23.5 milestone Jun 18, 2026

Uh oh!

Conversation

ramonjd commented Jun 17, 2026

What?

Why?

Testing Instructions

Uh oh!

github-actions Bot commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jasmussen commented Jun 17, 2026

Uh oh!

github-actions Bot commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Unlinked Accounts

Uh oh!

andrewserong left a comment

Choose a reason for hiding this comment

Uh oh!

andrewserong Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

ramonjd commented Jun 18, 2026

Uh oh!

andrewserong commented Jun 18, 2026

Uh oh!

ramonjd commented Jun 18, 2026

Uh oh!

ramonjd Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

andrewserong Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

andrewserong left a comment

Choose a reason for hiding this comment

Uh oh!

ramonjd commented Jun 18, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions Bot commented Jun 17, 2026 •

edited

Loading

github-actions Bot commented Jun 17, 2026 •

edited

Loading

github-actions Bot commented Jun 17, 2026 •

edited

Loading