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

Post Template: Ensure layout classnames are not attached to inner li elements #41827

Conversation

andrewserong
Copy link
Contributor

What?

Fixes #41026 by ensuring that the Layout block support for the Post Template block is only applied on the outer-most wrapper, and not on the first child of each instance of the inner query loop. This PR is an alternative to #41802.

Why?

Based on discussion in #41802, the Post Template block's inner li elements should not receive a Layout container classname. Within the Post Template block, there is a loop that iterates over the current query. For each instance of that loop, we need to output an li element with the block's inner blocks as the template.

Prior to this PR, the container Post Template block is rendered again for each of these inner instances, however this has an undesirable side-effect that the Post Template block's block supports are invoked an additional time for each of these instances of the loop, on the inner wrapper.

How?

When rendering the inner wrapper to contain the post template for each instance of the loop, set the blockname to a null name that does not correspond to any registered blocks. This ensures that no block supports are invoked on this inner wrapper element, effectively skipping all block supports for that inner wrapper, ensuring that Post Template block supports are only applied to the outer wrapper.

Testing Instructions

  1. Add a Query Loop block to a post
  2. In the Post Template, create some blocks to demonstrate what goes wrong if the Layout classname is erroneously added to a child block. For example, in the below screenshots, I've used a Columns block as the direct child of Post Template. In this case, it should be fairly obvious that the styling is incorrect, as the second Column will receive the margin-block-start gap of the default Layout type, adding an unexpected top margin on the second column.

Screenshots or screencast

In the Before screenshot below, note that the first child of the highlighted li element receives two container classnames (wp-container-12 and wp-container-11). In the After screenshot, it only receives the single wp-container-11 classname.

Before After
image image

@andrewserong andrewserong added [Type] Bug An existing feature does not function as intended [Block] Post Template Affects the Post Template Block labels Jun 21, 2022
@andrewserong andrewserong self-assigned this Jun 21, 2022
// This ensures that for the inner instances of the Post Template block, we do not render any block supports.
$block_instance['blockName'] = 'core/null';

// Render the inner blocks of the Post Template block, with `dynamic` set to `false` to ensure that no wrapper markup is included.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
// Render the inner blocks of the Post Template block, with `dynamic` set to `false` to ensure that no wrapper markup is included.
// Render the inner blocks of the Post Template block with `dynamic` set to `false` to prevent calling
render_callback and ensure that no wrapper markup is included.

This is a good comment! Saves folks searching around for API docs. Would it be worth adding that 'dynamic' => false skips render_callback to explain the how and the what?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, good suggestion! Yes, I think because of how unusual this block is, the more explanatory text, the better, to hopefully make it a little easier for anyone making future changes. I'll tweak the wording a little later today 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Committed in c8e2814. Thanks!


// Set the block name to one that does not correspond to an existing registered block.
// This ensures that for the inner instances of the Post Template block, we do not render any block supports.
$block_instance['blockName'] = 'core/null';
Copy link
Member

Choose a reason for hiding this comment

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

What would be the option for developers who would want block supports for core/post-template later?

Render them somewhere in the render callback?

Copy link
Contributor Author

@andrewserong andrewserong Jun 23, 2022

Choose a reason for hiding this comment

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

The supports still get rendered on the outer wrapper (this function is called with core/post-template) so the block supports are should still apply there (I think!).

I'm not too sure about how we'd handle styling for the inner wrapper to be honest — I think the best bet for pattern design would be to have a Group block as the first child of the inner wrapper, and then folks can use block supports there. I was almost wondering if we could use a group block instead of core/null, but that felt like going down a rabbithole that might be a bit broader in scope than solving the current bug 🤔

Longer-term, I'd love for us to figure out how to reliably get block spacing and block supports working nicely for styling up different kinds of post template layouts, though!

Copy link
Member

@ramonjd ramonjd left a 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 for me, and it looks unintrusive

It'd be great to get a ✅ from @ntsekouras just in case I'm missing something!

Before
Screen Shot 2022-06-23 at 11 57 51 am

After
Screen Shot 2022-06-23 at 12 07 06 pm

@andrewserong
Copy link
Contributor Author

Thanks for reviewing @ramonjd, much appreciated! And yes, it'd be good to get another pair of eyes on this, too, as the hack of using a core/null block name to ensure we render something that doesn't correspond to an existing registered block might seem a bit unusual. Though I guess this is an unusual block 😄

@ramonjd
Copy link
Member

ramonjd commented Jun 23, 2022

I think this PR will fix #41756 as well

@andrewserong andrewserong added the Backport to WP Minor Release Pull request that needs to be backported to a WordPress minor release label Jun 24, 2022
@andrewserong
Copy link
Contributor Author

@adamziel hope you don't mind the ping, but I wondered if you think this PR would be worth trying to get into WP 6.0.1? I've added the backport label, and I think @ramonjd and I believe this is ready to go, but wanted to get a second opinion from someone just in case, since it's a bit of an unusual fix 🙂

@adamziel
Copy link
Contributor

@andrewserong thanks for the ping, sounds good to me!

@andrewserong
Copy link
Contributor Author

Thanks Adam! Merging now 🙂

@andrewserong andrewserong merged commit 9a761d3 into trunk Jun 27, 2022
@andrewserong andrewserong deleted the fix/post-template-block-inner-block-instances-by-skipping-block-supports branch June 27, 2022 00:27
@github-actions github-actions bot added this to the Gutenberg 13.6 milestone Jun 27, 2022
adamziel pushed a commit that referenced this pull request Jun 30, 2022
…elements (#41827)

* Post Template: Ensure layout classnames are not attached to inner li elements

* Fix linting issue

* Clarify dynamic set to false comment.


Co-authored-by: ramonjd <[email protected]>
@adamziel
Copy link
Contributor

I just cherry-picked this PR to the wp/6.0 branch to get it included in the next release: d5c2f4f

@adamziel adamziel removed the Backport to WP Minor Release Pull request that needs to be backported to a WordPress minor release label Jun 30, 2022
@andrewserong
Copy link
Contributor Author

Thanks Adam! 🙇

@mburridge mburridge added the Needs Dev Note Requires a developer note for a major WordPress release cycle label Sep 14, 2022
@mburridge
Copy link
Contributor

Added the Needs Dev Note label in case this needs a dev note (either individual or as part of a "misc" dev note) for WP 6.1 release.

@andrewserong
Copy link
Contributor Author

Thanks for following up — for this one, I'm not sure that it needs a dev note as it's a bug fix for the internal behaviour of the Post Template block, rather than a change to how the layout support works, which will be covered in other dev notes. Let me know if you think there is something that needs to be captured here, though!

@mburridge
Copy link
Contributor

Thanks @andrewserong, I was going through a whole load of PRs so had to make a quick judgement call on each one. This one appeared to change the rendered markup so I added the Needs Dev Note label just in case. Feel free to remove it if you think no dev note is needed.

@andrewserong andrewserong removed the Needs Dev Note Requires a developer note for a major WordPress release cycle label Sep 15, 2022
@andrewserong andrewserong added the [Feature] Layout Layout block support, its UI controls, and style output. label Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Post Template Affects the Post Template Block [Feature] Layout Layout block support, its UI controls, and style output. [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

An extra container class is getting added to the first element of each Query Loop
4 participants