Template Designers: Template Pages
Document which parts of each page editors can change and which parts belong to a fixed application flow. In erxes, a page is a Page record. What editors can change is its fields plus the ordered pageItems you designed as sections.
Content pages
Home, About, Contact, articles, policies, and custom content pages map to Page records: name is the title, slug is the route, description and coverImage feed SEO and hero areas, status controls whether the page is live, and pageItems holds the sections.
On deploy, each page is written to a per-page JSON file named after its slug (see the deploy step). A page whose slug is /, empty, or home becomes the index page. Keep slugs short, lowercase, and stable; changing a slug changes the route.
Confirm with the developer which operations editors get: change text and images inside config/content, reorder pageItems, add or remove sections, or edit page-level fields. List the supported operations per page rather than assuming all pages are equally editable.
For collection and detail pages (a post archive, a category page, a product detail), specify the data source, card/detail fields, links, pagination, empty results, and missing-record behavior. These pages render live queries. A Post detail needs title, content, publishedDate, thumbnail, categories, tags, and an agreed author display; an archive needs the same card fields plus ordering and pagination rules.
Application pages
Login, registration, password reset, profile, checkout, payment, and confirmation depend on functional workflows in the template. They may share your branding (colors, fonts, logo from Web.appearances/Web.logo) while keeping the interaction and validation logic fixed.
Do not describe them as universally editable or non-editable. Confirm the available customization boundary and design within it. Show submission progress, validation errors, authentication failures, and completion states where relevant.
Page specification
For each page, hand off:
- Its purpose,
slug(route), and primary action. - Shared layout and the ordered
pageItemslist with each section'stype. - Editable fields: which
configkeys,contentvalues, and page fields editors control. - Mobile and wide-screen layouts.
- Loading, empty, error, and success behavior for dynamic sections.
- Navigation into the page (which
main/footermenu items point to it) and the next step in the flow.
Handoff checklist
| Per page | Stored in | Specify |
|---|---|---|
| Page title | Page.name | SEO title and any separate display title |
| Route | Page.slug | Final URL; home// becomes the index page |
| Metadata | Page.description, Page.coverImage | Social card text and image |
| Visibility | Page.status | Live vs. hidden during editing |
| Sections | Page.pageItems (type, order, config) | Ordered list with editable fields per section |
| Menu entries | MenuItem pointing at the page | Label, kind, linkType, order |
| Bound content | objectType/objectId, linked posts/categories | Which records feed dynamic sections |
Review direct entry, navigation, and the mobile flow with the developer. Link requirements that need new routes, fields, or integrations to the agreed development scope.
