Template Developers: Template Layout

Maintain the shared shell that wraps the template's pages: branding, navigation, content width, typography, and footer.

Template paths and editor controls depend on the separate template repository. Confirm them in your checkout; see what the product defines.

Locate the layout

In the App Router convention, start with app/layout.tsx, shared Header/Footer components, the client layout wrapper if present, and global styles. Check which pages share the shell and which application routes have a separate layout.

UI-only scope

Preserve providers and server/client boundaries during presentation work. A visual Header change should not require exposing a token to the browser or moving page data loading into a client component. Do not touch the data layer.

Use existing theme values

Use the template's existing font, color, spacing, and appearance values. In a deployed site these come from data/configs.json, which the deployer generates with a fixed shape: meta (title, description, logo, favicon, keywords, url), appearance (theme, baseFont, headingFont, baseColor, backgroundColor), menus (main and footerMenu arrays), and additional (copyright, social links, integrations). See buildConfigs and the Web schema it reads from. Confirm which of those keys your template reads before depending on them.

Provide useful behavior for missing logos, long site names, optional contact details, and translated menu labels. Keep navigation labels and destinations aligned with the content source. Render only the authentication and language controls supported by the selected template.

The header should make the main navigation and current location understandable on small and large screens. Keep menu toggles keyboard-operable, expose their expanded state, and preserve visible focus.

The footer may include secondary navigation, contact information, social links, copyright, and legal links. The deployer maps kind: "main" menu items to menus.main and kind: "footer" items to menus.footerMenu, each with label, url, icon, parentId, and order. Each rendered link needs a valid destination; do not use an empty link or # as a substitute for unavailable content.

For live navigation, cpMenus returns the site's items filtered by kind:

query CpMenus($kind: String, $language: String, $webId: String) {
  cpMenus(kind: $kind, language: $language, webId: $webId) {
    _id
    parentId
    label
    linkType
    kind
    icon
    url
    order
    openInNewTab
    target
    linkedContent {
      _id
      title
      slug
      linkType
    }
  }
}

Branch on linkType (URL, PAGE, POST, CATEGORY, TAG) and use linkedContent.slug to build hrefs without a second request; see the MenuItem schema. For UI-only work, keep menu fetching, authentication, and metadata logic intact. If data is missing or a destination is unsupported, work out the content or scope with the owner rather than inventing a flow.

Check the shared change

Check the homepage, a content detail page, and any affected account or checkout page. Test both available themes, mobile navigation, long labels, missing optional fields, and keyboard focus. A fixed header should not hide anchored content or focused controls.

Run the template's available checks and production build, then review the page-level behavior.

Was this helpful?