Shopify sections and blocks explained

Sections and blocks are what made Online Store 2.0 a genuine improvement rather than a rename. A section is a self-contained piece of a page with its own settings. A block is a repeatable element inside a section. Together they're what lets a merchant rearrange a page in the theme editor without touching code — which is the entire promise of a modern Shopify theme.

The anatomy of a section

A section file lives in sections/ — see the theme file structure — and has two parts: Liquid markup, and a {% schema %} block of JSON at the bottom describing its settings.

```liquid

{% schema %} { "name": "Feature list", "settings": [ { "type": "text", "id": "heading", "label": "Heading", "default": "Why buy from us" } ], "blocks": [ { "type": "feature", "name": "Feature", "settings": [ { "type": "text", "id": "title", "label": "Title" }, { "type": "richtext", "id": "text", "label": "Description" } ] } ], "max_blocks": 6, "presets": [{ "name": "Feature list", "blocks": [{ "type": "feature" }, { "type": "feature" }] }] } {% endschema %} ```

Three details that matter:

• block.shopify_attributes is what makes a block clickable in the theme editor. Omit it and the merchant can't select the block visually. It's the single most commonly forgotten line in section development.
• presets decide what a merchant gets when they add the section. A preset with sensible defaults and a couple of blocks already in place makes the section feel finished; without it they get an empty box and assume it's broken.
• max_blocks caps repetition. Use it — a feature list with fourteen entries is a design failure you can prevent in the schema.

Section or block?

The rule: a section is a horizontal band of the page; a block is one item within it.

A three-column feature strip is one section with three blocks, not three sections. A testimonials carousel is one section, each testimonial a block. A hero and a product grid are two sections.

Getting this wrong in the direction of "everything is a section" produces a theme editor list forty entries long that nobody can reorder sensibly.

Section groups

Section groups extend the same model to the parts of the page that used to be hard-coded — header, footer, and any other area you define. They're declared in JSON files under sections/ and referenced from the layout, which means a merchant can add sections to the header area, and announcement bars stop needing to be theme settings.

If you're building a new theme, use section groups for header and footer from the start. Retrofitting them later means moving settings, and moving settings means merchants lose their configuration.

Designing settings people actually use

This is the part that separates a good theme from a technically correct one.

• One section, one job. A universal "content section" with twenty settings covering four layouts is unusable. Three focused sections beat one flexible one every time.
• Label things in the merchant's language. "Heading above products", not "Section heading override". The person reading it has never seen your code.
• Defaults that look right immediately. Every setting should have a default that produces something presentable.
• Group and order settings the way someone would work through them — content first, then layout, then colour. header and paragraph schema types let you add structure and explanation.
• Don't expose what nobody will change. Every setting is a decision you're delegating. Delegate the ones that need delegating.

Static and dynamic sections

Sections can be placed dynamically by the merchant through JSON templates, or rendered statically in Liquid with {% section 'name' %} where the position is fixed. Static rendering is right for things that genuinely belong in one place; dynamic is right for everything else. Defaulting to static is how you end up with a theme the merchant can't rearrange — which was the problem 2.0 solved.

Blocks from apps

Sections can accept app blocks, so an app's UI can be placed by the merchant inside your section rather than injected into your code. Supporting them means adding a block of type @app to your schema — a one-line change that makes your theme substantially more compatible with the app ecosystem. Theme app extensions covers the other side of that relationship.

A section is a small product with a user. The Liquid is the easy half; the schema is where you decide whether that user has a good day.