Sections support the `{% schema %}` Liquid tag. This tag allows you to define various attributes of a section, such as the section name, any section blocks, and settings to allow for theme editor customization options. ## Schema Each section can have only a single `{% schema %}` tag, which must contain only valid JSON using the attributes listed in [Content](#content). The tag can be placed anywhere within the section file, but it can’t be nested inside another Liquid tag. > Caution: > Having more than one `{% schema %}` tag, or placing it inside another Liquid tag, will result in an error. The following is an example of a valid section schema. For details on each attribute, refer to [Content](#content).

## Content The content of `{% schema %}` can include the following attributes: - [name](#name) - [tag](#tag) - [class](#class) - [limit](#limit) - [settings](#settings) - [blocks](#blocks) - [max_blocks](#max_blocks) - [presets](#presets) - [default](#default) - [locales](#locales) In addition, you can use one of the following attributes to specify where a section can be used: - [enabled_on](#enabled_on): Limit a section to specific templates and section groups. - [disabled_on](#disabled_on): Prevent a section from being used in specific templates and section groups. > Note: > The `{% schema %}` tag is a Liquid tag. However, it doesn’t output its contents, or render any Liquid included inside it. You should also consider making your section compatible with [app blocks](/docs/storefronts/themes/architecture/blocks/app-blocks). App blocks allow app developers to create blocks for merchants to add app content to their theme without having to directly edit their theme code. ### name The `name` attribute determines the section title that is shown in the theme editor. For example, the following schema returns the following output: ```json {% schema %} { "name": "Slideshow" } {% endschema %} ```

### tag By default, when Shopify renders a section, it’s wrapped in a `
` element with a unique `id` attribute: ```html
// Output of the section content
``` If you don’t want to use a `
`, then you can specify which kind of HTML element to use with the `tag` attribute. The following are the accepted values: - `article` - `aside` - `div` - `footer` - `header` - `section` For example, the following schema returns the following output:

### class When Shopify renders a section, it’s wrapped in an HTML element with a class of `shopify-section`. You can add to that class with the `class` attribute:

### limit By default, there's no limit to how many times a section can be added to a template or section group. You can specify a limit of 1 or 2 with the `limit` attribute:

### settings You can create section specific [settings](/docs/storefronts/themes/architecture/settings/input-settings) to allow merchants to customize the section with the `settings` object:

> Caution: > All section setting IDs must be unique within each section. Having duplicate IDs within a section will result in an error. #### Access section settings Section settings can be accessed through the [`section` object](/docs/api/liquid/objects/section#section-settings). Refer to [Access settings](/docs/storefronts/themes/architecture/settings#access-settings) to learn more. > Tip: > If a section is [statically rendered](/docs/storefronts/themes/architecture/sections#statically-render-a-section), then there’s only one instance of the section across all static renderings, as a result they all share the same section setting values. ### blocks You can create blocks for a section. Blocks are reusable modules of content that can be added, removed, and reordered within a section. Blocks have the following attributes:
blocks attributes
Attribute Description >Required
type The block type. This is a free-form string that you can use as an identifier. You can access this value through the type attribute of the block object. Yes
name The block name, which will show as the block title in the theme editor. Yes
limit The number of blocks of this type that can be used. No
settings Any input or sidebar settings that you want for the block. Certain settings might be used as the title of the block in the theme editor. No
The following is an example of including blocks in a section:

> Caution: > All block names and types must be unique within each section, and all setting IDs must be unique within each block. Having duplicates will result in an error. #### Access block settings Block settings can be accessed through the [`block` object](/docs/api/liquid/objects/block#block-settings). Refer to [Access settings](/docs/storefronts/themes/architecture/settings#access-settings) to learn more. > Tip: > If a section is [statically rendered](/docs/storefronts/themes/architecture/sections#statically-render-a-section), then there’s only one instance of the section across all static renderings, meaning they all share the same block setting values. #### Render blocks You can render a section's blocks by looping over the `blocks` attribute of the [`section` object](/docs/api/liquid/objects/section#section-blocks): ```liquid {% for block in section.blocks %} {% case block.type %} {% when 'slide' %}
{{ block.settings.image | image_url: width: 2048 | image_tag }}
... {% endcase %} {% endfor %} ``` In the example above, each block's content is included inside a parent container, and that container has `{{ block.shopify_attributes }}` added as an attribute. Shopify's theme editor uses that attribute to identify blocks in its [JavaScript API](/docs/storefronts/themes/architecture/sections/integrate-sections-with-the-theme-editor#javascript-events). If your block is a single element, then ensure that the element has this attribute. > Caution: > Don't rely on the literal value of a [block's ID](/docs/api/liquid/objects/block#block-id) when you iterate over blocks. The ID is dynamically generated and is subject to change. The following is an example of relying on a literal value of a block's ID, which may break functionality in your theme if the ID changes: > > > ```liquid > {% for block in section.blocks %} > {%- if block.id == 'J6d9jV' -%} >

