Documentation Header, Footer and Logos

The layout decides where the header and footer sit; this page is about what goes in them. Six settings do almost all of the work — a top menu, a bottom menu, one call-to-action button, and a logo for each color scheme — and they turn Leed’s default documentation chrome into your own without a line of code.

The top and bottom menu slots

These two are the whole “make the header and footer mine” story, and they are free on every plan, so start here rather than with a template override.

Top Menu fills the navigation row of the documentation header. Bottom Menu fills the footer’s menu columns — and gates rather more than that, which the footer section covers.

Both are on the documentation set’s page type, under Configuration Overrides in Settings → Page Types, and both also appear in Settings → General as a company-wide default.

The header call-to-action

Header Button Text and Header Button URL, in Settings → General → Documentation, put one button on the right of the documentation header.

One button, not a set of them: there is no array, no secondary button and no option to open in a new tab. A marketing header carrying two calls to action cannot keep both on the default documentation header.

Where a setting lives is worth one paragraph, because these fields do not all sit in the same place. The documentation settings you save in Settings → General are copied onto your documentation and API page types, but only into values a page type has not set for itself — company settings fill blanks, they never overwrite. And it is the page type’s copy, not the company’s, that reaches your published site. Practically: set a value once in Settings → General while a set is new and it lands where it needs to be; change it later and a set that already has its own value keeps it.

Logos for light and dark

Logo (Light) and Logo (Dark) are uploaded through the image dialog and are documentation-specific — they are not the same field as your site logo. Both the header and the footer paint them, as a background image, and which one a reader gets follows their operating system’s color scheme. There is no toggle: a reader in dark mode gets the dark file, and that is the whole rule.

The asymmetry is the part to plan around. Setting only the light logo is safe; setting only the dark one is not.

The dark-only case is a genuine hole rather than a fallback: the light value is what defines the logo for the page, and the dark value only overrides it. With nothing to override, a light-mode reader gets an empty space where your logo should be. Supply both.

The footer

The documentation footer has three parts, and only one of them is unconditional.

The logo and menu columns are gated entirely on the bottom menu slot. Leave it unset and you do not merely lose a menu — the logo goes with it, and the footer collapses to a social row above a copyright line.

With no bottom menu bound, the same footer collapses to the social icon row and the copyright line alone — no logo, no menu columns. Binding a menu is what fills those columns; nothing else does.

The social row renders whether or not a menu is bound — it is the one part of the footer you always get. Its links are assembled from your site-wide social accounts, which are set once for the whole site under Site Identity and Branding rather than per documentation set. An account you have not filled in renders no icon.

Four of the thirteen have fields in the CMS today; the rest are stored on the same record and can be set through the API.

The badge line

Two things are worth being blunt about. The badge is not a setting, so there is nothing to switch off; and it cannot be removed by replacing the footer, because overriding the footer is gated on the same plan level that removes the badge. Below Starter you get Leed’s footer, badge included, whatever files are in your repository.

Replacing the header or footer wholesale

Everything above works from the CMS. If the slots are not enough — you want a different structure, not different content in the same structure — you can replace either region entirely by adding src/_includes/docs-header.hbs or src/_includes/docs-footer.hbs to your site repository. The file existing is what switches the override on; there is no flag to set. Both are Starter and above.

leed site eject docs-footer gives you a byte-identical copy of Leed’s own footer to start from rather than a blank scaffold — leed site eject lists what else can be ejected — and the contract each file has to honor is at Customizing the Documentation Header and Footer.

One consequence changes what you do next. On the ejected route the header button becomes inert unless your own template reads it: Leed still stores the text and the URL, but nothing renders them until you do. An ejected header that ignores the field drops the call-to-action silently. And keep the menu slots set regardless of whether you eject — the slot names feed the campaign tracking on the logo and call-to-action links, and they are what the default footer needs if the override file is ever removed.

Tab groups are configured in the same panel and are a subject of their own — Tab Groups for Consistent Examples covers them end to end.