Header and Footer Implementation Standards

Header and Footer Implementation Standards

Use this guide when changing the public shell or admin shell of a website built with Batoi Press. The goal is to keep Batoi Press sites consistent, accessible, easy to operate from the admin console, and aligned with Batoi brand and UIF conventions.

Canonical Batoi Press Files

Do not copy global header, footer, account, or navigation markup into individual content pages. Pages and posts should provide content and metadata only. The public shell should render the header, footer, assets, navigation, and shared page chrome.

Public Website Header

The public website header for a Batoi Press site belongs in radpress/theme/default/partials/header.php. radpress/theme/default/layouts/base.php owns the public shell and includes the header partial.

Admin-Managed Header Changes

• Routine menu link changes should be manageable through the Batoi Press admin console.
• Header template changes should be made through /admin/theme-templates when the site operator is changing an editable theme file.
• Admin-managed menu configuration should cover navigation labels, internal URLs, external URLs, target behavior, item order, and visibility.
• The layout should render validated admin-managed menu data and keep safe code defaults for first install, broken config, or incomplete config.
• Admin forms should validate labels and URLs, reject unsafe protocols, and preserve safe external-link behavior.
• Changes should be recorded in audit/governance history where the site enables that capability.

Navigation Structure

• Keep primary navigation as structured data, not duplicated markup.
• Use stable item fields such as label, URL, target, order, and optional child items.
• Use local Batoi Press site URLs for internal links and absolute URLs only when the destination is external.
• Keep top-level labels concise. Longer explanatory text belongs in page content or structured menu descriptions, not the main nav label.
• If a theme supports dropdowns or mega menus, render them from the same admin-managed data used by mobile navigation.
• Nested menus should preserve stable child routes, exclude draft pages from public navigation, and derive active state for parent and child items from the current public path.

Logo And Branding

• Use the configured site logo when available.
• Respect the configured public branding mode: text, logo, or logo plus text.
• Use configured logo alt text when available.
• Keep a safe Batoi or site-name fallback for new installs.
• Link the logo to the site home page.
• Provide meaningful alt text such as the site name or "Batoi".
• Do not hardcode a one-off logo inside an individual page.

Active State Behavior

• Active state should be derived from the current request path and the configured menu URL.
• The layout should apply active classes consistently across desktop and mobile navigation.
• Do not hardcode active classes in content files.
• Redirect and alias paths should resolve to the canonical URL before active state is evaluated when practical.

Responsive And Mobile Behavior

• Desktop and mobile menus should be rendered from the same configured navigation data.
• The mobile header must include a reachable menu control with a clear accessible name.
• Keep the mobile brand and menu button on one row.
• When the mobile menu opens, let navigation expand across the full header width so nested menu items have enough room.
• Long labels should wrap or truncate cleanly without shifting the shell.
• Account, search, theme toggle, or other global controls should remain in predictable header positions when enabled.

Accessibility

• Use semantic landmarks: header, nav, and meaningful link text.
• Keep menu controls keyboard-accessible.
• Use aria-label, aria-expanded, and aria-controls where the interaction requires them.
• Escape dynamic labels, URLs, and descriptions before output.
• Icons may support actions, but they should not be the only accessible name.

What Content Pages Must Not Hardcode

• Global header navigation.
• Logo paths or brand replacement rules.
• Account menu entries.
• Search, login, admin, preview, or logout links that belong to the shared shell.
• Dropdown or mega-menu markup.
• Route/page CSS that changes global header spacing, breakpoints, or positioning.

Public Website Footer

The public website footer for a Batoi Press site belongs in radpress/theme/default/partials/footer.php. radpress/theme/default/layouts/base.php owns the public shell and includes the footer partial.

Admin-Managed Footer Changes

• Routine footer template changes should be manageable through /admin/theme-templates when the site exposes the footer partial for editing.
• Footer link data should be represented as validated site/menu data where the theme supports admin-managed footer links.
• Admin-managed configuration should cover footer columns, footer links, social links, contact links, compliance links, copyright text options, and ordering.
• The layout should render validated admin-managed footer data and keep safe defaults for first install or invalid config.
• Admin forms should prevent private file paths, unsafe protocols, and empty labels from being published.

Footer Structure

• Keep footer data structured by column or section.
• Prefer adding links to existing columns before creating new columns.
• Keep the first footer area available for brand copy, logo, contact, or newsletter links when the site needs them.
• Keep labels concise and durable.
• Do not add page-specific footer blocks unless the page has a real local disclosure requirement.

Social, Contact, And Compliance Links

• Social links should have accessible names.
• External links should preserve safe external-link attributes.
• Contact links should point to public contact pages, mail links, or configured forms only.
• Compliance, legal, policy, privacy, and terms links should stay reachable from the footer where the site needs them.
• Do not expose private uploaded files or internal storage paths through footer links.

Branding And Copyright

