Allow the Layout Panel in the Inspector Controls to be customizable

[sunyatasattva]

What?

This PR allows users to hook into the Layout Panel of the Inspector Controls to add their layout-related options for their block.

Why?

The Inspector Controls already allow to hook into most generic panels (i.e. panels that automatically get added to most blocks). The Layout is missing among those, while many blocks likely have some sort of layout options that it would make sense to group together instead of having a different layout panel (for example, in WooCommerce, we have this).

In general, I'd say the Layout Panel is the outlier in that is not hookable.

How?

It's as simple as adding a SlotFill. No big changes required.

Testing Instructions

1. Create a block or select an existing block.
2. Add some code like the following to your render function.

<InspectorControls __experimentalGroup="layout">
  // Add anything you like here…	
</InspectorControls>

3. Select your block and make sure the new controls appear at the bottom of the Layout panel.

[Mamaduka]

Thanks for the proposal, @sunyatasattva!

I'm unsure if the special SlotFill is needed for the use case you linked in the description. The "Query" block has similar settings in the block toolbar. Another option is to add new "Settings" panel to the sidebar.

P.S. The block-specific settings won't be displayed when the theme doesn't support the layout.

Screenshot

[andrewserong]

Thanks for exploring this idea! One of the challenges with exposing a slot within the LayoutPanel is that there are a number of proposals to change the panel quite considerably, which would likely impact any plugins expecting their controls to be displayed within it. For example, there's an open issue to explore refactoring to the ToolsPanel (#44560) and previously explorations into doing that (#48533).

I think, personally, I'd lean toward waiting until the Layout panel and controls have stabilised a little further, especially with some of the ideas surrounding consolidating Layout controls with other controls, but I'd be curious to hear what @tellthemachines thinks, too.

P.S. The block-specific settings won't be displayed when the theme doesn't support the layout.

That's a good point. At this stage I imagine it's probably safer for plugins to use their own panel rather than attempt to hook into the Layout panel, but I do see the value in consolidating. Possibly once the Layout block support has been stabilised?

[tellthemachines]

In general, I'd say the Layout Panel is the outlier in that is not hookable.

Currently, layout is an outlier in its behaviour on all fronts: it only exists on container blocks, its controls mostly apply to container children as opposed to the block itself, and as @Mamaduka pointed out it can be disabled at a theme level separately from all the other controls. It also has limited effect on classic themes: some layout types only exist on block themes.

It's possible this will change with the explorations @andrewserong mentions above, and I agree it's best to postpone adding any slots until after the panel (and the wider layout support) is stabilised. This is a work in progress tentatively targeting 6.3, so it shouldn't be too much longer.

In the meantime, looking at the design shared on that woocommerce issue, I can't help wondering if the problem would be solvable with an existing layout type such as flex, or perhaps the upcoming Grid layout: #49018. In particular, I'm curious about how the "number of columns" option should work: will it always display a static column number, and stack on mobile like the core Columns block? Or will it have a more fluid responsive behaviour?

Thinking about the problems extenders face can be super helpful to inform progress on layout features in core, so I hope you don't mind sharing a bit more about that particular case 😁

[aaronrobertshaw]

Thanks for the proposal @sunyatasattva 👍

I'd like to echo some of the previous sentiments made by @andrewserong and @tellthemachines and hopefully add some smaller points about how we might eventually offer a layout slot.

There are a couple of issues at play that I think are worth highlighting so we're all on the same page.

• The layout panel isn't representative of an InspectorControls slot (yet).
• The layout panel is only rendered as a fill into the default InspectorControls slot.
• This panel only currently has the layout block support controls but it does make sense that all layout-related controls are within a single panel
• Because the proposed slot is to be rendered via the layout block support hook, that's why theme.json disabling the block support UI would then also prevent the display of other controls injected there.

If a layout InspectorControls group was to be added, I believe it would come with expectations it would be consumed as per the other groups. With the exception of default, advanced, and position, they will all render their own ToolsPanel.

If there is to be a layout panel and layout group, that would detach the display of layout-related controls from whether the layout block support UI was enabled. The block support controls would then be rendered into that group's panel and it would no longer matter if the block in question was a container block or not. If that slot had fills, the panel renders.

For us to be able to offer the layout panel and group, we'd first need the layout panel migrated to a ToolsPanel, which as @andrewserong noted, is being explored. How that shakes out when we also continue to look at consolidating layout controls with other panels e.g. Dimensions, is still a bit unknown.

So my vote would also be another +1 to waiting on the layout panel to settle and hopefully be migrated to a ToolsPanel.

Further to this PR, there was also some recent discussion around potentially relocating the layout panel within the Block Inspector which itself would require the layout group to be added to the InspectorControls.