-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardise capabilities for wp_template, wp_template_part and wp_global_styles #30893
Conversation
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @carlomanf! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
* | ||
* @return array Default capabilities. | ||
*/ | ||
function gutenberg_get_default_capabilities_for_fse() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this function is not very useful as part of our public API so we should mark it as internal by saying In the comments that it is internal and prefixing it with "_".
Regarding the name I guess it can more specific _gutenberg_get_default_capabilities_for_fse_post_types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amended.
Superseded by WordPress/wordpress-develop#1267 |
Description
Closes #30892
Although I have #27632 open as a more ambitious permissions prototype, there has not been much attention on it and it's unlikely to be ready for 5.8.
Accordingly, this branch is intended as a smaller target that just cleans up some code without changing behaviour.
At the moment, all three of the FSE post types use
edit_theme_options
as a blanket capability. However, all of them are doing this in different ways:wp_template
does a just-in-time update of the capability using theuser_has_cap
filterwp_template_part
uses the default post capabilities, and relies only on the REST API permissions checkwp_global_styles
sets some of the capabilities directly on the post type object, but many of them are missingThis standardises all three post types to configure their capabilities in the same way.
How has this been tested?
Screenshots
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
*.native.js
files for terms that need renaming or removal).