Define content once and show it wherever it is needed: the benefits and costs, the techniques, picking shared blocks, and loading a settings record once.
Content that appears in more than one place can be defined once and shown wherever it is needed, or it can be written again in each place. Defining it once has three benefits: • Consistency. Every place that shows the content shows the same thing, so a changed phone number or price changes everywhere. • A better editor experience. An editor changes a fact in one place instead of looking for copies, and each page has fewer fields to review. • Simpler content management. There are fewer records to keep in step, so fewer copies can drift apart. It also has costs. A page that shows shared content can be customized less, an edit reaches every page that shows it, repeated or nested queries can slow a page, and the structure has to exist before the first page uses it. A second copy is a valid choice when it is deliberate; the cost is that the copies drift apart.
Ways to define content once Several of these can be combined on one site. • A datastore item picked by a datastore item list field. Each page selects the items it shows (the cards on Home, the questions under a category) and none of them copies the text. This fits content with a shape of its own: testimonials, FAQs, calls to action, services. See Content Types. • Any entity picked by an entity list field. Use it for articles, blog posts, or other content records. Set Has URL on the field when every pick must have its own page. • A fetch. A list method with a query shows recent, filtered, or random items without anyone picking them. Picks, a Fetch, or Both covers choosing between picks and a fetch and combining them. • A snippet. Editor-owned markup with no URL, changed in one place and shown wherever it is inserted. See Using Includes and Snippets. • A settings record. One item in a settings datastore holds site-wide content (logo, contact details, call to action, social links, footer groups, chosen menus) that the header, footer, and any partial read. • A partial that takes input variables. A consuming template can pass it shared or page-specific content. See Choosing a Content Architecture. • A default the editor can override. Show the shared version unless an editor sets a value on this page. A testimonials section may pull random testimonials with an option to select them for one page. A "Core Values" list may default to the values from another page, with an option to set custom values. An "Our Story" section may reference a snippet with a default selected, so changing it means selecting a different snippet and updating the snippet updates every page that shows it. The override costs the editor one more option, so offer it only where pages really differ.
A block shown in more than one place Name the source of each shared block: the datastore and the picker field that selects from it. For example, Home's featured_testimonials field is a datastore item list over Testimonials, and the /testimonials page lists the same datastore, so the text lives once. FAQs grouped by category are a page fieldset of categories, each with its own list of selected questions, so one question can appear under several categories. A datastore of this kind can still own a landing page; see Datastore Landing Pages.
Loading the settings record once Load the settings datastore by name, near the top of the shared header, and give every partial the one variable:
Partials then read settings.company_phone and the like. Loading by name rather than GUID keeps the code working on every site the template is copied to.
Choosing between them Ask who edits the content, whether it varies by page, whether it needs a URL, and how many places read it. A fact that never varies and is read by many templates fits a settings record. Content with a shape of its own that pages choose from fits a datastore and pickers. Markup an editor adjusts occasionally fits a snippet. A value that differs on most pages is not worth sharing. The two pages beneath this one carry the detail: Choosing a Content Architecture decides, section by section, whether a template reads fields on the page or queries content stored elsewhere, and Picks, a Fetch, or Both covers how a listing is populated. For the editor's side, see Editor Experience.