-
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
Block Supports: Extend stabilization to common experimental block support flags #67018
Block Supports: Extend stabilization to common experimental block support flags #67018
Conversation
Size Change: +147 B (+0.01%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
@@ -2,3 +2,4 @@ https://github.com/WordPress/wordpress-develop/pull/7069 | |||
|
|||
* https://github.com/WordPress/gutenberg/pull/63401 | |||
* https://github.com/WordPress/gutenberg/pull/66918 | |||
* https://github.com/WordPress/gutenberg/pull/67018 |
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.
The plan is to backport all the block support stabilization updates in a single core PR as the PHP changes there will be done within relevant classes rather than via filters like the Gutenberg PRs.
A single core commit will make debugging and tracing changes much easier as well.
I've kept this PR in a draft status for the moment. It would benefit from some additional testing and depends upon #66918 merging first anyhow. |
@@ -88,79 +88,7 @@ describe( 'processBlockType', () => { | |||
radius: true, | |||
style: true, | |||
width: true, | |||
__experimentalDefaultControls: { |
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.
There was quite a bit of overlap and duplication between some of the test cases. I've consolidated some tests to keep things a little more concise as well as grouped relevant tests for deprecations within their own describe block.
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. |
I've flagged this as ready for review although the plan is still to merge #66918 first then rebase this accordingly. For now, my initial testing looks promising. I've taken multiple blocks with various default controls and serialization configs for a spin and they appear to be behaving for me. Adding several filters for block type args to my test theme works as expected given known limitations (i.e. end result can't be 100% accurate when there are repeated modifications of both the experimental and stable flags in differing orders via filters). |
b1e58d6
to
8b92b76
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.
This is working well in testing! I have mostly questions on the code at this point, trying to understand how it all works 😄
Flaky tests detected in f502d30. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11947309560
|
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.
I went through the testing steps and the changes are working as described when I mixed up the __experimental*
and stable support keys.
Doc changes are 👍🏻
I'm not sure what more feedback or testing you need - let us know what would help, but if it's good with @tellthemachines, then it also LGTM.
On a side note, do you think it's worth advertising on the Core blog that stabile keys are a thing, and, I assume should be preferred? Or is there more stabilization to come?
Thanks for the review @ramonjd 👍
If we've had a few people go through the PR test instructions and we can't see any obvious gaps, I think we might be best served by getting this into Gutenberg and testing more in the wild. I believe it should be fine, known issues for extreme edge cases aside e.g. repeated mix-and-match filtering using varied experimental and stable keys.
For sure. I was expecting we'd post on the dev blog and provide a release dev note at least. I wanted to touch base with @ndiego, @justintadlock, and @bph, to tap their collective wisdom on the best way to communicate all this. Especially due to the edge cases if multiple plugins filter block supports with different keys. In terms of more stabilization to come, I'm not 100% sure at this stage. The There appear to be quite a few other random experimental top level block support keys e.g.
All of those are probably much more niche use cases and less likely to be leveraged by 3rd party devs. Their stabilization should be a simple addition to the stabilization maps added in this PR, when the time comes. Long story short, for now I think the main goal is stabilizing the block supports used for design tools. This PR pretty much gets that done. |
Sounds good to me. Great stuff. |
I'll merge this and get to work in earnest on the combined backport for all the recent stabilizations. |
Any plans on adding some documention about |
Absolutely. It's already in the works although I've paused publishing docs, block.json schema updates, and dev notes until the backport and now potentially the relocation of I'll update and close the loop here when they're published. The tracking of block support stablization is covered by: |
Quick update: As discussed in #67729 (comment), the approach to block support stabilization needs more time so will likely be punted from 6.8. There is a revert PR available (#68163) and anyone interested in stabilized block supports is advised to follow that for the latest 🙏 |
…alization and default controls supports (#68163) * Revert "Global Styles: Fix handling of booleans when stabilizing block supports (#67552)" This reverts commit 4335c45. * Revert "Block Supports: Extend stabilization to common experimental block support flags (#67018)" This reverts commit 5513d7a. * Revert "Borders: Stabilize border block supports within block processing (#66918)" This reverts commit b5ee9da. * Revert "Process Block Type: Copy deprecation to a new object instead of mutating when stabilizing supports (#66849)" This reverts commit 457fcf8. * Revert "Typography: Stabilize typography block supports within block processing (#63401)" This reverts commit 48341a1. Co-authored-by: aaronrobertshaw <[email protected]> Co-authored-by: ramonjd <[email protected]> Co-authored-by: talldan <[email protected]>
Part of:
Depends on:
What?
Extends the approach to block support stabilization in #66918 to also stabilize shared/common experimental block support flags such as:
__experimentalSkipSerialization
__experimentalDefaultControls
Why?
These experimental flags have been around a long time and are extensively used throughout core blocks. It's time to stabilize them to increase confidence for extenders and better document what is possible.
How?
__experimentalSkipSerialization
within the filtered results due towp_should_skip_block_supports_serialization
in core only checking__experimentalSkipSerialization
. It will have to stick around in the Gutenberg filter until 6.8 is the minimum supported version.Next Steps
Update uses of__experimentalSkipSerialization
and__experimentalDefaultControls
within Gutenberg's block supportsFuture follow-ups
Testing Instructions
Warning: This is likely going to need considerable testing!
Screenshots or screencast
There should be no visual differences in blocks between this PR and trunk. Any found are regressions.