-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Expose the Site Editor Patterns page to all users #61637
Comments
Throughout our code base we generally use @jsnajdr Just noting that this issue might mean introducing "protected routes" in the site editor routing. |
That should place any special demands on the router: just register only these routes that correspond to the We'll have to preload the user REST data, if they aren't being preloaded already. Security concerns (user can't see certain data) should be fully addressed by the REST API -- the responses shouldn't contain any data that the non-admin user is not supposed to see. Calypso, the WordPress.com dashboard SPA, has been doing all this (preloading the user, conditional routes and sidebars) since forever, it's not a big deal. |
I hope to address this issue at least a little bit for WP6.7. Furthermore, if we aim to expose the entire site editor to all users, I think checking user permissions may be necessary not only for the Patterns page but also for other views. And that issue may also be relevant to moving forward with #62371.
I've tried digging into the Calypso code, but I wonder if adding a selector like the one below to Gutenberg would be a good first step? I'd be happy to hear any suggestions on what to do first. |
Yes, being able to check any user capability in JS code like this would be great: wp.data.select( 'core' ).canUser( 'manage_options' ); This should map directly to a server-side PHP call The current Jetpack and WP.com have this as part of the REST endpoint that retrieves info about a site. There is a But Core doesn't have anything like this, as far as I know. |
As I looked into in this comment, it seems that wp.apiFetch( {
path: '/wp/v2/users/1',
method: 'POST',
} )
.then( ( response ) => {
console.log(response)
} ) Do we need an endpoint that returns the result of running |
Maybe this doesn't need to be said or isn't relevant to this particular issue, but, just in case, whether a user has a capability depends not only on the capabilities assigned to their user object but the For example, using the The |
This is a good point. The I think this is a bug in the |
Yeah, this would certainly improve the accuracy of the endpoint, as long as core didn't assume that a capability has to be in the list for a user to possess it (the super admin example, among other use cases). |
Thank you for all of your research. When I submitted #63623, I learned that the template/template part endpoint permission checks only " In the future, the site editor should be accessible to users without the |
Currently all data related to the site editor quite consistently require The only exception are @youknowriad Are the strict read permissions really intentional, with good reasons? Or is it mostly an omission?
By the way, the |
I'm a bit confused, but at least with regards to patterns, we should be able to create patterns if you have However, the current site editor can't be accessed without the Wouldn't the purpose of this issue be to remove this restriction and allow all users access to the Site Editor Patterns page and control which screens and actions they can perform depending on their capabilities? |
The site editor shows pages and patterns so this is not entirely true that can be accessed without
I don't really know for the entities you mentionned.
This makes sense to me yes. |
That's true because patterns are saved as the |
Further improve #52150
What problem does this address?
#52150 aims to expose the Site Editor Patterns page for every "theme".
However, currently the Site Editor is only accessible to admin users. For non-admin users, links related to the Pattern page link to the classic post list (
edit.php?post_type=wp_block
).What is your proposed solution?
We should be able to remove this restriction and allow all users to access the Site Editor Patterns page.
To achieve this, I think we need to implement at least the following points:
The text was updated successfully, but these errors were encountered: