Only add layout classes to inner wrapper if block is a container.

[tellthemachines]

What?

Fixes #48606. While working on this change I noticed the updates to this logic from the Core backport code review hadn't been copied over yet, and as they are fairly minor and touch the same part of the code I'm also including them here.

The actual fix is just updating the isset( $block['innerContent'][0] ) && 'string' === gettype( $block['innerContent'][0] condition to isset( $block['innerContent'][0] ) && 'string' === gettype( $block['innerContent'][0] ) && count($block['innerContent']) > 1

because if the number of items in $block['innerContent'] is less than or equal to 1, then either the block isn't a container for inner blocks, or it's a dynamic block such as Post Content or Navigation, in which case the logic to add classnames to the inner wrapper would have to be added in the block's custom PHP anyway.

Testing Instructions

1. Add layout-enabled blocks to a template: Query, Post Content, Social Icons, Buttons, Gallery, Navigation, Group, Columns, Comments Pagination;
2. Check that their layout classnames still render correctly in the expected wrapper;
3. Generate some posts via CLI using the deprecated Gallery block markup as outlined in Flex layout classes added incorrectly in deprecated gallery blocks. #48606;
4. Check that those posts don't have layout classes in unexpected places on the front end.

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

Flaky tests detected in 217f4dc.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4300006453
📝 Reported issues:

• [Flaky Test] should open a preview window for a new post #35387 in /test/e2e/specs/editor/various/preview.spec.js
• [Flaky Test] shouldn't conflict with server-side autosave #35176 in specs/editor/various/autosave.test.js

[peterwilsoncc]

Thanks for the quick fix, the explanation makes sense.

Testing notes:

• All deprecated gallery blocks are now showing the correct html markup (layout tag on parent)
• Current gallery blocks have correct mark up too -- tested columns, with a caption, standard
• Following current blocks also appeared to behave as expected
  • Social Icons
  • Query (various layouts)
  • Buttons
  • Group
  • Column
  • Navigation
  • Comments (specifically checked pagination per shoutout in PR description)

I've approved the PR but would appreciate a logic check from someone who spends more time in the Gutenberg repo if possible.

[andrewserong]

Thanks for opening this one! The logic looks good, but in testing the linked markup, it looks like there's still a classname being injected for is-layout-flex — I'm not sure if I've made a mistake while testing, though:

I'll see if I can get a bit more info...

Update: I was going way too quickly, I copied from the result instead of from the source when adding the test markup in my local environment 🤦

[andrewserong]

LGTM, the logic looks good, and this is testing well for me with all the mentioned current core blocks, and the deprecated versions of the gallery block 👍

Thanks for the quick fix! ✨

[Mamaduka]

@tellthemachines, do we need to backport this into the release branch? Based on the description, the fix is already in the core.

[andrewserong]

@Mamaduka I believe there's a one-liner that appears to need to be backported — it's easy to miss, though, since it's a fix to the code that's in core, so I think this PR needed to migrate over the core code first before adding the fix. (Please correct me if I got that wrong @tellthemachines!)

The actual fix is just updating the isset( $block['innerContent'][0] ) && 'string' === gettype( $block['innerContent'][0] condition to isset( $block['innerContent'][0] ) && 'string' === gettype( $block['innerContent'][0] ) && count($block['innerContent']) > 1

[tellthemachines]

Thanks for the reviews folks!

I think this PR needed to migrate over the core code first before adding the fix.

Yes that's correct.

@Mamaduka it's probably a good idea to add it to the release branch in Gutenberg for consistency. I'm happy to prepare the core patch for it!

[Mamaduka]

Thank you, @tellthemachines! The core patch would be appreciated 🙇

[tellthemachines]

Done: WordPress/wordpress-develop#4149

[ntsekouras]

I just cherry-picked this PR to the wp/6.2 branch to get it included in the next release: 0367c43