Introduction

Design reusable website layouts and sections that map to what the erxes CMS stores and what the selected Web Builder template can render.

The product repository defines what data the CMS stores. The section types, editor controls, and page rendering live in a separate template repository per website template, so this guide gives you a design workflow, not a guarantee that every template supports every control. Review the selected template with its developer before preparing the handoff.

Start with what the CMS stores

Every visual element in your design ends up in one of these records. Naming the CMS field in your handoff is the fastest way to get an accurate implementation.

• The website (Web): name, description, domain, copyright, logo, favicon, plus appearances: backgroundColor, primaryColor, secondaryColor, accentColor, fontSans, fontHeading, and fontMono. Social links are stored in externalLinks as name/URL pairs. These are the branding settings you control; a Web Builder deployment writes them into the site's appearance and meta configuration.
• Navigation (MenuItem): label, url, icon, order, and parentId for nesting. The deploy step looks for menus with kind main (header) and footer; use those names in your handoff. Items can also carry linkType (URL, PAGE, POST, CATEGORY, TAG), openInNewTab, and target.
• Pages (Page): name, slug (the route), description, coverImage, status, and pageItems. A page's sections are the pageItems array. Each item has a type (which section component renders it), an order, a free-form config object for the section's options, a content field, and optional objectType/objectId pointers that link the section to another record.
• Posts (Post): title, slug, excerpt, content, thumbnail, images, categories, tags, authorId/authorKind, publishedDate, and status (draft, published, scheduled, archived). Design your cards and article pages against these fields.

Section type values and the keys inside config are defined by the template, not the CMS schema. The CMS stores any type string and any config JSON; whether a "hero" or "gallery" section renders correctly depends on the template's components.

Design for realistic content

Identify the audience, primary page action, and supported routes. Use realistic titles, images, translated text, and collection sizes. The CMS supports per-language translations of post and page fields, so check how your layout handles longer translated strings. Include loading, empty, error, and success states wherever the page renders live data such as post lists or menus.

Handoff checklist

Design element	CMS field it maps to	What to specify
Brand colors	Web.appearances.primaryColor, secondaryColor, accentColor, backgroundColor	Hex values and which UI role each color plays
Typography	appearances.fontSans, fontHeading, fontMono	Font family and fallback for body, headings, code
Logo and favicon	Web.logo, Web.favicon	Source assets and minimum sizes
Header nav	MenuItem with kind main	Item order, nesting depth, mobile behavior
Footer nav and copyright	kind footer, Web.copyright	Link groups, legal text
Social links	Web.externalLinks	Name/URL pairs and icons
Page list	Page.name, Page.slug, Page.status	Route for each page
Sections per page	Page.pageItems (type, order, config)	Ordered section list and editable fields per section
Post cards and article	Post fields above	Which fields appear, image crops, date format

Follow the design track

1. Template Structure: organize global elements, pages, sections, and fields.
2. Template Layout: specify branding, header, and footer.
3. Template Sections: define section content and states.
4. Template Pages: document per-page editability and flows.