Skip to documentation content

Datastore Landing Pages

On this page

    Making the datastore itself the page at a family’s root: the Has URL setting, its listing template, and what that page can hold.

    The listing at a family's root (for example /equipment) can belong to the datastore. Check Has URL on the Datastore and give it a template, and the Datastore itself is a page rendered by a listing template. An Article can own the landing instead; Defining Pages covers that choice. Either way, a URL is unique per domain across all pages, so an Article cannot also claim /equipment, though an Article at another path is fine.

    The settings involved:
    • 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 does not decide whether the Datastore itself can be a page. It is about the items, and Item Pages or Articles covers it.
    Blog and Calendar forms have the same settings, labelled Blog Posts and Calendar Entries instead of Datastore Items.

    Consequences
    One record holds the family's schema and its landing, and nothing else has to be kept in step with it. 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 listing of every published item needs no extra field.
    A datastore can be a page even when its items are not. A Testimonials datastore whose items have no pages can still have a URL and a listing template, so /testimonials is a page while no testimonial has a URL of its own. A menu item can then link to the datastore.
    Choose an Article as the landing instead when the landing is hand-curated, mixes sources, or wants a different editing surface than the datastore. Then a new item appears only if the Article picks or fetches it.