Block Supports: Extend stabilization to common experimental block support flags #67018
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
aaronrobertshaw
added
[Type] Enhancement
This was referenced Nov 19, 2024
|
Size Change: +147 B (+0.01%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
aaronrobertshaw
commented
Nov 19, 2024
| @@ -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.
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.
aaronrobertshaw
changed the title
|
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. |
aaronrobertshaw
commented
Nov 20, 2024
| @@ -88,79 +88,7 @@ describe( 'processBlockType', () => { | |||
| radius: true, | |||
| style: true, | |||
| width: true, | |||
| __experimentalDefaultControls: { | |||
There was a problem hiding this comment.
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.
aaronrobertshaw
requested review from
spacedmonkey,
tellthemachines,
ajitbohra,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
|
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). |
aaronrobertshaw
changed the title
This was referenced Nov 20, 2024
Base automatically changed from
update/stabilize-border-block-supports
to
trunk
November 20, 2024 07:56
aaronrobertshaw
force-pushed
the
update/stabilize-common-block-support-flags
branch
from
b1e58d6 to
8b92b76
Compare
|
Flaky tests detected in f502d30. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11947309560
|
ramonjd
approved these changes
Nov 25, 2024
There was a problem hiding this comment.
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. |
aaronrobertshaw
deleted the
update/stabilize-common-block-support-flags
branch
|
Any plans on adding some documention about |
fabiankaegy
added
the
Needs Dev Note
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: |
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.
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__experimentalDefaultControlsWhy?
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?
__experimentalSkipSerializationwithin the filtered results due towp_should_skip_block_supports_serializationin 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__experimentalSkipSerializationand__experimentalDefaultControlswithin 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.