Allow setting defaultBlock in navigation block

[sethrubenstein]

What?

Create a defaultBlock attribute and sets innerblocks to reference that if attributes are present in it.

Why?

Solves for #50982

How?

This adds a new defaultBlock attribute and a check for it along with a quick sanity check if it fails it falls back to the DEFAULT_BLOCK constant.

Testing Instructions

• Open a post or page
• Copy and paste this block markup into the editor:

<!-- wp:navigation {"defaultBlock":{"name":"core/navigation-link","attributes":{"type":"category","kind":"taxonomy"}}} /-->

• Click + inside the navigation block.
• Now category links should be the default when clicking + inside this navigation block.

[scruffian]

It seems like this only works with variations of the navigation link block. Could we also make it work for all blocks that are allowed inside the navigation block?

[sethrubenstein]

@scruffian It defaults to core/navigation-link, it's current default behavior but you could do any block thats supported inside the navigation block, like:

<!-- wp:navigation {"defaultBlock":{"name":"my-custom/nav-block","attributes":{"myValue":"xyz"}}} /-->

[scruffian]

That didn't work in my testing but maybe I was doing it wrong!

[sethrubenstein]

You are correct @scruffian, because the allowedBlocks are set as a constant at https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/navigation/constants.js#L5 this will only work for the blocks listed therein. I agree it would be nice to extend that as well, and I believe there is other work underway to standardize around an allowedBlocks attribute #52467, when that work is complete along with this work your use-case will be possible.

CleanShot.2023-07-14.at.12.52.40.mp4

[scruffian]

I was trying it with the search block, which is an allowed block, so I would expect it to work...

[sethrubenstein]

Hi @scruffian Just checking back on this, I'm able to get the search block to work, are you passing in something for attributes? In this implementation I'm only passing in the defaultBlock attribute if you give more than just a name, so that the DEFAULT_BLOCK behavior is respected for the time being except for very explicit use cases.

CleanShot.2023-07-25.at.22.05.18-converted.mp4

[github-actions]

⚠️ Type of PR label error

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Accessibility (a11y), [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Performance, [Type] Project Management, [Type] Security, [Type] WP Core Ticket.
• Labels found: [Block] Navigation.

[draganescu]

One thing to test is that when the navigation block includes other blocks than navigation link the auto insert behavior is turned off. Maybe we should just customize the variation of the navigation link? Like defaultLinkType instead of defautlBlock?

[scruffian]

Ah yes, it wasn't working because I hadn't specified attributes. It does work now.

One thing to test is that when the navigation block includes other blocks than navigation link the auto insert behavior is turned off

This is still the case.

[scruffian]

I think this is good to go.

[draganescu]

I am not sure about this. @sethrubenstein could you consider my idea of the attribute being only for the variation of the navigation link, not for specifying any block? It's just a too finicky for a public API for any block considering we have an allowedBlocks list and that specifying anything other than the navigation link disables the behavior which this PR aims to improve.

What do you think?

[sethrubenstein]

@draganescu yeah that works by me. I need to catch up on the auto insertion apis. All I'm really trying to solve for is when you click plus on the nav block to insert a specific variation (in our case the category link variation) of the navigation link block. Let me investigate best way to do that now that there's this insertion api and I'll modify this PR accordingly.

[colorful-tones]

I'm trying to catch up on all things defaultBlock, but I missed a lot. However, I'm currently trying to get it to work in useInnerBlocksProps, and it will not work at all. Do you know if it only works with the Navigation block? That seems odd, and the README should likely be updated with a pertinent example (if so). 😕

Maybe I'm just missing that defaultBlock does not exist in WordPress core yet because I'm just running WP 6.4.1 and creating a custom block with useInnerBlocksProps and getting nowhere.

[sethrubenstein]

@colorful-tones Yeah unfortunately this isn't going to work with Nav block currently. We stabilized the defaultBlock api point in 6.4 so it should be available but I realize now I had the syntax wrong on the docs and need to update that asap. The correct syntax for defaultBlock is {name: 'my/block-name', attributes: { content: 'This block has some predefined content when clicking to insert it into the editor'}} and of course have directInsert set to true as well.