Reference → Footer — Reference

Footer — Reference

The Footer surface owns the bottom chrome that renders on every public page of an SGEN site. It carries column blocks, link groups, copyright text, social-icon strips, legal notices, and the conditional rules that swap variants per page type. Anything that appears under the main content region on the public site traces back to a template managed here.

This page is a reference for platform engineers and integrators who need to understand the surface before extending it, scripting against it, or building a multi-site rollout. Customer-facing how-tos live in the customer docs set; this page describes the shape of the surface, not the steps to drive it.

Overview

Footers live under the Appearance → Footer area in SG-Admin. The module renders three primary views — the footer list, the footer create / edit form, and the conditional-assignment matrix — and exposes write operations for create, duplicate, update, version snapshot, conditional rule assignment, and delete.

A site carries one active footer for each page-type context. Defaults exist for the global fallback, the blog index, the post detail, the product detail, the cart, the checkout, and the maintenance page. Each site can override any of these with a custom variant. The active variant resolves at render time by walking the page-type ladder from the most specific match down to the global fallback.

A footer record carries a row of columns, each column carrying a list of blocks. Blocks fall into one of a small set of types — heading, link list, free text, social-icon strip, newsletter subscribe, contact summary. Block content is authored once on the template; per-page overrides live in the Page record, not here.

Where it lives in SG-Admin:

Sidebar: SG-Admin → Appearance → Footer
URL prefix: /sg-admin/footer/
View templates: application/views/Admin/Appearance/Footer/

The module surface deliberately stays narrow. Logo assets are sourced from the Media library. Menu link sets are sourced from the Menus surface. Social profile URLs are sourced from Settings → Social. The footer template references these by id and does not duplicate their content.

┌──────────────────────────────────────────────────────────────────────┐│ SG-Admin → Appearance → Footer [+ New footer]│├──────────────────────────────────────────────────────────────────────┤│ Name Applies to Status Updated ││ ───────────────────── ──────────────────── ───────── ────────── ││ Default footer Global fallback Active 3 days ago ││ Blog footer Blog index + posts Active 1 week ago ││ Checkout footer Cart, checkout Active 4 days ago ││ Holiday footer (paused) Draft 2 weeks ago││ ││ [⋯ Edit] [⋯ Duplicate] [⋯ Assign] [⋯ Snapshot] [⋯ Delete] │└──────────────────────────────────────────────────────────────────────┘

Actions

The Footer surface exposes the following operations. Each is described by what it does to the data, not by its internal method name.

List and search

Returns the footer records on the site, with name, page-type assignment, status, and last-updated columns. Supports column sort and free-text filter. Driven by the standard SG-Admin data-table contract — responses arrive as a row collection plus a total count.

Create footer

Opens an empty footer form. Required at minimum: name. The form ships with a four-column layout and one heading block per column; the author edits column count (one to six), block order, and block content. Submit validates that no two footers carry the same assignment scope and persists the record.

Edit footer

Loads an existing record into the form, pre-populated with its column and block tree. Submit replaces the stored tree with the posted tree. Edits do not roll forward to historic snapshots; the prior shape is recoverable from the snapshot history.

Duplicate footer

Clones an existing record. The clone carries the suffix (copy) on its name, lands in draft status, and has its assignment scope cleared. Useful for seasonal variants and A/B variants that share a column scaffold.

Conditional assignment

Maps a footer record to one or more page-type contexts. The assignment matrix carries one row per context (global, blog index, post detail, product detail, cart, checkout, maintenance, custom page collection) and one column per available footer. Exactly one assignment per context is active at a time; setting a new assignment clears the prior one. The matrix exposes a preview link per assignment so the operator can verify the live shape before committing.

Version snapshot

Captures the current footer record as an immutable snapshot. Each snapshot carries the editor identity, a timestamp, and an optional note. Snapshots are listed in the Versions tab of the footer edit form and can be promoted back into the active record at any time.

Promote snapshot

Reverses a snapshot back into the active record. The current shape is captured into a fresh snapshot before the promotion runs, so no edit history is ever lost.

Delete

Removes a footer record. The surface refuses the action if the footer holds any active page-type assignment; the operator must reassign the affected contexts before delete is allowed.

Data model

A footer record carries the following fields. Field names below are the conceptual shape — on-disk column names match closely but are not contractually stable across releases.

Field	Type	Notes
`id`	integer	Primary key. Stable across edits.
`name`	string	Display name. Not unique.
`slug`	string	URL-safe handle. Unique within the site.
`status`	enum	`active`, `draft`, `archived`.
`assignments`	array	List of page-type contexts the footer renders on.
`columns`	array	Ordered list of column objects, each carrying a width hint and a block list.
`blocks`	array	Per-column ordered list. Each block has a type and a payload.
`created_by`	integer	User id of the original author.
`created_at`	timestamp	Set on create, immutable.
`updated_at`	timestamp	Touched on any edit.
`published_at`	timestamp	Set when status moves to active.

