Shopify's Liquid July '26 developer preview introduces two tags that change how a theme can be composed: {% block %} and {% partial %}. The first renders a reusable theme block directly from a Liquid template. The second names a server-rendered region that JavaScript can refresh without reloading the whole page.
The important word is preview. These tags are available only on development stores with the Liquid July '26 feature preview selected. Existing themes still work with sections, JSON templates, theme settings, and the established theme-block architecture. Treat the new model as something to evaluate, not as an immediate production migration.
What the new {% block %} tag changes
Theme blocks already live in /blocks and keep markup, settings, behavior, and accessibility concerns together. Until this preview, merchants normally placed dynamic blocks through the theme editor, while developers rendered them through content_for.
The new tag lets a Liquid template name and render a block directly:
{% block 'container' %}
<h1>Welcome</h1>
{% endblock %}That call maps to blocks/container.liquid. The content between the opening and closing tags becomes block.content inside the block file:
{% assign tag = tag | default: 'div' %}
<{{ tag }} class="{{ class }}">
{{ block.content }}
</{{ tag }}>
{% schema %}
{
"name": "Container",
"settings": []
}
{% endschema %}The result is a page structure you can understand by reading one Liquid template. The reusable implementation stays in /blocks, while page-specific content remains at the call site.
Passing named parameters
The tag follows the same mental model as {% render %}. A template can pass named values to a block rather than making the block depend on global variables or hidden assumptions:
{% block 'container', tag: 'section', class: 'page-width' %}
<h2>{{ collection.title }}</h2>
{% endblock %}Explicit arguments make a component easier to reuse and review. If a block needs a value, the call should make that dependency visible. Shopify's new Theme Check rules can also compare block arguments with schemas and {% doc %} declarations, which makes accurate documentation more valuable.
Do not confuse this preview tag with the current theme-block model. Our theme blocks guide explains content_for, merchant-managed blocks, nesting, and presets in today's architecture. The preview adds another way to place those blocks; it does not invalidate the existing one.
What {% partial %} does
A partial is a named region of server-rendered HTML. It renders normally on the first request, but its name gives JavaScript a target that can be fetched and replaced later.
For example, a collection template can identify only the product grid as replaceable:
{% partial 'product-grid' %}
{% for product in collection.products %}
{% render 'product-card', product: product %}
{% endfor %}
{% endpartial %}Filtering or sorting can then refresh the grid without rebuilding the header, filters, footer, or the rest of the page in a client-side framework. Liquid remains responsible for the HTML, so the initial and updated markup share one server-side source.
The design rule is simple: wrap the smallest region that changes. A partial around the entire page throws away much of the performance and state-management benefit. A partial around the results grid, cart contents, or another focused region gives the browser a precise replacement target.
Blocks and partials solve different problems
| Feature | Main job | Best mental model |
|---|---|---|
{% block %} |
Compose a template from reusable theme blocks | A server-rendered component call |
{% partial %} |
Mark HTML that can be refreshed independently | A named server-rendered update region |
{% render %} |
Render an isolated snippet | A reusable Liquid include |
{% content_for 'blocks' %} |
Render merchant-managed theme blocks | An editor-controlled block area |
You can combine the ideas: a partial might contain a product-grid block, and that block might render product-card snippets. Each layer should have one clear responsibility.
Why this matters for Liquid-first storefronts
Modern interactive storefronts often duplicate rendering logic: Liquid generates the first page, then JavaScript or a framework builds later states. That split can create inconsistent markup, larger bundles, and accessibility regressions.
Partials keep refreshed HTML on the server. Blocks keep reusable page structure readable in Liquid. Together they offer a path to dynamic interactions without turning a theme into a client-rendered application.
The preview also ships with Theme Check 3.28 rules for syntax errors, excessive complexity, oversized files, invalid schema, and mismatches between arguments, schemas, and documentation. That is a useful signal: Shopify wants Liquid-first themes to remain explicit and maintainable as they become more capable.
A safe evaluation plan
- Create or use a development store with the Liquid July '26 changes preview enabled.
- Test a small, non-critical template rather than porting an entire production theme.
- Build one reusable block with a narrow argument contract.
- Wrap one independently changing region in a partial.
- Test keyboard focus, live-region announcements, loading states, browser history, and failure recovery after an update.
- Run the current Theme Check release and fix preview-specific findings.
- Keep the production implementation on stable Liquid until Shopify moves the feature beyond preview.
Accessibility needs deliberate attention when a partial replaces content. Preserve focus where possible, announce meaningful updates, and avoid replacing a region while a buyer is interacting with a control inside it.
Should you migrate now?
No broad migration is necessary. Existing section and JSON-template themes remain supported. Use this preview when you are starting a new experimental theme, exploring Liquid-first composition, or prototyping a server-rendered interaction that currently requires substantial client code.
For production work today, keep using stable theme blocks, snippets, sections, and the Section Rendering API where appropriate. The official developer-preview announcement, block reference, and partial reference should remain your source of truth because preview syntax can evolve.
When you are working with stable sections, use the Schema Builder to assemble settings and the HTML to Liquid converter to turn an existing component into a practical starting point.