Update the rules to hide/show blocks in the global styles sidebar #35178
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: +39 B (0%) Total Size: 1.06 MB
ℹ️ View Unchanged
|
|
For context, we removed that restriction for themes at #29941 I've just checked the styles section of a couple of themes and I see that they use the following styles for which the block doesn't declare support: TT1-blocks:
Quadrat:
|
|
The rationale to remove that requirement for themes was that they could experiment at a higher pace than we could add supports for the blocks. The responsibility for checking that it worked was shifted to the themes, I'm not sure it's a good thing to expose users to this burden. I'd argue the properties I've shared above should be added as block supports to the blocks at some point (even if we want to hide them by default from the user in the block sidebar). Essentially, my concern is: if we show the panels, isn't the expectation that they work? And if they don't work, isn't this a bug? |
|
An alternative approach is to create the panel/properties if any of this happens: the block supports the property or the theme styles the property. If the theme is styling the property, it probably works, so we could be optimistic about exposing that to users. |
I agree with this way of seeing things. I also worry about another point:
What if theme.json does not use some block supports at all but the block supports it? The user will not be able to use some customization ability that should be possible right? |
|
Yeah, I see the points. I'm still uncertain as well. I think I can scale this down to this to start with:
|
91d60ca to
c7824ff
Compare
|
Ok, I restored the checks and only left the removal of blocks with no visible panels. This should be ready for another review. |
Addison-Stavlo
approved these changes
Sep 29, 2021
There was a problem hiding this comment.
The logic looks good, and the behavior is working well in my testing.
I activated a couple of plugins that add a ton of blocks that don't support styling, and this greatly clears up the blocks selection menu by removing them as expected!
Thanks for getting to this so quickly! 🎉
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.
This changes the rules of whether to show the block panels in the global styles sidebar in two ways:
Edit: The second point above has been reverted (see discussion)