Allow parent blocks to expose specific child toolbar controls

[scruffian]

What?

Adds granular control over which parent block toolbar controls are exposed when a child block is selected.

Parent blocks can keep using supports.__experimentalExposeControlsToChildren: true to expose every control that opts into child sharing. They can now also pass an allow-list, for example supports.__experimentalExposeControlsToChildren: [ 'media' ], and controls can opt into that list with __experimentalShareWithChildBlocks="media".

This also updates the Playlist block to use the new granular behavior so its Add media control is owned by the parent Playlist block while still appearing for selected Playlist Track children.

Why?

Some parent blocks need to share one specific toolbar control with child blocks without exposing every parent control that has opted into child sharing.

For Playlist, this avoids plumbing the add-tracks callback through child block context just so each Playlist Track can render the parent's Add control.

How?

• Carries the raw __experimentalExposeControlsToChildren support value through block edit context as either true, an allow-list, or false.
• Allows BlockControls fills to name shared child controls with __experimentalShareWithChildBlocks="name".
• Checks named controls against the parent allow-list before rendering them in the child toolbar slot.
• Captures child toolbars when the parent exposes all controls or a non-empty allow-list.
• Moves Playlist's Add media toolbar control back to the parent Playlist block and exposes only the media control to child tracks.

Testing Instructions

Automated tests

Run:

npm run test:unit -- packages/block-editor/src/components/block-controls/test/index.js packages/block-editor/src/components/inner-blocks/test/index.js packages/block-library/src/playlist/test/edit-component.js

Confirm all suites pass.

Manual smoke test: legacy boolean behavior

1. Start the environment if it is not already running:

   npm run wp-env status
   npm run wp-env start

2. Open the editor and insert a parent block that already uses supports.__experimentalExposeControlsToChildren: true, such as Buttons.

3. Select a child block inside that parent, such as an individual Button block.

4. Confirm the parent toolbar controls that were previously shared with child blocks are still available.

5. Select the parent block directly and confirm its own toolbar controls still render as expected.

Manual smoke test: Playlist granular behavior

1. Open the editor and insert a Playlist block with at least one track.
2. Select an individual Playlist Track child block.
3. Confirm the Add media control appears in the child toolbar.
4. Confirm unrelated parent toolbar controls are not exposed to the Playlist Track child toolbar.

Screenshots

Note that now the playlist track toolbar appears in the same place as the playlist block toolbar:

Note

We should remove the playlist specific commit from the PR (9f8a5bf). This is just for testing.

Automated Tests Run

• npm run test:unit -- packages/block-editor/src/components/block-controls/test/index.js packages/block-editor/src/components/inner-blocks/test/index.js packages/block-library/src/playlist/test/edit-component.js

[github-actions]

Size Change: +52 B (0%)

Total Size: 7.72 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	422 kB	+64 B (+0.02%)
build/scripts/block-library/index.min.js	351 kB	-12 B (0%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 479392d.
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/29439955199
📝 Reported issues:

• [Flaky Test] Should save the changes #78689 in /test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js

[github-actions]

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: scruffian <scruffian@git.wordpress.org>
Co-authored-by: jeryj <jeryj@git.wordpress.org>

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

[jeryj]

I don't think this is working as intended. The alignment control is also being passed down through to the child track.

Also, I'm unsure about the overall API design here. Even if it does work as intended, the Add button has to go in it's own toolbar group, and I'm not sure that's the final design we'd want. I assumed it would go in the same group as "Add"

[scruffian]

I don't think this is working as intended. The alignment control is also being passed down through to the child track.

You're right. I've fixed this.

[scruffian]

Also, I'm unsure about the overall API design here. Even if it does work as intended, the Add button has to go in it's own toolbar group, and I'm not sure that's the final design we'd want. I assumed it would go in the same group as "Add"

Do you mean:

I assumed it would go in the same group as "Replace"?

I think it makes sense to be in its own group, since this action relates to the parent block. This is a question for @fcoveram and @jasmussen:

We already have a feature that allows parent blocks to optionally share their toolbars with child blocks - the buttons block is an example. This PR brings in the ability for parent blocks to decide which parts of the toolbar to share - rather than sharing all controls:

1. Do you think this is a valuable addition?
2. If so, does it make sense for the parent controls to go into a different "group" than the child block controls?

Thanks!

[jeryj]

I assumed it would go in the same group as "Replace"?

Yes, sorry. I thought they would go in the same group since they're about modifying the track list. I can see why the parent tools passed down should be in their own group for clarity.

[jeryj]

@scruffian Is the specific issue here that the alignment control gets passed through to the child, and you don't want that one to show? I think it might be fine for the alignment control to get passed through. It's pretty hard to discover anyways. And the playlist track block isn't full of custom controls, so I think it would be fine to just add __experimentalExposeControlsToChildren supports.

[scruffian]

Yes that was the issue i was trying to solve. Maybe you're right, we can just use __experimentalExposeControlsToChildren

[scruffian]

I'm doing that in #80368

[jeryj]

Closing in favor of #80368