Global Styles: allow read access to users with edit_posts capabilities
#65071
Conversation
|
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
| 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
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
|
What's the reason for having the plugin override class directly in the The |
|
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 |
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
Agreed. Thanks for testing that. I'll take a look. It would be good not to introduce a regression. |
|
While testing with @aaronrobertshaw we noticed that was no difference between preloading global styles for the post editor and not doing it, which means that something is buggy. Or maybe not 😄 I removed the update to the preload filter path array for now. I think we should look at this in an immediate follow up as it might be an unrelated bug. |
There was a problem hiding this comment.
While testing with @aaronrobertshaw we noticed that was no difference between preloading global styles for the post editor and not doing it, which means that something is buggy. Or maybe not 😄
While giving this PR a final test in its current state, I think preloading the view context for global styles does have a tiny reduction in the flash of styling for the non-admin user in the post editor.
This isn't enough to overcome the real issue of a styling flash though. More on that below.
I think we should look at this in an immediate follow up as it might be unrelated bug.
Agreed.
As it stands, this PR solves the main bug and the styling flash is the same as on trunk for admin users. A dedicated follow-up specifically tackling the preloading of global styles data sounds like a good idea.
With all that said, this PR is testing as advertised.
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.
Check read caps on all CPTs
Preloads the global styles CPT without edit via filter Check canUser capabilities according to the capabilities set in the CPT wp_global_styles
Update WP_Error code and associate tests for read permissions check
Co-authored-by: George Mamadashvili <georgemamadashvili@gmail.com>
ramonjd
force-pushed
the
try/extend-read-access-to-edit-capabilities-for-global-styles
branch
from
1ad99d4
to
768770e
Compare
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 🚢
|
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
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: