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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: kmanijak <[email protected]>
Co-authored-by: mikachan <[email protected]>
Co-authored-by: Mamaduka <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Disclaimer: This is not a full review. I was just looking at recent PRs.

Using the editor.BlockEdit filter to just change the position of the controls for the same block type doesn't feel like a good practice.

@Mamaduka , thanks for the tip with key! Wasn't aware of the potential problem. 🙌

Using the editor.BlockEdit filter to just change the position of the controls for the same block type doesn't feel like a good practice.

Valid concern, but is there any other way to achieve it? In this case there's strong UX justification to push a setting above the "native" Layout section.

When it comes to specific block UX justifications vs consistency across the blocks, I lean towards the latter.

Having a more declarative way for blocks to render their custom "Block Styles" controls could be a nice approach, which, if understood correctly, is what we're trying to do.

Using a filter also doesn't guarantee the positioning of a control. The core controls can change and give us a different order.

Actually @mikachan , in ideal world we should probably use supports.layout.allowSwitching: true flag instead and get rid of custom controls completely. But in current shape there's too many options and for some reason Layout section disappears. However, it may be related to custom implementation now and with some tweaking we could make it work. I may try in separate PR:

in ideal world we should probably use supports.layout.allowSwitching: true flag instead and get rid of custom controls completely

Nice! I've tried this out in #71488. It's working OK, but there doesn't seem to be much control over the layout options via the block. How important do we think it is that the grid option is still available when "Show hierarchy" is true? At the moment, "grid" is disabled if "Show hierarchy" is true.

I guess it's unlikely that folks would choose a layout option that doesn't work well with the terms query they've selected, so maybe giving the users complete control over the layout options is fine.

How important do we think it is that the grid option is still available when "Show hierarchy" is true? At the moment, "grid" is disabled if "Show hierarchy" is true.

Ah, I see. Always a tradeoff 😅 I think it's alright to keep it enabled and give control and leave the responsibility to users in this case.

maybe giving the users complete control over the layout options is fine.

Yeah! This!

Given we'll most likely go with the native option I'm closing this PR. 🙌