Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Verify 'upload_files' capability when displaying upload UI in media blocks #4155
I've been looking for a way to solve this issue #3672 and I think one possible way is to add a capability attribute to blocks and check the current user has this cap before registering the block.
In the classic editor, the upload button is disabled if the current user does not have the
How Has This Been Tested?
I have tested this PR for the contributor role. A contributor does not have the
Screenshots (jpeg or gifs if applicable):
See #3672 for a video of the issue.
Types of changes
I think this PR is first a bug fix, but i also think it could be interesting to be able to restrict block usage according to the user's role.
FWIW i've tested in the classic editor the situation where a contributor can edit a post containing an image. In this case, the contributor can edit the markup (alignment, caption, link, classes, rel attribute) and can remove the image from the content.
When it's a gallery of images, the contributor cannot see it. He sees this placeholder instead
Anyway & imho, a possible approach could be to hide the media blocks from the block pickers, so that a contributor cannot be the one who inserts one of these blocks. If another user with the
@aduth about WP_REST_Attachments_Controller: creating items checks for the same capability (
In 1216849 I'm using the approach I've described in my previous comment. But instead of not showing the blocks, I'm using the feature that disables them when the property
So when the contributor is using the inserter he sees:
When another user with an upper role added an image or a gallery and kept the post as pending.. The contributor can see the corresponding block, remove it or modify markup, caption, link, alignment etc.. But he can't use the Edit button to open the WP Media Editor and can't transform it to another type (as the other types also require the
I haven't edited the Block autocompleter because i think there's another issue to fix in
Do you think it will be clear to the user what's happening here? Wondering if it would be much more effort to include a tooltip explaining the disabling (which may or may not be difficult, since mouse events tend not to be fired for disabled elements).
Perhaps related to #4097 ?
About the tooltip, i've tried to use the Tooltip component but i'm stuck as it is not supporting disabled elements. I think the user will understand he can't use the blocks, but i'm not sure he will figure out why, especially users who are not too aware of WordPress roles and capabilities. So I agree it's a bit too bad.
It looks like I have 2 lint errors, but i wasn't able to replicate them on my local environment, so I'll give it another look soon.
About the Autocompleter, yes i think it's best to wait for #4097 to be fixed, before adding the capability check to it.
referenced this pull request
Mar 18, 2018
It looks like that API returns an array with capabilities. Is it possible that block would require a check for more than one capability? At the moment we introduce only check for images, but I wonder if it should be represented as an array in the case when a user needs to have more permissions to edit a given block.
Thanks for your feedback. I can't think of an example where WordPress would require more than one capability to be able to do something. I think using an array to check for more than one capability would introduce some complexity eg: how should values in the array be treated: the user needs to have one of listed capability or all of them ? If a developer needs more than one regular capability, he could use a custom capability like
About the name:
referenced this pull request
Nov 14, 2018
Really great work on this PR
I left some minor comments. And not blocking here but I'd appreciate an e2e test (maybe as a follow-up PR) to ensure we don't regress.