Templates

How SG-Core resolves a record to its rendered layout.

Templates in SG-Core is the engine-level system that takes any renderable record and finds the right layout to render it through. Where SG-Admin owns the operator-facing module (the master list, the assignment surfaces) and SG-Builder owns the authoring (the visual editor that produces template content), SG-Core owns the runtime: the resolver that walks from "this record needs to render" to "this is the final layout to use."

What is this for?

Read this page when you need the engine-side definition: how a record finds its template, what the assignment surfaces are, how fallback resolves when no explicit assignment exists, and where the inheritance lines run between Pages, Posts, Custom Objects, and the platform-default layouts.

Good use cases

• You need to understand why a Page is rendering with a different template than expected.
• You are scoping a change that affects how multiple records render simultaneously.
• You are checking the cascade order between per-record, per-type, and site-default templates.
• You hit a question like "What template will a new Custom Object record use if I don't pick one?"

What NOT to use this for

• Operator how-to (creating templates, assigning them, managing the master list) — that lives in SG-Admin Templates.
• Authoring template content (the visual layout itself) — that lives in SG-Builder Templates Library.
• Per-release shipped change — open the Changelog.

How this connects to other features

• SG-Admin Templates — the operator-facing module that lists and assigns templates.
• Pages & Posts — the records templates render.
• SG-Builder Templates Library — the visual authoring surface.
• Custom Objects — operator-defined record types that participate in the same template-resolution path.

Template model

Every template at the engine layer is itself a record — stored in the same tables as Pages and Posts, with a template flag that marks it as a template rather than a content record. That choice keeps the storage shape uniform and lets templates flow through every cross-cutting feature (revisions, scheduling, search-exclusion, backups) the same way other records do.

A template carries:

• Identifier — internal record ID and operator-set name.
• Slug — used to reference the template in assignment paths.
• Body — the SG-Builder document tree that defines the layout.
• Eligibility flags — which post-types this template can render (Pages, Posts, Custom Object types, or any subset).
• Default-for-type marker — optional flag indicating this template is the site-wide default for a specific record type.

The template body is whatever SG-Builder produced. The engine treats the body as opaque; render resolution and binding are SG-Core concerns, the actual layout markup is SG-Builder output.

Layout resolution

When a record needs to render, the resolver walks a fixed cascade and returns the first template it finds. The cascade is:

1. Per-record assignment — the record carries an explicit template binding. If set, this wins.
2. Per-type default — the record's post-type carries a default-for-type template marker. If set on a template the record is eligible for, this is used.
3. Platform fallback — every site has a built-in fallback layout for every record class. If no per-record or per-type template applies, the fallback renders.

The cascade evaluates once per render. There is no live re-evaluation — a record's effective template is the resolver's answer at the moment of render, not at the moment of assignment.

Eligibility filter

Each template carries eligibility flags listing which post-types it can render. A template marked eligible only for Pages will not be returned for a Post or a Custom Object record, even if explicitly assigned. The eligibility check runs at every step of the cascade — the resolver skips ineligible templates rather than returning them.

When a per-record assignment points at a template that has since lost eligibility (for example, a template's eligibility was narrowed after the assignment was made), the resolver falls through to step 2.

Assignment surfaces

Template assignment for records flows through two paths.

Per-record assignment is the operator's explicit choice for one specific record. It is set in the record's edit surface (Pages editor, Posts editor, Custom Object record editor) via a template picker that lists eligible templates from the master list.

Per-type default assignment is the operator's choice for a whole post-type at once. It is set in the admin Templates module by marking a template as the default for a specific record type. New records of that type pick up the default automatically; existing records keep whatever per-record binding they had.

Both assignments are recorded in standard fields on the record (per-record) or on the template (per-type-default). There is no separate assignment table; the assignment data is co-located with what it binds to.

Assignment lifecycle

Per-record assignments persist across edits, status changes, scheduling, and revisions. They are preserved by backup and restored on recovery. They are visible in the per-record revision log when changed.

Per-type-default assignments take effect at next render for any record of the matching type that does not have a per-record assignment. There is no migration step; the resolver picks up the new default the next time it walks the cascade.

Inheritance

Templates do not inherit from other templates at the engine layer. Each template is a standalone record with its own body. The cascade resolves to one template; it does not stack contributions from multiple templates onto a single render.

This is intentional. Stacked or layered template inheritance would require coordination between authoring and rendering that SG-Builder is not designed for. Operators who need shared layout fragments use SG-Builder's component library — components can be saved, named, and reused inside any template body.

The shared-component path keeps the inheritance conversation inside SG-Builder rather than leaking it into SG-Core's resolver. A template that uses a saved component carries the latest version of that component at every render; updating the component updates every template that uses it.

Render binding

Once the resolver picks a template, the renderer binds the record's content fields into the template's body. Standard binding points include the record title, the record body, the record's Custom Field values, and any platform-provided context (e.g. published date, author, related records).

Binding points are anchors the template body declares — typically through SG-Builder's content components (Title block, Content block, Field block). At render time, each anchor is replaced with the bound value. Anchors with no matching value render as empty (or, where applicable, with the template's placeholder text for that anchor).

