FSE Navigation Block Woes

This post is mainly to provide feedback to the FSE-Outreach team and document a specific workflow issue. If you have thoughts on how you’d solve this, please please please let me know!

I’m having an issue with our Site Editor workflow for Headers / Navigation and I want to make sure I’m understanding this correctly. Here’s a list of assumptions based on my experience, but nothing would make me happier than being wrong somewhere here:

The core navigation block does not support “classic” menus at all- other than handling a one-time conversion to the new wp_navigation post type. You cannot use the core Navigation block and still be controlling the menu through the classic Menus interface.

The navigation block does not support traditional menu locations (ex. Primary, Secondary, Footer). Once you pull a menu into the navigation block it will be converted and the menu location is not saved/applied in any meaningful way.

The Navigation block creates a new post in the wp_navigation post type, which stores the menu items. This sort of replaces the old WP_Term that was used. So the navigation block needs to store a post_id of a specific wp_navigation post as an attribute (ref).

Essentially this means that a theme can’t have a header.html template part that gets continuous updates, especially when sending those updates to multiple sites, because it would then overwrite the unique post_id of the menu on that specific site. (In classic themes, your header.php would reference a menu “location” which was a more site-agnostic way to keep a reference to a specific menu without relying on site-specific unique IDs).

Similarly, I can’t programmatically create menus using the classic wp_nav_menu function at all because I still need the block editor to run it’s conversion process and set the post_id in the header template part (which I believe is only possible as a manual action in the editor itself).

Does this make sense or am I missing functionality here? Essentially a theme can’t version control any template parts that use the navigation block without the site instance needed to override it with customizations?

Right now our proposed solution is to remove the core navigation block and write a custom block, but I’d love to know if there’s another solution.

Learn Modern WordPress Development

I’m sharing the best resources and tutorials for developers building in and on the block editor.

8 responses to “FSE Navigation Block Woes”

  1. Dave Smith Avatar
    Dave Smith

    Hi Brian,

    Long time contributor to the block editor (and specifically the Nav block) here. I’ll try and answer a few of your questions, although I am just one of the many contributors.

    > You cannot use the core Navigation block and still be controlling the menu through the classic Menus interface.

    That is correct. This was an intentional design decision as providing backwards compatibility for the whole spectrum of enhancements to the Classic Menu screen was not seen as achievable. You are encouraged to manage menus in your block theme via the new block-based system.

    > Once you pull a menu into the navigation block it will be converted and the menu location is not saved/applied in any meaningful way.

    That’s correct. There is no concept of “location” in block themes and so we have not been able to meaningfully bring this across and apply it from a classic theme setting. Perhaps you would expect the editor to infer a suitable location (e.g. header template part) within the site based on the “location” attribute? I’d love to understand more your expectations here (a good forum is an Issue on the Github repo https://github.com/WordPress/gutenberg/issues/new/).

    > …which was a more site-agnostic way to keep a reference to a specific menu without relying on site-specific unique IDs

    This is a known issue and one we’ve been trying to get around to solving for some time. TL;DR – we are looking to move to slugs to “reference” menus but this is still in the works. Please see https://github.com/WordPress/gutenberg/pull/42809.

    In short, I understand all these frustrations and contributors are indeed aware of many of them. We’d love your input, whether that’s in the form of testing, raising Issues or even submitting PRs. The block has improved in recent releases, but – as evidenced by your frustrations here – there’s still lots to do.

    I just wanted to reach out to say “we hear you”.

    Thanks again for posting this and I hope to engage with you on Github, WP Slack in the near future.

    1. Brian Coords Avatar
      Brian Coords

      Thanks for the response! I’ll spend some time thinking about an ideal workflow here and see if I can coalesce that into a formal issue. Your PR on allowing a more general “slug” would be a good first step, but it looks like there’s still a lot of work to bring this to any sort of feature parity with classic menus (from a developer/extensibility perspective).

      I was hoping I could avoid a custom block, but it looks like that’s going to be the only viable approach for this specific use case. Thanks again for helping me through this.

  2. Peter Avatar

    The current implementation of the nav block is woefully inadequate. I’m keen to make the transitionfrom from a classic theme to a block theme.

    The nav block is the one thing stopping my move from a classic theme (Asrta Pro) to to a block theme.

    With Astra Pro my current page is highlighted on the nav menu. As I move from one menu item the hoover color changes. Ditto sub menus. And if I choose a page that is a sub-menu page… then the parent is highlighted. This give users a visual cue as to where they are.

    None of this is currently possible with the current nav block…hence my description of it being “woefully inadequate”.

    It’s such a basic feature of a nav menu I was surprised it was not available.

    I’m hoping it’s going to be fixed in 6.5.


    1. Brian Coords Avatar
      Brian Coords

      If all you need is the classic menu experience, I’ve heard good things about the Classic Menu Block. But I agree, some of the basic features are lacking in the core block!


    2. Peter Avatar

      Thanks Brian

      I’ll take a look at the Classic Menu Block.

      Jamie Marsland suggested a partial work-around using the plugin: Twentig, that allows hovers to be added to blocks. I say its a partial work-round as it does not highlight the Primary menu item as Active, when there is an Active sub-menu item…

      For me the deal breaker for a change from my classic theme to a block theme is that in the current navigation block cannot highlight active pages as possible in Astra Pro / if not using Astra Pro this can be done with some css along the lines:
      .current_page_parent >a, .current-page-ancestor >a, .current-menu-parent >a, .current-page-ancestor >a, .current-menu-item >a {
      color: #990000 !important;

      According to @zoonini, a WordPress Support Moderator: “in Full Site Editing / block themes .current-menu-parent or ancestor is not automatically assigned yet…”.

      Really hoping there is a fix / workaround coming in WP6.5.


    3. Brian Coords Avatar
      Brian Coords

      You could also try the new `:has()` selector in CSS to target navigation elements that have the `.current-menu-item` inside of them.


    4. Peter Avatar

      Many thanks Brian for the has: link


      did the trick!

  3. Fabian Todt Avatar

    Those are the problems I have with thr navigation block as well. Also I would like to give customers the possibility to edit menus but not enter the site editor or have to explain the whole concept to them.
    That‘s why I‘m using the Classic Menu Block atm.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.