-
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
Global styles: Allow indirect properties when unfiltered_html is not allowed #46388
Global styles: Allow indirect properties when unfiltered_html is not allowed #46388
Conversation
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.
Lovely, thanks for working on this!
It tests quite well for me, and the proposed approach makes sense to me. I'd love though to hear more feedback from someone with more experience than me in this area such as @ramonjd or @tellthemachines, since I'm not confident enough to approve this.
I left a couple of minor comments, but to me this is ready to go.
Thanks for giving this a test and for adding your thoughts @mmtr! 🙇
Good thinking! In that case, I'll just ping @WordPress/gutenberg-core and @scruffian too for visibility to see if there's anyone else with thoughts on the direction to take here, or potential implications on changing the logic here to add the concept of inferred properties in addition to explicit/direct properties that are handled by |
…perties when unfiltered_html is not allowed
de8638d
to
fe80e7b
Compare
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.
Testing locally with the add_action( 'init', 'kses_init_filters' )
snippet, this fixes the issue ✅
Just a couple of readability/code organisation points below, otherwise code looks good!
|
||
} | ||
add_action( 'init', 'gutenberg_override_core_kses_init_filters' ); | ||
add_action( 'set_current_user', 'gutenberg_override_core_kses_init_filters' ); |
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.
Should these changes be in a kses.php
file instead, to mirror core? Or perhaps we should have a file somewhere for changes that are not ever meant to be backported? It's best to keep class files for just the class.
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.
Should these changes be in a kses.php file instead, to mirror core?
Great point, yes! The lib/experimental
directory appears to be a good place for things that won't be backported necessarily since it isn't yet in a release, so I think lib/experimental/kses.php
might work. I can give that a go 🙂
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.
Thanks for the reviews @tellthemachines and @ramonjd! I'll rename the property and move the code around a little bit.
It winds up being piped through the same mechanism. The test currently just looks at the root level — I think to get the block level working in the test, we might need to register blocks, too 🤔. The change in this PR doesn't explicitly look at the nesting / recursive behaviour of
Good call. Once this PR lands, I'll open up a corresponding backport PR for core. I think an appropriate time for a dev note could be once the backport PR is approved, in case there's any additional feedback / work required for the core side of things. Let me know if you think a dev note should be put up sooner, though! |
Sounds good. Cheers! |
Update: I've done the following:
I'll leave this PR open overnight just in case anyone else pinged would like to chime in, but otherwise I think we should be able to merge this in tomorrow 🤞 |
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.
Changes look good!
Thanks again for the reviews! Since this PR only updates internal implementation details of the theme JSON class, I'll merge this in now. If there's any follow-up feedback, or if folks would like further changes, we should be able to happily make changes without affecting the API at all. |
…allowed (#46712) ## What? Follow-up of #46388. Ensures that the content and wide width settings set via Global Styles are considered safe and thus output as custom properties on the body element. ## Why? Because secure `layout.contentSize` and `layout.wideSize` settings are being stripped out for users without the `unfiltered_html` capability as part of `remove_insecure_settings`. ## How? - Updates the `INDIRECT_PROPERTIES_METADATA` array introduced in #46388 to allow the `layout.contentSize` and `layout.wideSize` settings. - Modifies the `remove_insecure_settings` to check the `INDIRECT_PROPERTIES_METADATA` array for settings that are not included in `PRESETS_METADATA`.
Dev note for 6.2This bug fix is an internal implementation detail of the Theme JSON class, and doesn't really directly affect extenders / people working with In WordPress 6.1 the layout block support was refactored to output CSS values for block spacing, with additional layout controls within global styles being made available. This resulted in a bug for admin users without the For WordPress 6.2 (and backported to WordPress 6.1.2) this issue is resolved by the Theme JSON class storing a list of indirect properties ( For themes using layout features, no changes are required, as the bug fix is an internal implementation detail of how Theme JSON styles are validated and output. Further reading
@bph just sharing a draft dev note above — this can be combined with other misc changes in 6.2, I think. |
What?
Fixes #45520
This PR adds a new
INDIRECT_PROPERTIES_METADATA
array to the theme JSON class, to store properties metadata for properties that are not directly output bycompute_style_properties
, but are instead used elsewhere in global styles output.This array is then used in
remove_insecure_styles
to ensure that style values that will be used in other cases are validated against an indirect property. The main use case at the moment is forblockGap
style values, which are output as either top margins or gap styles, depending on the layout type. For the purposes of validation, though, we can safely validate against a small list of gap properties.Why?
Over in #45520 it was flagged that the absence of
blockGap
inPROPERTIES_METADATA
meant that the value was being stripped in situations where a user doesn't have theunfiltered_html
capability and is saving global styles (e.g. for multisite regular admins). Hopefully, this PR should resolve that.How?
INDIRECT_PROPERTIES_METADATA
array to the theme JSON class.remove_insecure_styles
.wp_filter_global_styles_post
(gutenberg_filter_global_styles_post
) so that we can test this change in Gutenbergwp_filter_global_styles_post
callbacks are registered, then de-register, and re-register the Gutenberg versions insteadTesting Instructions
Note: a quick way to test this PR is to place the following in
lib/init.php
in the Gutenberg plugin, rather than worrying about changing user capabilities:unfiltered_html
capability (e.g. a regular admin), you should be able to save root block spacing values in global styles, as well as block level spacing (e.g. set Buttons spacing, and axial row/column spacing for Social Icons).unfiltered_html
capability (or enable the KSES filters withadd_action( 'init', 'kses_init_filters' );
) you should now still be able to save root block spacing values in global styles, and block level spacing.Ensure tests pass:
Screenshots or screencast