[WIP] Allow setting allowedBlocks on Navigation block via attribute #52467
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is an interesting PR. Searching through Gitbug we have a slew of issues about how allowed blocks in inner blocks should be improved:
Also I am unsure opening up the navigation block like in this PR is a good idea for another reason I remember stumbling upon recently: the rendered expects only certain kinds of blocks to be available and adds HTML wrappers depending on block name. Some plugin authors complained that their custom block would not get a wrapper. So if we want to allow customising the inner blocks of the navigation block I think we should lean more into changing how innerblocks themselves work - and also coming up with a renderer for inner blocks that always works. |
|
Size Change: +22 B (0%) Total Size: 1.43 MB
ℹ️ View Unchanged
|
Yes there is a fair amount of demand for this.
Yes exactly what I discovered (see |
|
Related Issue to refactor PHP render code for the block should help here. |
|
Flaky tests detected in 347a3f0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5507037347
|
|
I think allowed blocks should be extendable as a root prop in block json not as an attribute. That would be a solution that solves for all blocks and something which must be supported 1st class by block renders (or explicitly opted out of). |
|
I don't have bandwidth to pursue this PR at this time. Moreover it sounds like this will be solved at a more systemic level. I will close out but feel free to reopen if anyone feels able to take it on. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
PoC for allowing setting a set of allowed blocks on the Nav block using an attribute `allowedBlocks.
Closes #31387
Why?
Because people want to customise the Nav block. See #31387.
How?
Following existing examples such as #49128.
Problems
The current issue with this approach is that unlike many blocks, the Nav block actively manages it's inner blocks on server side render.
So instead of just "render these inner blocks" the Nav block will loop over the inner blocks and actively manage their markup. I believe this is for accessibility reasons.
There's probably a good case for moving away from this approach but that would need to be a seperate PR.
Testing Instructions
Problemsabove.Testing Instructions for Keyboard
Screenshots or screencast