Binding fallback

When a record carries fewer fields than the template's body anchors expect (e.g. an old record predating a Custom Field addition), missing fields render as empty rather than producing an error. This keeps templates resilient to schema evolution.

When a template has fewer anchors than the record carries, the record's extra fields are unrendered for that template. The data is still stored on the record; choosing a different template (or updating the current one) can surface them.

Constraints and boundaries

Templates in SG-Core is the engine layer. The operator module is in the admin; the authoring surface is SG-Builder.

What this engine layer does

• Stores templates as records with a template flag.
• Walks the per-record / per-type-default / platform-fallback cascade at render time.
• Filters templates by eligibility flags during resolution.
• Binds record content into template body anchors at render time.
• Preserves assignment state across edits, backups, and restores.

What this engine layer does not do

• Provide template-content authoring — that is SG-Builder.
• List templates for operator selection — that is SG-Admin.
• Inherit between templates — there is no inheritance graph.
• Choose templates dynamically based on visitor or request context — assignment is record-level, not request-level.

Public boundary

The engine layer is publicly documented at this depth (cascade order, eligibility model, assignment shape). Lower-level details (table column names, internal flag values, render-pipeline internals) are not published.

Examples

Example 1 — Page with explicit per-record template

An operator creates a landing page and assigns the "Marketing Landing" template explicitly. On render, the resolver finds the per-record assignment in step 1 and returns "Marketing Landing." Per-type defaults and platform fallbacks are not consulted.

Example 2 — Custom Object record using per-type default

An operator marks "Project Detail" as the default-for-type for the Project Custom Object. New Project records have no per-record assignment; on render, the resolver finds no per-record binding (step 1 misses), finds the per-type default in step 2, and returns "Project Detail."

Example 3 — Fallback to platform default

An operator deletes the per-type default template for Posts without setting a replacement. New Posts have no per-record assignment; on render, step 1 and step 2 both miss; the resolver falls through to the platform's built-in Post fallback layout in step 3. The site continues to render — the fallback exists precisely so render never breaks when assignment is incomplete.

Example 4 — Eligibility narrowing

A template was eligible for both Pages and Posts. The operator narrows eligibility to Pages only. Existing Posts that had explicit per-record assignments to this template now fall through to step 2 (per-type default for Posts) on next render. The assignment data remains on the record but is no longer used.

Common patterns

A handful of template configurations recur often enough to be worth naming.

Single-default-per-type pattern — one default-for-type template per record class, no per-record overrides. Suitable for sites with a uniform look across all Pages or all Posts. Operators add new records and they render correctly with no further action.

Hub-and-detail pattern — a default-for-type template covers most records; a small set of high-visibility records carry per-record overrides for hero or campaign treatment. The default keeps the long tail consistent; per-record assignment handles the exceptions.

Per-type-family pattern — multiple Custom Object types (Project, Case Study, Member) each carry their own per-type default. Each type renders distinctly while sharing the same underlying resolution path.

Template-eligibility-as-policy pattern — sites narrow template eligibility deliberately so operators can only assign templates that match the record type's intended treatment. A "Marketing Landing" template stays eligible for Pages only; an "Internal Note" template stays eligible for the Internal Notes Custom Object only.