• Use configured site identity first.
• Keep a safe copyright fallback.
• Do not hardcode a product or customer name into the theme unless it belongs to that specific distributed site.
• For reusable themes, keep branding defaults configurable.

Adding, Removing, Or Renaming Footer Links

• Use the admin console for routine link edits.
• Confirm the target URL exists or intentionally points to an external destination.
• Keep legal, privacy, policy, support, and contact changes deliberate because they can affect customer trust and compliance.
• Preserve order and grouping so the footer remains scannable.

Batoi Press Admin Header And Navigation

The Batoi Press admin shell belongs in radpress/admin/AdminLayout.php.

Admin Shell Responsibilities

• Render the admin top bar, side navigation, account menu, logout action, and shared admin assets.
• Keep admin navigation in one source of truth, either in AdminLayout.php or a small dedicated navigation helper if the project introduces one.
• Keep page-specific admin forms and tables out of the shell.
• Keep shell markup predictable across Dashboard, Content, Media, Menus, Settings, Updates, Audit Log, and other admin areas.

Top Navbar Expectations

• Keep site/admin identity visible in the top bar.
• Keep account and logout placement predictable.
• Use icon plus text for major admin actions when space allows.
• Use compact icon buttons only for conventional actions with clear titles or accessible labels.
• Keep global actions such as preview site, clear cache, or update checks out of content editor markup.

Sidebar Or Admin Navigation Structure

• Group admin navigation by operator task, such as Overview, Publish, Site, Governance, Updates, and Intelligence when those areas exist.
• Match the current Batoi Press grouping: Overview, Publish, Site, Governance, and Intelligence.
• Keep active state derived from the current admin route.
• Do not duplicate the same admin navigation list in multiple pages.
• If roles or permissions are added, filter menu items before rendering them.
• Keep collapsed/mobile navigation usable by keyboard and touch.

Account And Logout Placement

• Keep account controls in the admin shell, not in individual admin pages.
• Keep logout as a clear final account action.
• Do not duplicate logout links across editor pages.
• Use CSRF or equivalent protection for state-changing account/admin actions where the runtime supports it.

Design Standards

• Use Batoi brand assets consistently where the site is a Batoi property.
• For customer or downstream sites, make branding configurable rather than hardcoded.
• Use existing Batoi Press and UIF visual conventions before introducing new styling.
• Buttons should include icons plus text when the action is not already obvious from a conventional icon-only control.
• Public navigation should be polished and spacious; admin surfaces should be dense, scannable, and business-ready.
• Avoid card-heavy marketing composition in admin shell areas.
• Keep typography restrained in nav, sidebar, dropdowns, and footer columns.
• Use responsive constraints instead of viewport-scaled font sizes.
• Ensure text does not overflow buttons, dropdowns, footer columns, sidebars, or account menus.
• Do not add route-local UI libraries to solve shell navigation problems.

Change Process

Where A Change Belongs

Required Checks

• Check that the public header and footer render on the home page, a page, a post, archive/blog listing, and 404 page.
• Check desktop and mobile widths.
• Check active navigation state.
• Check that admin-managed menu/settings/template changes survive save and reload.
• Check that invalid or empty config falls back safely.
• Check legal, contact, social, and compliance links after footer changes.
• Check that admin navigation, account menu, and logout remain reachable.

Suggested Browser Smoke Tests

• Public home page: logo, primary nav, mobile menu, footer columns.
• Nested public page: parent and child menu active states, stable child route, and draft-page exclusion.
• Public page and post: same shell, no duplicate page-local header/footer.
• Blog/archive page: active state and footer visibility.
• 404 page: shell still renders safely.
• Admin dashboard: topbar, admin navigation, account menu, logout.
• Admin menus/settings/theme-template editor: save, reorder, add external link, add internal link, remove link, edit supported header/footer template, reload.
• Public page after admin save: rendered links match the saved config.

Common Mistakes To Avoid

• Editing theme layout files for routine link changes that should be admin-managed.
• Adding a public nav item to desktop markup but not mobile markup.
• Hardcoding active nav state in content files.
• Publishing unsafe external URLs or private filesystem paths.
• Duplicating header/footer markup across page templates.
• Moving logout into individual admin pages.
• Adding shell CSS to a content page when the shared layout should own it.
• Forking this guidance into another long-form copy instead of keeping local product mappings concise.

Cross-Repo Guidance

Downstream product repositories should maintain only local file mappings and product-specific exceptions. They should point back to this guidance for brand, navigation, footer, admin shell, and UIF behavior.

For Batoi Press websites, keep these mappings as the first reference:

• Public shell: radpress/theme/default/layouts/base.php
• Public header: radpress/theme/default/partials/header.php
• Public footer: radpress/theme/default/partials/footer.php
• Admin shell: radpress/admin/AdminLayout.php

When a downstream product needs a different shell, document only the local path mapping and the specific approved difference. Do not fork this standard into another long-form copy.