Landing Page Ownership

The listing at a family's root (for example /equipment) can belong to the datastore or to an Article. Both work; they trade off differently.

• The datastore owns the landing. Check Has URL on the Datastore and give it a template, so the Datastore itself is a page rendered by a listing template. The Datastore settings involved are listed below. Blog and Calendar forms have the same settings, labelled Blog Posts and Calendar Entries instead of Datastore Items.

• Has URL makes the Datastore itself a page. It then carries the same page fields every page has: a URL, a template, and a browser title (the editor requires a browser title for anything that has a URL).
• Create Page For Datastore Items By Default only sets whether the option to give an item its own page starts checked when an editor creates an item. It generates no pages and enforces nothing, and it does not decide whether the Datastore itself can be a page. When it is checked, a Default Page Template for Datastore Items field appears.
• Default Page Template for Datastore Items and Default Root Path For Datastore Items pre-fill the template and the URL an editor would otherwise pick for each new item.
• Enforce Root Path For Datastore Items appears once Default Root Path has a value. When on, the CMS rejects an item whose URL does not start with that path ("URL must start with ..."); when off, the path is only a suggestion. Turn it on when the whole family should live under one root; leave it off when some items need to live elsewhere.
• Folders also carry Default Root Path and Enforce Root Path settings, though not Create Page By Default, and they are used less often. If a folder and its Datastore, Blog, or Calendar both enforce a root path, the CMS has a procedure for resolving the conflict; it matters only in unusually complex setups.

Consequences: one record holds the family's schema and its landing, and nothing else has to be kept in step with it. The CMS requires each URL to be unique per domain across all pages, so an Article cannot also claim /equipment, though an Article at another path is fine. The listing template's own custom fields (an intro, a banner, a call to action) are saved on the datastore record, so presentation fields alone are not a reason to use an Article. A plain every-published-item listing needs no extra field.

• An Article owns the landing. The Article takes the URL and a page template. It can select and order the family through a picker field, or fetch it. Consequences: the editor controls which cards appear and in what order for this landing; the Article can mix items from several datastores or other content records; it is a second record that describes the family, so a new item appears only if the Article picks or fetches it. Choose this when the landing is hand-curated, mixes sources, or wants a different editing surface than the datastore.

Either way, items may name their own template, so one family can mix page types. If both a datastore and an Article describe the same family, write down which one is the landing and why.

Every page-owning item, whether an Article or a datastore item, blog post, or calendar entry that has its own page, still needs its own URL, template, and browser title. The create-page and default settings above only supply starting values in the editor.