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.
Header and footer behavior
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.