Column shape: each column has a width hint (1/4, 1/3, 1/2, full) and a vertical block order. The sum of widths in a row should resolve to a single twelve-column grid; the renderer normalizes overflow.

Block shape: every block carries a type slug, a render order, and a payload. Payload structure varies by type — a heading block carries text plus level; a link-list block carries a menu reference id; a social-icon block carries a set of profile slugs; a newsletter block carries a target form id.

FOOTER RECORD├── id integer primary key├── name string display├── slug string url-safe handle├── status enum active | draft | archived├── assignments array page-type contexts├── columns[]│ ├── width enum 1/4 | 1/3 | 1/2 | full│ └── blocks[]│ ├── type enum heading | links | text | social | subscribe | contact│ ├── order integer render position│ └── payload object type-specific fields├── created_by integer user id└── timestamps created_at, updated_at, published_at↓ on snapshotFOOTER VERSION RECORD(immutable; restorable via promote)

Permissions

Access to the Footer surface is gated at two layers.

Layer 1 — admin gate. Every action under SG-Admin passes through the platform's standard admin access check at request entry. An unauthenticated request never reaches the Footer surface.

Layer 2 — per-action capability. Each Footer action checks a capability associated with the calling operator's role. The default role configuration ships with three roles — Administrator, Editor, Viewer — and the capability map is:

Capability	Administrator	Editor	Viewer
List footers	✔	✔	✔
Create footer	✔	✔	—
Edit footer	✔	✔	—
Duplicate footer	✔	✔	—
Assign to page-type	✔	—	—
Snapshot	✔	✔	—
Promote snapshot	✔	—	—
Delete footer	✔	—	—

Custom roles defined under Settings → Roles override the default map. The capability slugs are stable; the role slugs are configurable.

Assignment guard. A footer cannot be deleted while it holds an active assignment. The surface lists the blocking contexts in the rejection payload so the operator can resolve them.

Audit. Every write — create, edit, duplicate, assignment change, snapshot, promote, delete — emits an Activity Log entry naming the acting operator, the target record, and the change shape.

ASSIGNMENT MATRIX Default Blog Checkout Holiday──────────────────────────────────────────────────────────────────────Global fallback ● ○ ○ ○Blog index ○ ● ○ ○Post detail ○ ● ○ ○Product detail ● ○ ○ ○Cart ○ ○ ● ○Checkout ○ ○ ● ○Maintenance page ● ○ ○ ○Seasonal collection ○ ○ ○ ●● = active assignment ○ = available

Related references

Header — Reference. Owns the top chrome. Same model shape — columns, blocks, page-type assignment, snapshot history.
Pages — Reference. Page records can override the resolved footer with a per-page footer slug, taking precedence over the assignment matrix.
Menus — Reference. Footer link-list blocks reference menu records by id; menu edits roll forward into footer renders without a footer edit.
Media — Reference. Logo and icon assets on footer blocks resolve against the Media library.
Settings — Reference. Social-profile URLs, copyright defaults, and locale strings used by footer blocks live under Settings.
Snippets — Reference. Small reusable text fragments embedded in footer text blocks pull from the snippets surface.

For the corresponding customer-facing walkthrough — designing a footer, swapping a variant for a campaign, restoring an older shape — see the Appearance section of the customer docs at /docs/appearance/footer.

Render resolution order

When a public page renders, the active footer is resolved through a five-step ladder. Understanding the order matters for any integration that swaps footer variants by campaign, page-type, or per-page override.

Per-page override. The page record's optional footer_slug field, if set, wins outright. The Pages surface exposes this field on the page edit form.
Page-type assignment. The footer assignment matrix is consulted for the page's resolved page-type. The most specific match wins (product detail beats global, blog index beats global).
Custom collection match. Page collections (a curated set of pages grouped under a label) can carry a collection-level footer assignment. The collection assignment beats page-type assignment when both apply.
Locale fallback. If the site runs multiple locales and the resolved footer has a locale-specific sibling, the sibling renders.
Global fallback. The footer marked as the global fallback in the assignment matrix renders if no other step resolved.

The renderer logs the resolution path in development mode so integrators can verify which step picked the rendered footer. In production, the resolution path is captured in the response header for the first request after a footer edit, then cached.

Cache invalidation. Footer edits invalidate the render cache for every page whose resolution path passes through the edited record. The invalidation runs asynchronously; a forced flush is available from the Settings → Cache surface.

Preview parity. The preview link from the assignment matrix uses the same resolution ladder as the live render, so an operator inspecting a variant before publish sees the same footer the visitor will see.

Multi-site rollout. A site connected to SG-Dashboard can declare a footer record as a dashboard-managed template. Edits to a managed template push to every connected site on the next render. Sites can opt out per record from the Dashboard → Templates surface.

On this page

Guides

Reference

Changelog

Roadmap