Each pattern is a configuration, not a code path. The engine has no notion of "single-default" vs "hub-and-detail"; those are descriptions of how operators combine the same primitives.

Edge behaviors

A handful of behaviors are worth surfacing because they answer recurring "what happens if..." questions.

What happens if a template is deleted while records reference it? The template moves to trash; existing per-record assignments to it now point to a trashed record. On next render, the resolver finds the binding but rejects it as ineligible (trashed templates are not eligible) and falls through to step 2.

What happens if a template's body is edited? Every record that resolves to that template renders with the new body on next page load. There is no per-record cache that needs flushing; the resolver returns the template's current state.

What happens if a per-type-default and per-record assignment conflict? Per-record wins. Step 1 of the cascade returns first.

What happens if no platform fallback exists for a record class? This case does not arise. The platform ships fallbacks for every default record class and Custom Objects inherit the Page fallback unless per-type configuration overrides it.

Migration considerations

When importing a site, templates can be created up front and assignments applied to incoming records during the import. The eligibility model lets the importer enforce the right pairings — incoming records of one post-type cannot accidentally pick up a template that's eligible for a different post-type.

When exporting, every template record exports through the same backup path that handles content records. The export carries the template body, the eligibility flags, and the per-type-default markers. Restoring into a different SGEN site recreates the templates with the same identifiers and the same default-for-type bindings; per-record assignments restore alongside the records that carry them.

For sites moving between SGEN versions, template body compatibility is governed by the SG-Builder component versioning. A template authored against an older SG-Builder component set continues to render under newer SG-Builder versions; component-level migration runs at render time when needed.

For sites moving from another platform, templates can be authored fresh against the new content shape rather than imported. Direct import of templates from other platforms is rarely useful — different platforms model layouts differently — and the rebind-during-import path produces cleaner results.

The same migration considerations apply when consolidating multiple SGEN sites onto one.

Templates from each source site are imported alongside the source site's records; eligibility and per-type defaults can be reconciled after the import lands.

Operators consolidating sites should expect to revisit per-type defaults after the import — the merged site has more candidate templates than either source did, so the right default is often a fresh choice.

Search and sitemap behavior

Templates are themselves SGEN records, but they are excluded from public-facing surfaces by default. Search does not index template records. The sitemap does not include them. Public routes do not mount for them. They exist as content sources, not as content.

When operators want to share a template's body publicly — for design-system documentation, for partner reference — the standard approach is to copy the template body into a regular Page record rather than exposing the template directly. The Page goes through normal indexing and routing; the template stays internal.

Internal lookups (the admin master list, the SG-Builder Templates Library picker) read the template flag directly, bypassing the public-surface filters. Operators with admin access see every template the site has registered.

Versioning and rollback

Templates carry the same revision history every other SGEN record gets. Every save creates a revision; every revision is restorable. The revision view shows the body diff between versions and lets operators roll back to an earlier state.

Rollback affects every record currently bound to the template. Operators considering a rollback should know whether records have visibly changed since the version they're rolling back to — the resolver returns the template's current state on next render, so a rollback is observed across the site as soon as it lands.

For staged template changes — large rewrites that need review before going site-wide — the duplicate-and-swap workflow is preferred over editing the live template directly. The duplicate stays unbound while it's being edited; the swap to the duplicate is the moment the change goes live.

Operational notes

Template assignment changes propagate at next render. There is no rebuild step. Operators editing a per-type default see the change reflected the next time anyone visits a record of that type without a per-record override.

When a template is duplicated, the duplicate gets a new identifier and a fresh slug; the per-record assignments on existing records still point at the original template. Duplicates are useful for staging variants — operators duplicate, edit the duplicate, swap assignments to the duplicate when ready, and either retire the original or keep it for later A/B comparison.

Template assignment behavior across multi-language sites follows the language-aware version of the cascade: per-record assignment for each language version is independent, per-type defaults can carry per-language defaults, and the platform fallback applies per-language. The resolver picks the right per-language template at render time.

