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?

@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"}}} /-->

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

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.

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

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.

⚠️ 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.

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?

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.

@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.

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.

@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.