Skip to main content

The two files

Every theme has two JSON files at its root, and they do different jobs. You edit schema.json by hand when you add a setting. settings.json is normally written by the visual editor, though you can edit it directly to change a theme’s shipped defaults.

schema.json

Two top-level keys:
global.properties are theme-wide settings, available everywhere as global.properties.<id>. components declares each component type.

Property definition

Property types

A list with nested properties:

Component definition

For reference, how Canvas declares its global components:
There is no conditional-visibility key. A field cannot be hidden based on another field’s value. Handle dependent options in the component template instead, which is what the official themes do:

settings.json

How each part reaches your templates: Component instance IDs are arbitrary strings. A component that has multiple: true gets one entry per instance, so a page can have three hero entries with three different IDs, all rendering components/hero.njk.

Adding a setting

1

Declare it in schema.json

2

Read it with a fallback

For a toggle that defaults to true, test against false so an unset value still counts as on:
For a toggle that defaults to false, a plain truthiness check is enough. For everything else, use the inline conditional:
Defaults in schema.json are not backfilled into an existing settings.json. A merchant who installed your theme before you added a setting will have no value for it, so the fallback in the template is what they actually get. Always write one.

Nunjucks inside setting values

Setting values can contain Nunjucks expressions. They are evaluated when the template pipes the value through renderString:
Without renderString the value is printed literally, braces and all. Use it for any text setting where a merchant might reasonably want to interpolate their shop name or the current year.