{{ block.settings.heading }}

> {% endif %} > {% endfor %} > ``` > #### Show dynamic block titles in the theme editor In certain cases, the theme editor can display an input setting value as the title of a block in the theme editor sidebar. This can help merchants to identify and rearrange blocks in a section. The theme editor checks [the `id` values](/docs/storefronts/themes/architecture/settings/input-settings#standard-attributes) of the settings in a block to determine the best one to use for the block title. The theme editor uses settings with the following `id` values, in order of precedence: 1. `heading` 2. `title` 3. `text` If a setting with a matching `id` value doesn't exist, then the block name is used as the title. For example, this block with a setting `id` of `heading` displays in the sidebar with the title `Welcome to our store`.

### max_blocks There’s a limit of 50 blocks per section. You can specify a lower limit with the `max_blocks` attribute. > Note: > [Static blocks](docs/storefronts/themes/architecture/blocks/theme-blocks/static-blocks) don't count toward this limit.

### presets Presets are default configurations of sections that enable users to easily add a section to a [JSON template](/docs/storefronts/themes/architecture/templates/json-templates) through the theme editor. Presets aren't related to [theme styles](/docs/storefronts/themes/architecture/config/settings-data-json#theme-styles) that are defined in `settings_data.json`. Presets have the following attributes:
presets attributes
Attribute Description >Required
name The preset name, which displays in the theme editor's Add block picker. Yes
settings A list of default values for any settings you might want to populate. Each entry should include the setting name and the value. No
blocks A list of default blocks that you might want to include. Each entry should be an object with attributes of type and settings. The type attribute value should reflect the type of the block that you want to include, and the settings object should be in the same format as the settings attribute above. No
The following is an example of including presets in a section:

> Tip: > Sections with presets shouldn't be [statically rendered](/docs/storefronts/themes/architecture/sections#statically-render-a-section). If you’re going to statically render a section, then you should use [default settings](#default). ### default If you statically render a section, then you can define a default configuration with the `default` object, which has the same attributes as the [preset object](#presets). The following is an example of including a default in a section:

> Tip: > You should only use the section `default` attribute for sections that will be reused, or installed on multiple themes or shops. Statically rendered sections that come pre-installed on a theme should have their default configuration defined by the `default` attribute for each individual setting. ### locales Sections can provide their own set of translated strings through the `locales` object. This is separate from the `locales` directory of the theme, which makes it a useful feature for sections that are meant to be installed on multiple themes or shops. The `locales` object has the following general format:

For example:

Any translations will show up under the **Sections** tab of the language editor for merchants to edit. When edits are made, the changes are saved directly to the applicable locale file, and the section schema is unchanged. These translations can be accessed through the Liquid [translation filter](/docs/api/liquid/filters/translate) (`t` filter) where the key will be in the following format: ```text sections.[section-name].[translation-description] ``` For example, if you want to reference the `title` translation from the example above, then use the following: ```liquid {{ "sections.slideshow.title" | t }} ``` ### enabled_on You can restrict a section to certain template page types and section group types by specifying them through the `enabled_on` attribute. `enabled_on`, along with `disabled_on`, replaces the `templates` attribute. > Caution: > You can use only one of `enabled_on` or [`disabled_on`](#disabled_on). `enabled_on` must have at least one of the following attributes:
enabled_on attributes
Attribute Description
templates

A list of the template page types where the section can be used.

Accepted values:

  • A list of page types
  • ["*"] (all template page types)
groups

A list of the section groups where the section can be used.

Accepted values:

  • A list of the section group types. Accepted values: header, footer, aside, and custom types in the format custom.<NAME>.
  • ["*"] (all section group types)
In the following example, the section is available to all templates, and to the `footer` section group:

### disabled_on You can prevent a section from being used on certain template page types and section group types by setting them in the `disabled_on` attribute. When you use `disabled_on`, the section is available to all templates and section groups except the ones that you specified. `disabled_on`, along with `enabled_on`, replaces the `templates` attribute. > Caution: > You can use only one of [`enabled_on`](#enabled_on) or `disabled_on`. `disabled_on` must have at least one of the following attributes:
disabled_on attributes
Attribute Description
templates

A list of the template page types where the section can't be used.

Accepted values:

  • A list of page types
  • ["*"] (all template page types)
groups

A list of the section groups where the section can't be used.

Accepted values:

  • A list of the section group types. Accepted values: header, footer, aside, and custom types in the format custom.<NAME>.
  • ["*"] (all section group types)
In the following example, the section is available to all templates other than `password` templates, and to all section groups other than `footer` section groups.

### App blocks If your section is part of a [JSON template](/docs/storefronts/themes/architecture/templates/json-templates) or [section group](/docs/storefronts/themes/architecture/section-groups), then you should support blocks of type `@app`. [App blocks](/docs/storefronts/themes/architecture/blocks/app-blocks) allow app developers to create blocks for merchants to add app content to their theme without having to directly edit theme code.