Skip to content
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

Conversation

andrewserong
Copy link
Contributor

@andrewserong andrewserong commented Jan 30, 2023

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 include dimensions.minHeight under supports, and then add the following block markup to a template in the site editor (e.g. the single template):

<!-- wp:post-content {"style":{"dimensions":{"minHeight":"80vh"}},"layout":{"type":"constrained"}} /-->

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 to 80vh. 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.

Copy link
Contributor

@costdev costdev left a 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 🙂

tests/phpunit/tests/block-supports/dimensions.php Outdated Show resolved Hide resolved
tests/phpunit/tests/block-supports/dimensions.php Outdated Show resolved Hide resolved
@@ -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 );
Copy link
Contributor

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:

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?

Copy link
Contributor

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.

Copy link
Contributor Author

@andrewserong andrewserong Jan 30, 2023

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?

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.

Copy link
Contributor

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: Colin Stewart <[email protected]>
Copy link

@ntsekouras ntsekouras left a 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.

@hellofromtonya
Copy link
Contributor

Status: Currently reviewing and testing for commit consideration.

@@ -0,0 +1,104 @@
<?php
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

@costdev costdev Feb 1, 2023

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 the get_comment_class() function, is located in tests/comment/getCommentClass.php.

What I'm not sure about though, is whether {Group} should be BlockSupports, or Block_Supports, i.e.

  • Tests_BlockSupports_WpApplyDimensionsSupport OR
  • Tests_Block_Supports_WpApplyDimensionsSupport

Copy link
Contributor

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.

Copy link
Contributor

@costdev costdev Feb 1, 2023

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. 🙂

Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Capitalization done here 12cebb4. Thanks @costdev!

Copy link
Contributor

@hellofromtonya hellofromtonya left a 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 🟢

@hellofromtonya
Copy link
Contributor

@andrewserong
Copy link
Contributor Author

Wonderful, thank you for landing this one, and for the extra discussion, I learn more with each of these PRs 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants