How stores, themes, and design elements relate

Several different records decide how a StoreConnect storefront looks, and they are not arranged in one chain. A theme controls the markup. Pages and content blocks hold the words and images. Menus hold navigation. The Store record ties them together and overrides pieces of them.

Use this article to work out which record to change to affect a given part of a page, and to understand why a setting you expect to find on the theme is on the store instead.

The store is the hub

Everything starts at the Store record. It points at one theme, and separately at the individual records that fill in the parts of the page the theme leaves open.

Store ├── Theme_Id__c ─────────────► Theme ├── Header_Menu_Id__c ───────► Menu ├── Footer_Menu_Id__c ───────► Menu ├── Home_Page_Id__c ─────────► Page ├── Terms_Page_Id__c ────────► Page ├── Header_Content_Block_Id__c ──► Content Block ├── Footer_Content_Block_Id__c ──► Content Block ├── Head_Content_Block_Id__c ────► Content Block ├── Body_Content_Block_Id__c ────► Content Block ├── Logo_Id__c / Favicon_Id__c / Social_Image_Id__c ──► Media └── Product_Placeholder_Id__c / Category_Placeholder_Id__c ──► Media

This is the part that surprises people. The header and footer are not theme files; they are content blocks selected on the store. Two stores can share a theme and still have different headers, and changing the header on one store does not touch the other.

The theme owns the markup

A Theme record is almost empty by itself. It has a name and little else. What matters are the four kinds of record that point at it:

Record	Holds	Article
Theme Template	Liquid markup, one record per template, identified by Key	Theme Template
Theme Asset	CSS, JavaScript, fonts, and images	Theme Asset
Theme Variable	Key-value settings the templates read	Theme Variable
Theme Locale	Translation strings	Theme Locale

All four carry a s_c__Theme_Id__c lookup. That is the whole theme model: the Theme record is a container, and its content lives in the records pointing back at it.

A theme does not need to be complete. Any template it does not supply falls back to the built-in base theme, which is why a brand-new theme renders a working storefront. See theme structure for the template keys and how that fallback resolves.

Pages and content blocks

A Page holds a route and its own body. Content blocks are the reusable pieces placed onto it, and they attach through a junction rather than a direct field:

Page ◄── Content Block Page ──► Content Block ◄── Content Block Child ──► Content Block

Looking at Content Block alone, you will find lookups to Media and nothing pointing at a page. The placement lives on Content Block Page, one record per block-on-a-page, each with its own Position. The same block can therefore appear on many pages in a different order on each.

The same pattern attaches blocks to products, categories, and articles, and Content Block Child nests blocks inside other blocks. Junction objects explains the pattern and lists them all.

Menus, styles, and scripts

Menu records hold Menu Item records, and a menu item can nest inside another menu item to build a dropdown. The store chooses which menu is the header and which is the footer.

Style Block and Script Block both attach to the Store, not the theme. They are how you add CSS or JavaScript to one store without editing a shared theme.

Which record do I change?

To change	Edit
Page structure and markup	A Theme Template on the theme
Colors, fonts, spacing	A Theme Asset (theme-supplement.css), or a Style Block for one store
Text or images in a page region	The Content Block placed there
What appears in the header or footer	The content block the Store points at
Navigation links	The Menu the store points at, and its Menu Items
Wording of a built-in label	A Theme Locale on the theme
A setting a template reads	A Theme Variable on the theme
Logo, favicon, placeholder images	The Media records the Store points at
Which theme a store uses	Theme on the Store record

Why the split matters

Themes are shared; stores are not. Anything that should differ between two stores running the same theme has to live on the store, which is why the header content block, menus, logo, and style blocks are all store-level. Anything that defines how the storefront is built lives on the theme, so improving a template improves every store using it.

When you are deciding where to put something, ask whether a second store on the same theme should get it automatically. If yes, it belongs on the theme. If no, it belongs on the store.

You should now be able to take any visible part of a storefront and name the record that controls it, and use the Referenced by table on any object reference article to see what else points at it.