Shopify's new Liquid block and partial tags: pages composed in Liquid, not JSON

To understand where a Shopify page's structure lives today, you open a JSON template to find the section order, open each section's {% schema %} to find which blocks it accepts, open the block files to find their settings, and hold the whole graph in your head. Nothing about that is wrong. It is just spread across four file types, none of which show you the page.

On July 21, 2026, Shopify shipped a developer preview that takes a different position: put the page structure back in the Liquid template, where you can read it top to bottom. Two new tags do the work, {% block %} and {% partial %}. This post is a working tour of both, using code from Shopify's own reference implementation.

The block tag, in one breath

The shape is deliberately familiar. If you can read {% render %}, you can read this:

1{% block 'name', named_parameter: value %}2  Body content3{% endblock %}

It renders blocks/name.liquid, the same folder your theme blocks already live in. Three details carry the weight:

• It takes named parameters. These are ordinary Liquid values the block file reads directly, like tag or class. You can also set schema settings inline with block.settings.<id>: value.
• It has body content. Everything between {% block %} and {% endblock %} is available inside the block as {{ block.content }}. This is the part {% render %} could never do, and it is what makes blocks compose into a page instead of just appearing on one.
• The closing tag is mandatory. Even with no body content, you write {% endblock %}.

That third bullet looks like pedantry until you see what it buys. Because a block wraps content rather than replacing it, blocks nest, and a nested block call is the page layout. Here is the skeleton theme's entire home page template:

1{% block 'container' %}2  {% block 'hello-world' %}{% endblock %}3{% endblock %}

No JSON. No section. No schema indirection. A container block wrapping a content block, in a file called templates/index.liquid, which is exactly where you would look for it.

What a block file looks like on the other side

The receiving end is a normal theme block with one addition: it renders {{ block.content }} wherever the caller's body content belongs. This is the skeleton theme's container block, the one every template composes through:

1{% doc %}2  Wraps composed page content in a semantic HTML element. Every template3  composes its page through a container block: the block owns the outer4  layout element and renders the composed body via {{ block.content }}.5 6  @param {string} [tag] - HTML element for the wrapper. Default: 'section'.7 8  @example Default section wrapper9  {% block 'container' %}10    <h1>{{ page.title }}</h1>11    {{ page.content }}12  {% endblock %}13 14  @example Override the wrapper element15  {% block 'container', tag: 'div' %}16    ...17  {% endblock %}18{% enddoc %}19 20{%- assign tag = tag | default: 'section' -%}21 22<{{ tag }} class="block-container" style="--text-align: {{ block.settings.alignment }};" {{ block.shopify_attributes }}>23  {{ block.content }}24</{{ tag }}>

Read the {% doc %} header carefully, because it is doing more than documentation here. @param {string} [tag] declares a named parameter that has nothing to do with the schema. It is not a merchant setting; it is an argument the developer passes at the call site. Blocks now have two distinct input channels: schema settings for merchants editing in the theme editor, and named parameters for developers composing in Liquid. Keeping those straight is the main new concept to absorb.

Everything else stays as you know it. {{ block.shopify_attributes }} still belongs on the root element so the theme editor can identify the block, and the block still carries a {% schema %} for its merchant-facing settings. What it does not carry, in this model, is presets.

A real template: the product page

Composition reads better with something substantial in it. The skeleton theme's product template is one container block holding plain markup and a standard product form:

1{% block 'container' %}2  <div class="product-images">3    {% for image in product.images %}4      {% render 'image', class: 'product-image', image: image %}5    {% endfor %}6  </div>7 8  <div class="product-info">9    <h1>{{ product.title }}</h1>10    <p>{{ product.price | money }}</p>11    <p>{{ product.description }}</p>12  </div>13 14  <div class="product-form">15    {% form 'product', product %}16      {% assign current_variant = product.selected_or_first_available_variant %}17 18      <select name="id">19        {% for variant in product.variants %}20          <option21            value="{{ variant.id }}"22            {% if variant == current_variant %}23              selected="selected"24            {% endif %}25          >26            {{ variant.title }} - {{ variant.price | money }}27          </option>28        {% endfor %}29      </select>30 31      <input type="text" name="quantity" min="1" value="1">32 33      <input type="submit" value="Add to cart">34      {{ form | payment_button }}35    {% endform %}36  </div>37{% endblock %}

Notice what did not change: {% render %} for snippets, {% form 'product' %} for the add-to-cart, {% paginate %} on the collection template, the money filter. The Liquid you already know is the Liquid you keep writing. What changed is the container it sits in.

The layout composes the same way. layout/theme.liquid wraps the header and footer blocks in their own containers and drops content_for_layout into a plain <main>, so each template is the composition root for its own page:

