Webshop overrides & the shell model
A design can own every page — not just the homepage. Per-design product cards and PDP layouts, plus site-wide chrome and per-page templates.
Early Cartwright designs only styled the homepage; cart, product, contact and info pages fell back to a shared default. From engine v0.33.0 a design pack can own the whole site — its own chrome, its own per-page templates, and bespoke commerce layouts — while a design that doesn't opt in still gets the shared defaults, byte-for-byte.
Ships in engine v0.33.0. Every override is optional and default-safe: an undefined seam falls back to the shared chrome / default body, so existing designs are unchanged.
The shell model — a design owns every page
A DesignPack can declare a siteChrome and per-page pages:
const myDesign: DesignPack = {
// …homepage, tokens…
siteChrome: {
Shell, // wraps every route
Header, // bespoke header
Footer, // bespoke footer
},
pages: {
contact, // a custom /contact body
info, // a custom /info/[slug] body (FAQ, legal…)
notFound, // a custom 404
},
};Each seam is optional. Leave siteChrome undefined and the design uses the shared header/footer; leave a pages entry undefined and that route renders the default body. So opting in is purely additive — it can never regress a design that doesn't.
The four recognizable premium packs that ship with this model — halo, flux, drive (and the flagship apex) — carry their own chrome plus contact/info/404 templates, so the whole site feels designed, not just the landing page.
Webshop overrides — bespoke commerce layouts
For shops, a DesignPack.webshop block lets a design replace the two surfaces that matter most for a storefront's feel:
const myDesign: DesignPack = {
// …
webshop: {
productCard, // the card used in product grids (PLP, featured)
pdpLayout, // a wrapper around the product detail page
},
};productCardis threaded into the sharedProductGridvia itscard?prop, so the same grid renders your bespoke card everywhere products are listed.pdpLayoutwraps the product-detail tree, so a design can frame the PDP (breadcrumbs, canvas, panels) without forking the commerce logic.
halo ships both — an Apple-minimal product card and a PDP layout — as the reference implementation.
Palette-adaptive designs need none of this
The shell model and webshop overrides are how a distinct-identity design (a locked theme, its own token prefix) takes over the whole site. A palette-adaptive design (apex, aurora-*, jungle, …) usually doesn't need them: with applyPaletteAsTheme, the shared chrome and the default product cards already re-skin to the brand palette automatically. Reach for overrides when you want a bespoke structure, not just bespoke colours.
Related
- Designs overview — the design pack model
- Writing your own design — build a pack from scratch
- design.md spec — the portable design format
Picking a design
How to choose a design for your Cartwright shop — via the setup wizard at first install, or via /admin/designs anytime after.
design.md spec (cartwright-design-v1)
Full schema reference for cartwright-design-v1 — the YAML-frontmatter format that powers design imports and exports in Cartwright v0.7.0.