-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Backport min-height block support feature #3940
Backport min-height block support feature #3940
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.
Thanks for the PR @andrewserong! I've left few thoughts below 🙂
@@ -29,8 +29,7 @@ function wp_register_dimensions_support( $block_type ) { | |||
return; | |||
} | |||
|
|||
$has_dimensions_support = block_has_support( $block_type, array( '__experimentalDimensions' ), false ); | |||
// Future block supports such as height & width will be added here. | |||
$has_dimensions_support = block_has_support( $block_type, array( 'dimensions' ), false ); |
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.
Results from a wp.org search:
- 0 plugins found using
__experimentalDimensions
https://wpdirectory.net/search/01GR1JTT957N4BM1FAZAHPCQ1C - 0 themes found using
__experimentalDimensions
https://wpdirectory.net/search/01GR1JX1E9HM3BQQQ0GJ457B68
So I'm wondering:
- What are the backwards-compatibility risks for users who may have a custom plugin or theme using it?
- How was
'__experimentalDimensions'
previously exposed and used? - What is the mitigation plan for
'__experimentalDimensions'
to upgrade blocks using this setting?
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.
One way to mitigate:
- Check it here with an
||
. - Throw a deprecation notice to alert to use the new
'dimensions'
instead.
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 raising this one @hellofromtonya — this is a pretty interesting case for stabilisation in that the support technically existed prior to this PR (with the name __experimentalDimensions
) however it was a no-op, in that it didn't actually expose any controls or styles. So even if a plugin had opted in to using it (which is pretty unlikely), there would have been no behaviour from it. Because min-height
is a new feature, and the dimensions controls were never exposed or promoted anywhere, I don't think we need to add any handling to deal with the former __experimentalDimensions
name — it appears it was mostly there as a placeholder in code for future features.
What do you think?
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.
If it was a no-op, I think we're good to leave it as is.
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.
Thank you @andrewserong and @ntsekouras for the explanation.
tl;dr
No BC concern.
Let me summarize the reasoning:
- Yes, this
__experimentalDimensions
setting existed before 6.2. - It did nothing. No functionality was attached to it. (think of it as placeholder for the future, ie today)
- If a developer is using it, there is no effect to them for removing it.
I agree then. It's not a BC concern to remove it. Thank you!
Co-authored-by: Mukesh Panchal <[email protected]>
Co-authored-by: Colin Stewart <[email protected]>
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.
Thank you @andrewserong !
I have manually tested the front end by adding
<!-- wp:post-content {"style":{"dimensions":{"minHeight":"80vh"}},"layout":{"type":"constrained"}} /-->
and adding the support in the block, and works as expected in the front end - that means applying the minHeight
styles.
Status: Currently reviewing and testing for commit consideration. |
@@ -0,0 +1,104 @@ | |||
<?php |
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 file and the class need renaming for Core's Test coding standards and consistency.
- File
wpApplyDimensionsSupport.php
- Test Class:
Tests_Block_Supports_wpApplyDimensionsSupport
Will push a commit shortly.
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.
Whoops forgot to share the naming convention:
For the file:
It's the function's name in camelCase without the _
.
For the test:
It's in this format:
Tests_{group}_{functionNameInCamelCase}
See handbook here https://make.wordpress.org/core/handbook/testing/automated-testing/writing-phpunit-tests/#test-classes for more information.
Note: In Gutenberg, more work is needed in the linting before its tests can be converted into Core's coding standards.
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.
@hellofromtonya According to the handbook, it says the test class should be in this format:
Tests_{Group}_{FunctionNameInTitleCase}
Thus, the class
Tests_Comment_GetCommentClass()
, which contains tests for theget_comment_class()
function, is located intests/comment/getCommentClass.php
.
What I'm not sure about though, is whether {Group}
should be BlockSupports
, or Block_Supports
, i.e.
Tests_BlockSupports_WpApplyDimensionsSupport
ORTests_Block_Supports_WpApplyDimensionsSupport
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.
@costdev The other test in the group has it as Block_Supports
. So I felt it that way for consistency and because the handbook is unclear if the group should also be smooched together. Thinking that topic needs a Trac ticket of its own to discuss and get consensus.
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.
Regarding _Wp
rather than _wp
, see this ticket with support for encouraging Wp
for consistency among all test classes, despite there being more cases of _wp
in the test suite historically. I'm happy to go with what you decide regarding the capitalization after viewing the ticket. 🙂
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.
Oh wait I do see what you mean though about capitalizing the first letter of the function's name. Yup that needs changing. Good catch. Will do that in the commit.
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 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.
- Confirmed the PHP changes from the GB PRs are here ✅
- Confirmed there's no BC issue for the removal of
__experimentalDimensions
setting ✅ - Reviewed for coding standards ✅
- Tests are okay ✅
- @ntsekouras tested it ✅
LGTM 👍 Will prepare the commit once the CI jobs finish and are 🟢
Committed via https://core.trac.wordpress.org/changeset/55175. |
Wonderful, thank you for landing this one, and for the extra discussion, I learn more with each of these PRs 🙂 |
This PR backports the minimum height block support feature's PHP changes from Gutenberg. Those changes were originally merged in the following PRs:
The opting-in of the block support for particular blocks, and UI support will land separately as part of the main JS package update for 6.2 — hopefully, this PHP change should be able to safely land in isolation.
Trac ticket: https://core.trac.wordpress.org/ticket/57582
Aside from the included tests, I'm not sure if there's a reasonable way to test this prior to the JS packages update landing, since that will also include the block support opt-ins for group and post-content blocks. However, it might be possible to manually update the
block.json
file for the post template block to includedimensions.minHeight
under supports, and then add the following block markup to a template in the site editor (e.g. the single template):On the site-frontend (assuming the site editor allows you to save the above block markup), the post content block should be rendered with
minHeight
set to80vh
. If this doesn't work in manual testing, however, then we might need to wait until the JS packages have been updated before testing manually.This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.