# Template Pages

Page types the Web Builder supports, grouped by how much editors can change


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`](https://github.com/erxes/erxes/blob/f91e8c6f4714c910a32c6b6e14fe085f6435c89e/backend/plugins/content_api/src/modules/cms/graphql/schemas/page.ts) 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](https://github.com/erxes/erxes/blob/f91e8c6f4714c910a32c6b6e14fe085f6435c89e/backend/plugins/content_api/src/modules/webbuilder/utils/utils.ts#L314-L321)). 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 `pageItems` list with each section's `type`.
- Editable fields: which `config` keys, `content` values, 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`/`footer` menu 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.