Root cause
frontend/packages/ui/src/resource-page-common.tsx: header showsdirectoryItemswhenhomeNavigationItemsis empty.frontend/apps/desktop/src/components/edit-nav-header-pane.tsx: popover seedsdocNavonly fromhomeDocument.detachedBlocks.navigation.So sites using header fallback (no explicit
navigationdetached block) render nav links in header, but editor menu sees[]and shows only “Add Navigation Item”.
Plan
frontend/apps/desktop/src/components/edit-nav-header-pane.tsximport
useDirectory,getSiteNavDirectory,packHmId,nanoid,useMemo,useRef.keep current explicit-nav extraction as-is.
add directory query for
homeId.build
fallbackNav: HMNavigationItem[]fromgetSiteNavDirectory({id: homeId, directory}).text:item.metadata.name|| ''type: 'Link'id: stable synthetic block id per item key viauseRef(new Map()); generate once withnanoid(). Important so drag/reorder/edit state stays stable across renders.
choose source:
machineNavigationfirstelse explicit
publishedNavif non-emptyelse
fallbackNav
pass that into
EditNavPopover.
Tests: add
frontend/apps/desktop/src/components/__tests__/edit-nav-header-pane.test.tsxmock
EditNavPopover; assert receiveddocNav.cases:
no explicit nav + directory items => popover gets fallback items.
explicit nav exists => explicit nav wins over directory fallback.
machine draft nav exists => machine nav wins over both.
Optional small cleanup
extract tiny local mapper(s) inside
edit-nav-header-pane.tsxfor readability only if needed; no new shared module unless duplication grows.
Why this fix
minimal; desktop-only.
matches what user currently sees in header.
preserves existing publish flow: first edit on fallback nav creates explicit
navigationblock, which is the expected transition from auto-nav to custom-nav.
Unresolved questions
Should editor fallback mirror only the public header (
getSiteNavDirectorydefault), or should it include editor-visible private children too? My read: mirror public header exactly.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime