Nav menu

The first header in the catalogue that drives a real menu. core/navigation, core/site-logo, core/site-title and core/search on one row, in a core/columns inside a full-bleed group.

A full-height currentColor hairline stands between the site and the search. Every other header in this catalogue rules horizontally, under the bar or between two rows. Here the bar is closed underneath by one hairline and DIVIDED by another, at right angles to it, so the field reads as a separate instrument bolted to the end of the bar rather than as the last item in the menu.

The rest is held to the floor deliberately. Two cells, 74/26: the mark at the left in a tight 18px lockup and the menu standing against the rule at 14px with 0.12em of tracking in the first, the field at 16px in the second. Nothing is decorated, because the composition is the rule.

nav-bar is a wordmark against tracked links and one solid button, on one line. nav-stack is a masthead: two rows, two rules of different weights. Both are type somebody typed. This one is distinguished by what it DRIVES: a real core/navigation with real submenus, and a real search field. A buyer who wants a header they can edit as text takes one of those two; a buyer who wants the header WordPress manages takes this.

1. The menu. Select the block, then Menu, and point it at yours.
2. The logo. Site Editor, Styles, or the block's own placeholder. Its width is 40; raise it and the bar grows with it.
3. The cell widths. 74/26. A menu of seven items or a long site name wants the first cell wider; the field can live with less.
4. The label and the placeholder. "Search" is the visible caption and "Search this site" is the placeholder; both are block attributes, not content. Keep the caption to one short word: it sits in the narrowest of the three cells.
5. The finish. Ship the base on a light page, and nav-ink where the header should sit as a solid band above it.

• The typeface. No font family is stated anywhere.
• Your colours. The bar asks for base and the type for contrast, both ending on a colour WordPress guarantees. Both rules are currentColor.
• The menu's link colour is your theme's decision and cannot be ours. Core ships .wp-block-navigation .wp-block-navigation-item__content { color: inherit } at a specificity nothing an inline style can beat, so nav links follow the colour the navigation block inherits. That is why the ink variation works at all: the menu follows the band.
• The search field and its button are the theme's. Measured, and worth repeating: stating style.color.text on core/search puts that colour on the SUBMIT BUTTON as well as the input, and Twenty Twenty-Four had already given that button a contrast background. A contrast chain there painted the magnifier the same colour as the button it sits on, ratio 1.0, and nothing warned about it. So this pattern states no colour on the search block, and the field is whatever your theme makes of a form input.

• Full bleed with a 1240px measure, and a bar that stays compact: two cells on one row, and the only thing under either of them is the field's own caption.
• The menu stands against the rule. The lockup and the menu are the two ends of one row, so the menu reads as belonging to the site and the field, behind the rule, as the instrument bolted to the end of the bar.
• The field is a field, not an icon. A 404 can afford a search that is only discovered by clicking; a header cannot.
• The field's label is SHOWN, not hidden. core/search always prints a <label>; with showLabel off it prints it inside screen-reader-text, which is a box one pixel wide, and a one-pixel box is where the word "Search" ladders into six lines of nothing. Measured at all three widths in all four themes. Hiding it also leaves the field's only name in a placeholder, which disappears the moment anybody types. So the caption is visible, it sits on the field it names, and it is the same word a screen reader was being given in private.

core/navigation renders the menu your site has, not a list somebody typed into this file. The preview on the product page is our preview site's seeded menu: five items, one of them a submenu of two. Your bar will carry your items. The same is true of the mark and the field: core/site-logo prints the logo set in the Site Editor, core/site-title prints the site name from Settings, and core/search searches your content.

With no menu assigned, core falls back to a list of your pages. That is WordPress's own behaviour and it is worth knowing before it surprises you: an empty core/navigation looks for a wp_navigation menu first, then for a classic menu, and failing both it renders core/page-list, so a fresh site shows every published page in menu order. It is never blank, and it is never your menu until you make one. Open the block in the editor and pick or create a menu; the block then carries a ref to it and every page using this header follows that one menu.

With no logo set, core/site-logo renders nothing at all on the front end, which is why the mark is a lockup rather than a logo alone: the site title sits beside it and carries the name until a logo exists. That is a deliberate decision, not a spare part.

Core's own responsive behaviour takes over and it is not ours to override. overlayMenu: mobile collapses the navigation to a hamburger below 600px, which opens the menu as a full-screen overlay. The lockup and the menu share one flex row that never wraps, so on a phone the title keeps the left and the button sits at the right of the SAME line, the way a header should; the two columns stack under 782px, so the field drops under that row with the bay rule as a short marginal hairline beside it. Measured at 390: one line for the title and the button, no horizontal overflow, and nothing in the bar sets a ribbon of copy. (An earlier build put the menu in its own column, which stacked to a hamburger centred alone on a row of its own.)

• Core blocks only: group, columns, column, site-logo, site-title, navigation, search. No plugin, no script.
• Valid at WordPress 7.0. The server RENDER of core/navigation and core/search differs slightly between WordPress versions (different icon paths, a different interactivity attribute, a trailing space in one class); none of it is authored here and none of it changes what a buyer pastes.