A client came to me recently with what sounded like a small request: they wanted a custom “mini-cart” block sitting inside their main navigation menu. The trouble is that WordPress’s Navigation block is fussy about what you can put in it. By default it only really wants standard links, so anything more creative runs into a wall. They had tried forcing it with some dodgy CSS, which turned into a mess in the editor and broke the layout at certain screen sizes. So we sat down to work out how to extend the Navigation block properly.
The Navigation block is built to be a navigation tool, not a free-form content area. That is good for stability, but it gets in the way the moment you want something custom in there, like a live cart summary or a login form. My first instinct was to tell the client to live with it, or maybe inject the extra block with some JavaScript after the page loaded. That is fragile, though, and it turns future maintenance into a headache. This was an editor problem, so it needed a fix at the editor level.
Extending navigation blocks: the proper hook
The fix comes down to how Gutenberg registers and manages blocks. You tap into the blocks.registerBlockType filter and extend the allowedBlocks property of the core/navigation block. This is not a hack; it is a built-in WordPress mechanism for extending what a block can do. You load your custom JavaScript with the enqueue_block_editor_assets hook so the script runs in the block editor, which is where it is needed. That lets you tell the editor that the navigation block can now accept another block type as well. It is clean, easy to maintain, and it works inside the editor rather than around it.
add_action( 'enqueue_block_editor_assets', function() {
wp_enqueue_script(
'my-agency-extend-navigation-script',
plugins_url( 'js/editor-script.js', __FILE__ ),
array( 'wp-hooks', 'wp-blocks' ), // Dependencies for block filters.
'1.0.0',
true
);
} );With that PHP snippet in place, you need the JavaScript. Create an editor-script.js file inside a js folder in your plugin. You can do this in a theme instead, but a plugin is usually the better home for this kind of functionality. The script hooks into the blocks.registerBlockType filter. There is a good example of it on developer.wordpress.org, which is what this method is based on.
const addToNavigation = ( blockSettings, blockName ) => {
if ( blockName === 'core/navigation' ) {
return {
...blockSettings,
allowedBlocks: [
...( blockSettings.allowedBlocks ?? [] ),
'core/image', // Replace with your custom block or desired core block, e.g., 'my-plugin/mini-cart'
],
};
}
return blockSettings;
};
wp.hooks.addFilter(
'blocks.registerBlockType',
'my-agency-add-block-to-navigation',
addToNavigation
);See that 'core/image' part? That is where you put the name of whatever block you want to add. For my client it would have been the custom mini-cart block. This tells the Navigation block that it can now accept images too, or a custom mega menu block, or a user profile widget, whatever you define. It opens the block up without breaking anything. It is a solid way to handle custom requirements in the block editor, especially with core blocks that keep a strict allowedBlocks list. Try to hack around those limits instead and it will bite you later.
So, what’s the point?
The takeaway is simple: do not fight the editor. When WordPress gives you hooks and filters, use them. Forcing editor behaviour with CSS or sketchy JavaScript injections is a nightmare for whoever has to maintain the site later. Extending the navigation block this way is only a few extra lines of code, but it holds up over time and makes life easier for you and the client. Custom elements sit in the navigation the way they were meant to.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
