Image/Site Logo: hide crop toolbar when editMediaEntity is unavailable#76626
Merged
Conversation
ramonjd
added
[Type] Enhancement
|
Size Change: +63 B (0%) Total Size: 8.76 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 189d204. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23274795614
|
andrewserong
approved these changes
Mar 19, 2026
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
Nice catch, this is testing well for me based on the testing instructions and removing the update_files capability, with the cropping tool being available before this PR and not with this PR applied 👍
A couple of non-blocking questions. Should we also add this !! check to the condition that determines whether to inject the Edit media button for the experimental media editor?
gutenberg/packages/block-library/src/image/image.js
Lines 775 to 781 in 081c52d
Right now I think it shows based on whether the user has permission to edit the current attachment. It's probably quite an edge case this one, as to reach this state (where the button showed), I had to upload an image while I still had the upload_files capability, then remove that capability, then reload in order to see it.
This also raised another (idle) question for me: outside of the testing instructions, did you encounter seeing the Crop tool in situations where it shouldn't have displayed? For author roles, at least, they'll only be able to access items in the media library that they uploaded (I think), so I wondered how likely it is for folks to encounter this issue. (Still a good fix of course, I just want to make sure I have a good understanding of when we're accidentally showing controls when we shouldn't, as I think it'll help inform some of the media editor stuff).
This got wordy, apologies! Last note:
See also the alternative #76628, which proposes to stabilize the editMedia settings property
I think I prefer this PR personally. While in the longer term I like the idea of stabilising that key and the idea of custom editors that implement their own cropping tools (or indeed a custom cropping / image editor that's standalone from WP), given that the media editor experiment doesn't yet have cropping tools in trunk, I feel like there might be some more iteration on how all that works before stabilising. In particular, I'm excited about the explorations you've been doing into freeform crop, so wondered if it's worth looking at stabilising once we've got all the features we need in trunk for the media editor, first?
Just thoughts 🙂
This one otherwise LGTM!
|
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. |
Member
Author
Yes we should coerce to bool. Good pick up, thanks 🙇🏻
I see what you mean. I guess it is a possibility that permissions could change at run time. Not sure how to guard against that. Do you think we need to?
Never 😄 The primary motivation was to fix the UX for folks building a custom editor without the The crop tool appeared in the toolbar because it wasn't gated, but the block setting that actually did the editing wasn't present 😄 The second motivation was pure consistency: the media
I value your thoughts here. When I was preparing #76628 I was having doubts about adding another public property. It does seem premature, and I like the idea of encouraging users to extend the block tools with their own cropping tools for now. Maybe we need documentation around that. There are extension slots in the block toolbar. I agree. I'll close the other one. Can always reopen if there's more discussion. Thank you! |
Contributor
No, I mostly wanted to capture the thought, I think we're probably fine for now. We can revisit this stuff when we look at stabilising the media editor, I reckon, which is quite a long ways off!
Oh, great context, thanks! Yeah, in this case I think what you've done here is the right path forward for now 👍
Same. That said, I also really like the idea of eventually supporting a standalone image cropper further down the track. It would mean, as you say, documenting and thinking carefully about the APIs we're exposing. But for now, letting custom implementations roll their own thing sounds fine to me.
|
Member
Author
Oh I totally misread that. We'll add |
…g in the experimental media editor
ramonjd
force-pushed
the
update/gate-cropping-without-upload-permissions
branch
from
081c52d to
189d204
Compare
adamsilverstein
pushed a commit
that referenced
this pull request
Mar 31, 2026
#76626) Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
adamsilverstein
pushed a commit
that referenced
this pull request
Apr 7, 2026
#76626) Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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?
Follow up to:
Note
See also the alternative #76628, which proposes to stabilize the
editMediasettings property so that custom block implementations can provide their own cropping callback.Currently, users without upload permissions can see and interact with the crop toolbar in the Image and Site Logo blocks.
But attempting to apply a crop fails with the error message "Sorry, you are not allowed to edit images on this site."
Why?
The attachments REST controller rejects any request to edit for users without upload permissions.
For consistency, the crop UI should not be shown at all if the user cannot save the result.
How?
Check for the existence of editMediaEntity. Show the crop tools if it's available.
editMediaEntityis gated behind ahasUploadPermissionscheck.Testing Instructions
Add this to a must-use plugin or functions.php to strip upload permissions from the Author role.
As an editor/admin, first add an image to the Site Logo block. While you're there, verify that you can still see the crop button and can crop images in both blocks without issue.