Theme architecture

Sellerlane themes use the Liquid template language with a structure familiar to anyone who has worked with Shopify Online Store 2.0 themes. A theme is a set of files — layout, templates, sections, blocks, snippets, config, locales, and assets — used for theme-rendered storefront pages. Customer account documents are the system-owned exception described below.

Directory layout

Folder	Contents
`layout/`	`theme.liquid` — the wrapper for theme-rendered pages (`<head>`, `{{ content_for_header }}`, header/footer, `{{ content_for_layout }}`)
`templates/`	One JSON file per normal page type (`index.json`, `product.json`, …); `robots.txt.liquid` is the supported Liquid-template exception
`sections/`	Reusable section files (`.liquid`) with a `{% schema %}` describing settings and blocks; section group files (`header.json`, `footer.json`, …) also live here
`blocks/`	Reusable theme blocks (`.liquid` with their own `{% schema %}`) that any compatible section can host
`snippets/`	Partials included with `{% render %}`
`assets/`	CSS, JS, images, fonts — referenced with `asset_url`
`config/`	`settings_schema.json` (global theme settings) and `settings_data.json` (their values and presets)
`locales/`	Translation files used by the `t` filter

Templates

A template defines what renders for one type of page. Sellerlane recognises this exact set of template types:

index · 404 · article · blog · cart · collection · list-collections · page · policy · password · product · search · gift_card · robots.txt · metaobject

Customer account documents are system-owned. Themes cannot provide or override templates/customers/*; the account shell instead inherits the store’s published semantic branding tokens (colors, typography, radii, logo, and favicon), and its copy comes from the platform locale catalog plus supported store-level content overrides. metaobject renders custom content entries as web pages, and gift_card is the printable gift-card page.

JSON templates

Normal templates (index.json, product.json, and the other page types) are an ordered list of section instances. Each instance names a section type and carries its own settings and blocks; the order array fixes the sequence on the page. This is the structure the visual editor reads and writes, so merchants can add, reorder, hide, and configure sections without changing Liquid.

templates/robots.txt.liquid is the supported Liquid-template exception. Other normal .liquid templates such as product.liquid are rejected rather than accepted outside the visual-editor model. You can create alternate JSON templates (such as product.landing.json) and assign them to specific products or pages — see Alternate templates.

Sections and blocks

A section is a self-contained, reusable block of the page. Its {% schema %} declares the settings merchants can edit, the block types it accepts, and any limits or presets.

{% schema %}
{
  "name": "Featured products",
  "settings": [
    { "type": "text", "id": "heading", "label": "Heading" },
    { "type": "collection", "id": "collection", "label": "Collection" }
  ],
  "blocks": [
    { "type": "product", "name": "Product", "settings": [] }
  ],
  "max_blocks": 12,
  "presets": [{ "name": "Featured products" }]
}
{% endschema %}

Theme blocks vs section blocks

There are two kinds of block, and a section uses one or the other — never both:

Section blocks are defined inline in the section’s own schema.blocks array. They are local to that section.
Theme blocks are standalone files in blocks/ with their own schema. A section opts in by listing the explicit block type, or by listing the @theme wildcard to accept every theme block in the store. Theme blocks are reusable across many sections.

See Theme blocks and Section schema for the full schema reference.

Section groups

A section group is a JSON file in sections/ that bundles several sections so they can be reused across many pages — typically the header and footer. Group files are rendered with the {% sections %} tag, which takes the group handle:

{% sections 'header' %}
...
{% sections 'footer' %}

A group file has a type, a name, a sections object (the instances), and an order array that fixes their sequence — the same shape as the sections/order in a JSON template. Valid group types are header, footer, aside, and custom.<name>. A group is capped at 25 sections.

The difference from a template: a template renders for one page type, while a group is a shared band (header, footer, aside) injected into the layout on every page that calls {% sections %}. Editing the header group once updates it storewide. See Section groups.

Settings and config

The config/ folder holds the global theme settings — the brand-wide controls (colours, typography, defaults) that apply across the whole theme:

settings_schema.json defines the settings, grouped into editor panels. It is the only place the color_scheme_group setting type is allowed — that type is theme-settings-only and cannot be used in a section or block schema.
settings_data.json holds the chosen values plus any named presets.

Section- and block-level settings, by contrast, live in each section’s or block’s own {% schema %}. For the full catalogue of input types — text, richtext, color, color_scheme, image_picker, collection, product, metaobject, and more — see Setting types.

Many text and resource settings support dynamic sources — binding a value to product fields or metafields so the right content renders per page automatically. See Dynamic sources.

How a page renders

Every storefront page is assembled the same way:

layout/theme.liquid wraps the page. {{ content_for_header }} injects the platform’s required head tags (analytics, asset preloads, theme metadata), and {{ content_for_layout }} is replaced by the rendered template body.
The JSON template is resolved for the page type and composed by rendering each section instance in order (robots.txt.liquid is the dedicated robots exception).
{% sections %} pulls in the header, footer, and any aside groups.
Sections and snippets resolve from the published compiled artifact, and asset_url references resolve through an allowlisted versioned CDN route so each live asset is cached immutably.

Versioning and publishing

Every theme keeps multiple versions, each with one of three statuses:

DRAFT — a version you can edit and preview safely without affecting shoppers.
LIVE — the single published version your storefront serves.
ARCHIVED — a retired version kept for history or rollback.

Editing happens on a draft. Saving validates the changed theme program; publishing validates and compiles the complete immutable version, stores its private bundles, writes the manifest last as the commit marker, and only then promotes it to LIVE. A compile or persistence failure leaves the previous live version authoritative. Each version carries a manifest hash that fingerprints its files, which is how the renderer and CDN resolve the right artifact and asset version. Themes can also be imported as a ZIP, which creates a new draft version.

See Shopify theme compatibility for the exact compiler, file/section/block limits, preview, storage, and runtime contract.

Next steps

Themes and the editor

The hub for theme management — Themes and editor.

Manage themes

Library, versions, publish, and rollback — Manage themes.

Visual editor

Add and configure sections and blocks — Visual editor guide.

Edit theme code

Open the file editor and import a ZIP — Edit theme code.

Reference: Section schema · Theme blocks · Section groups · Setting types · Theme assets (CSS/JS) · Locales and translation · Liquid objects · Liquid tags · Liquid filters