Bulk template assignment changes — swapping every record using template A to template B — are an operator-side workflow. The engine does not have a built-in bulk-rebind affordance; operators run the swap through the bulk-edit surfaces in the admin. Each individual swap is a normal per-record assignment change.

Templates and Custom Objects

When operators create a Custom Object type, the type does not ship with a template binding. The first render of any record of that type falls through to the platform fallback (typically the Page fallback). Operators bind a template either by setting a per-record assignment per record, or by marking a template as the default-for-type for that Custom Object type.

The eligibility model lets operators be explicit about which templates can render which Custom Object types. A template that bundles tight visual treatment for "Project" records can be marked eligible only for the Project type; the resolver will not return it for unrelated record classes.

For Custom Object types that need detail-and-listing pairs (one template for the per-record detail page, another for the type's listing pages), operators create both templates and bind each through the appropriate path. Listing-context binding follows the same cascade as detail-context binding; the resolver runs separately for each render.

Templates and SG-Builder

The link between SG-Core templates and SG-Builder is a one-way reference at the engine layer. Templates are SGEN records; SG-Builder is the editor used to author their bodies. When an operator opens a template in SG-Builder, the editor loads the template body, presents it for editing, and saves the modified body back to the template record on publish.

There is no separate template store in SG-Builder. The SG-Builder Templates Library surface is a curated view of the SGEN templates list — it filters by the template flag, presents per-record bodies for visual edit, and respects the same eligibility flags. Operators authoring a new template in SG-Builder are creating a new SGEN record with the template flag set; the record then enters the resolver's cascade like any other template.

Performance characteristics

The resolver is a single indexed lookup per render — the per-record binding is on the record itself, the per-type default is keyed by post-type, and the platform fallback is a constant. Cascade resolution adds no measurable cost to render time.

Template body rendering is the same cost as rendering any other SG-Builder document tree of equivalent complexity. Templates with heavy components (data-driven listings, complex queries) cost more per render; the cost is in the components, not in the template-resolution layer.

Documentation guidance

This page is the engine-side reference. For operator how-to (managing the master list, setting per-type defaults, handling eligibility) open SG-Admin Templates. For visual authoring open SG-Builder Templates Library.

Reading order

Read this page when you need to reason about how a record will render — what template the resolver picks, why a different template than expected was chosen, when an eligibility narrowing might shift behavior. Pair with the admin Templates module for the operator-side flow that creates and assigns templates.

Related reading

• SG-Admin Templates — operator module.
• SG-Builder Templates Library — visual authoring.
• Pages & Posts — the records templates render.
• Custom Objects — operator-defined record types in the same template-resolution path.

Vocabulary cross-reference

• Layout resolution — the cascade the resolver walks to pick a template for a record at render time.
• Per-record assignment — explicit template binding stored on the record.
• Per-type default — template marked as the default-for-type for a given record class.
• Platform fallback — the built-in last-resort layout the platform ships for every record class.
• Render fallback — the chain of fallback steps the resolver walks when earlier steps miss.
• Structural inheritance — sharing of layout fragments via SG-Builder components, not via template-to-template inheritance at the engine layer.
• Eligibility flag — per-template marker controlling which post-types a template can render.
• Binding anchor — point in a template body where record content is injected at render time.

Maintenance discipline

Update this Reference when:

• The resolver cascade changes (new step added, existing step semantics shift).
• New eligibility flags or assignment surfaces are introduced.
• The template-record storage shape changes (e.g. inheritance graph added).
• Render binding semantics shift (new anchor types, new fallback behavior on missing fields).
• Cross-cutting features (revisions, search, sitemap) start treating templates differently from other records.

Operator-side changes (new SG-Admin UI, new bulk-assign affordances) belong in SG-Admin Templates, not here. Authoring-surface changes (new SG-Builder template-builder affordances) belong in SG-Builder Templates Library.

Scope

This Reference covers the platform-level shape of templates: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.

Where to find it

Open your SG-Admin and navigate via the sidebar group that owns this surface. For platform-level reference (this page), the entry point is the SGEN documentation index at docs.sgen.com. For the operator-facing configuration screen, the entry point is the corresponding SG-Admin module page linked in Related features above.