c86dbdc60d
Extends the branding service with a hiddenNavHrefs: string[] field so forks can hide sidebar entries (e.g. /salary, /customers) without patching DashboardNav.tsx. Configurable via NEXT_PUBLIC_BRANDING_HIDDEN_NAV as a comma-separated list. Default is [] — vanilla gnubok unchanged. Routes remain reachable; this is a nav-visibility switch only. Settings sidebar is intentionally out of scope. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Example branding extension
Copy this folder to start a whitelabel fork:
cp -r extensions/general/_example-branding extensions/general/your-brand
Then:
- Edit
your-brand/manifest.json— setid,exportName,entryPoint, name, description. - Edit
your-brand/index.ts— uncomment and set the branding values you want to override. - Drop your assets in
your-brand/assets/(logo.svg, favicon.ico, og.png, etc.). Wire up an extension API route to serve them, or set the asset paths inindex.tsto external CDN URLs. - Enable the extension in
extensions.config.json:{ "id": "your-brand", "enabled": true } - Run
npm run setup:extensions && npm run dev.
See WHITELABEL.md at the repo root for the full fork checklist (env vars, sync workflow, what NOT to change).
Why a separate extension instead of just env vars?
Both work. Env vars are simpler for scalar overrides (app name, support email). An extension lets you bundle assets (logos, icons) and override values that don't fit cleanly into env vars. You can use both — extension overrides win over env vars.