1<body>2  {% block 'container', tag: 'div' %}3    {% block 'header' -%}{%- endblock %}4  {% endblock %}5 6  <main>7    {{ content_for_layout }}8  </main>9 10  {% block 'container', tag: 'div' %}11    {% block 'footer' -%}{%- endblock %}12  {% endblock %}13</body>

The partial tag: server-rendered HTML that refreshes itself

The second tag solves a separate problem, and it is the more interesting one. Say a fragment of a page needs to update after an interaction. Today your options are to re-render the whole page, to reach for the Section Rendering API and structure your markup around sections to suit it, or to move that fragment's rendering into JavaScript and give up Liquid for it. Each has a cost, and the third one quietly duplicates your markup in two languages.

{% partial %} names a region of server-rendered HTML so JavaScript can ask the server for a fresh copy of just that region:

1{% partial 'name' %}...{% endpartial %}

The name in Liquid and the name in JavaScript have to match. That is the whole contract. Here is the skeleton theme's canonical example, a tip card whose sentence refreshes while its heading and control stay put:

1<div class="highlight" {{ block.shopify_attributes }}>2  <h3>{{ 'hello_world.liquid_tips_title' | t }}</h3>3 4  {% partial 'liquid-tip' %}5    {%- if tip_count > 0 -%}6      {%- assign index = seed | modulo: tip_count -%}7      {%- for tip in tips limit: 1 offset: index -%}8        <p class="highlight-description">{{ tip | t }}</p>9      {%- endfor -%}10    {%- endif -%}11  {% endpartial %}12 13  <p>14    <a role="button" tabindex="0" data-refresh-tip>15      {{ 'hello_world.liquid_tips_refresh' | t }}16    </a>17  </p>18</div>

And the JavaScript side is one call:

1import { partials } from "@shopify/partial-rendering";2 3async function refresh() {4  control.setAttribute("aria-disabled", "true");5 6  try {7    await partials.refresh("liquid-tip");8    flashTip();9  } finally {10    control.removeAttribute("aria-disabled");11  }12}13 14control?.addEventListener("click", refresh);

The payoff is that the tip's rendering logic exists once, in Liquid, on the server. There is no client-side template duplicating it, no JSON endpoint to define, no section restructured to fit a rendering API. Shopify's phrasing for the pair of tags is worth quoting: together they let you compose pages in Liquid and add dynamic storefront interactions without moving rendering into a client-side framework.

The architecture this implies

The tags are the visible change. The theme structure they enable is the real one. Shopify's reference theme sets rules that read as a genuine break from Online Store 2.0 conventions:

• No sections. No sections/ folder, no {% section %} or {% sections %} tags, no JSON templates, no schema presets.
• No Liquid-embedded assets. No {% stylesheet %}, no {% javascript %}. CSS and JavaScript live in assets/.
• Templates are the composition root. Each templates/*.liquid wraps its content in one or more container blocks, one per vertical slice. No section is created for markup used by a single page.
• Theme Check with zero overrides. The reference keeps a pristine extends: theme-check:recommended and fixes the Liquid rather than adding config exceptions.

Why Shopify is doing this

The stated goal is code that is easier to read, easier to maintain, and easier for AI tools to understand. That last clause is not filler. A coding agent asked to change a product page today has to traverse a JSON template, resolve section types to files, parse schemas, and infer which block accepts which setting, all before it can make an edit. Given one templates/product.liquid that contains the page, it reads the file and edits the file.

It is worth being clear-eyed about the tradeoff, because the JSON template model was not an accident. It exists so merchants can reorder and configure a page in the theme editor without touching code. Structure that moves into a .liquid file is structure a merchant cannot drag around. The preview keeps blocks, schemas, and shopify_attributes precisely so the editor still works on the parts that should be editable, and the reference theme drops presets because a developer-composed page does not need them. Expect the interesting arguments over the next year to be about exactly where that line sits.

How to try it

1. Create a development store with the Liquid July '26 developer preview enabled. Without it, the storefront does not know these tags.
2. Clone the skeleton theme rc-v2.0.0 branch. Read AGENTS.md first, then templates/product.liquid, then blocks/container.liquid. That order takes about ten minutes and explains the whole model.
3. Update Theme Check to 3.28.0 or later so the new Liquid-first rules actually run.
4. Build one page. Take a page you have already built with a section and a JSON template, and rebuild it as a .liquid template composed from blocks. The differences show up fastest on something you already know the shape of.

Do not migrate a production theme. Nothing is being taken away, there is no announced stabilisation date, and preview APIs change. The reason to spend an afternoon on this now is that theme architecture questions, where structure lives, what a merchant controls, what a developer composes, are the durable part of the job. The tags will settle. The judgment about how to arrange a theme is what you are actually building.