Global Styles: allow read access to users with edit_posts capabilities
#65071
Conversation
This file contains 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
|
Size Change: +19 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
|
We should also re-evaluate the |
Thanks for checking this out @Mamaduka 🙇🏻 Could you explain this a bit more to me? Do you mean we probably don't need to do a |
Correct. IIRC, anyone who can access editors will have this permission, but let's double-check when the REST controller update is ready. Happy to help with testing. |
ramonjd
force-pushed
the
try/extend-read-access-to-edit-capabilities-for-global-styles
branch
from
60370f5
to
1177a58
Compare
ramonjd
commented
Sep 9, 2024
| return ( | ||
| canUser( 'read', { kind: 'root', name: 'theme' } ) && | ||
| __experimentalGetCurrentThemeBaseGlobalStyles() | ||
| canUser( 'read', { |
There was a problem hiding this comment.
We could probably remove this since all roles that can read a post in the editor will need to read access to the styles object.
There was a problem hiding this comment.
This makes sense to me 👍
Edit: I guess we could consider it a further optimization after #65177. What's faster than not having to perform the check at all 😁
There was a problem hiding this comment.
What's faster than not having to perform the check at all 😁
That's the most performant "check" 😄
| ) | ||
| : undefined; | ||
| let record; | ||
| const userCanEditGlobalStyles = canUser( 'edit', { |
There was a problem hiding this comment.
Only admins will be able view the "edited" entity, when update styles in the site editor
In the post editor, it's enough to grab the saved entity.
| * Uses array_filter because it may have been added again in WordPress Core 6.6 in src/wp-admin/edit-form-blocks.php | ||
| * Reason: because GET requests to global styles items are accessible to roles with the `edit_posts` capability. | ||
| */ | ||
| $global_styles_edit_path = '/wp/v2/global-styles/' . WP_Theme_JSON_Resolver_Gutenberg::get_user_global_styles_post_id() . '?context=edit'; |
There was a problem hiding this comment.
Because read access permissions are looser, we don't need the edit response to be preloaded. The view/read is enough.
There was a problem hiding this comment.
Quickly hacking around to see the impact of these changes in relation to the regression noted earlier, removing this change brings the flash of styling much closer to trunk for both admin and non-admin users. Simply including the view context path as well didn't appear to make much difference.
There was a problem hiding this comment.
I can reproduce. I'll remove this change 👍🏻 and test the preloading array in a follow up. Thanks for finding it.
Logically, all we need is the view preloaded, but I suspect there's something going on at a deeper level that's evading me.
There was a problem hiding this comment.
Yeah, I'm missing something here as well. Seems related to the fact we get either the edit or view context based on user caps. I was wondering if the preloaded paths needed the same conditional treatment.
That said, I'll need to re-test to see if the non-admin user faced the same issue before the latest commit.
ramonjd
force-pushed
the
try/extend-read-access-to-edit-capabilities-for-global-styles
branch
from
ce2509d
to
41276bb
Compare
2 tasks
There was a problem hiding this comment.
This is testing well for me @ramonjd 👍
For admin users:
✅ Global Styles resets, theme style variation switches, style updates, push instance styles globally etc all work as before.
✅ Within the post editor the admin user still gets the Global Styles data.
For non-admin users:
✅ Global Styles data is now available and things such as block style variations display correctly, resolving the issue highlighted by #64755.
I think this is ready for some broader input from the REST API experts. Nice work!
|
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. |
ramonjd
added
[Type] Enhancement
Mamaduka
reviewed
Sep 12, 2024
|
What's the reason for having the plugin override class directly in the The |
Mamaduka
reviewed
Sep 12, 2024
ramonjd
added a commit
to ramonjd/wordpress-develop
that referenced
this pull request
Sep 12, 2024
|
Thanks for testing again, folks! 🍺
For similar reasons to when the inheritance chain was canned and the full The REST controller followed suit based on the same experience: #53618 The smallest inheritance override sometimes entailed copying half the class due to the prevalence of |
This was referenced Sep 12, 2024
spacedmonkey
previously requested changes
Sep 12, 2024
There was a problem hiding this comment.
I am not sure about this change. This could be seen as a breaking change. Not all users should have access to this data. I am against this change. Thoughts @TimothyBJacobs
talldan
dismissed
spacedmonkey’s stale review
No argument for blocking the PR was given
ramonjd
force-pushed
the
try/extend-read-access-to-edit-capabilities-for-global-styles
branch
from
1ad99d4
to
768770e
Compare
aaronrobertshaw
approved these changes
Sep 18, 2024
There was a problem hiding this comment.
The latest changes make sense and address the concern raised in #65071 (comment). Personally, I think that scenario was unlikely and overkill but better safe than sorry 👍
✅ Tests are passing locally
✅ Smoke test didn't reveal any regressions
LGTM 🚢
ramonjd
added a commit
to ramonjd/wordpress-develop
that referenced
this pull request
Sep 18, 2024
|
Thank you! I'll update the Core backport PR so discussion can move there. Thanks for the feedback, everyone. |
ramonjd
deleted the
try/extend-read-access-to-edit-capabilities-for-global-styles
branch
This was referenced Sep 26, 2024
97 tasks
|
Hey @ramonjd 👋 Would you be able to help write a dev note for this for the 6.7 release? We are planning to have this as part of a larger Miscellaneous Editor Updates note. We are hoping to get all drafts in by October 13th to leave some time for reviews before the RC1. All Dev Notes get tracked in #65784 so feel free to leave a note there or ping me directly :) Please let us know if you can assist with that. Thanks in advance :) |
fabiankaegy
added
the
Needs Dev Note
The scope of this change is pretty narrow, so being under the banner of Miscellaneous Editor Updates sounds good 👍 To help get the ball rolling I've drafted something small below. I'll leave it for Ramon to iterate on (or discard if its off the mark). Dev Note: Read access to Global Styles dataIn WordPress 6.7, users with the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Builds upon the base idea in:
With a view to:
What
Allows any role that can edit a post, including custom post types, to read global styles from the API and in the editor.
Why
Block style variations and other global styles are not available to non-admin editors. See #64755
Furthermore, having global styles available in the post editor will, one day, allow block controls to reflect any values inherited from the theme/global styles. See: #64670
How
readcapabilities toedit_postsin the global styles CPT (via filter)current_user_can( 'edit_posts' )Testing Instructions
await wp.data.resolveSelect( 'core/block-editor').getSettings()in the browser console.Symbol(globalStylesDataKey)- it should be a merged object of base theme and user global styles.await wp.data.resolveSelect( 'core' ).getEntityRecord( 'root', 'globalStyles', await wp.data.resolveSelect( 'core' ).__experimentalGetCurrentGlobalStylesId(), { context: 'edit' } )in the console. You should see a 403.Run a test or two: