Shopify OS 2.0 Sections & Blocks Explained

Shopify Online Store 2.0 organizes pages as editable systems. A template defines the arrangement for a resource type, sections perform larger page jobs, and blocks provide smaller pieces within compatible sections. App blocks add app-owned content, while dynamic sources connect settings to structured store data. This architecture lets merchants change many layouts without editing code, but the installed theme and version determine exactly which modules and relationships exist.

Think of scope before appearance. Templates answer which reusable page arrangement applies. Sections answer which major content modules appear and in what order. Blocks answer what smaller controls or content live inside one module. Global theme settings answer how recurring visual foundations behave. Choosing the correct scope prevents duplicate work and unexpected store-wide changes.

Templates provide the page arrangement

Every rendered resource uses a compatible template type. A product page needs a product template, a collection uses a collection template, and an article uses an article template. The default template can serve most resources, while alternate templates support recurring exceptions. A merchant might assign one product template to ordinary goods and another to made-to-order products that need measurements and longer lead-time guidance.

Online Store 2.0 commonly uses JSON templates. These data files list section instances, their settings, and their order; the HTML and Liquid live in referenced sections. Merchants can add, remove, and rearrange eligible sections through the editor. A JSON template is not a free-form code canvas. Shopify defines its schema, and the section’s own schema controls whether it is available in a particular template.

Assignments matter. Editing the default product template changes presentation for every product assigned to it, not just the product currently shown in preview. Before moving a section, identify the template name and affected resources. Create an alternate only for a stable, repeated content model. A separate template for every item usually signals that product facts should be stored as metafields instead.

Sections own substantial content jobs

A section is a reusable Liquid module with merchant-facing settings. Examples include the main product information area, featured collection, image with text, newsletter, recommendations, or rich text. Sections can carry their own schema, styles, and scripts. Their settings should describe choices at section scope, such as layout, scheme, alignment, media position, or heading.

Dynamic sections referenced by JSON templates can generally be added, removed, and reordered when their schema and presets permit it. Static sections embedded in older Liquid structures are less flexible and may represent one shared instance. Do not infer capability from the name alone. Check the actual theme architecture and editor behavior before promising that a merchant can relocate or duplicate a module.

Header and footer often use section groups. These containers let merchants arrange suitable sections in shared layout regions. Their reach is broad: a menu, announcement, localization control, or app content added there can appear across storefront routes. Review group changes on product, collection, search, cart, article, and policy pages, including narrow mobile states.

Blocks make a section internally flexible

A block is smaller than its containing section. Inside product information, blocks might represent title, price, variant picker, inventory message, description, purchase buttons, or complementary content. In an image section, blocks might supply slides or text elements. A section defines which block types it accepts, their limits, and whether required blocks can be removed or reordered.

Shopify distinguishes section blocks, theme blocks, and app blocks. Section blocks are defined for one section and make sense only there. Theme blocks are reusable Liquid files that supported sections can accept; newer architectures can allow nesting within documented limits. App blocks come from installed applications and let merchants position app functionality without pasting global integration code. A section can constrain which sources it accepts.

Nesting is a composition tool, not an invitation to recreate an entire site inside one module. Deep hierarchies make selection, ordering, accessibility, and responsive behavior harder to reason about. Give each block one understandable content responsibility, use logical reading order, and test long labels or missing values. Reuse a theme block when the same interface and data contract genuinely appear in multiple sections.

Settings and dynamic sources connect content

Section and block schema exposes settings such as text, images, links, selections, colors, alignments, or compatible resource references. Static values belong to that particular instance. A dynamic source instead connects an eligible setting to metafield or metaobject data associated with the current product, collection, page, article, or other supported resource. The same template can therefore show different factual values without being copied.

Use dynamic content for stable structured facts: dimensions, care, ingredients, compatibility, author details, or reusable records. Define ownership and missing-value behavior first. Connect one complete record and one incomplete record to see whether headings, separators, or empty containers remain. Not every setting accepts every source, and compatibility varies. The absence of a connector is a design constraint to investigate, not a cue to duplicate data manually.

Build a product page with correct scope

Start with the default product template and its main information section. Order essential blocks around the buying decision: identity, price, options, availability, purchase action, delivery, and returns. Add separate sections for richer storytelling, recommendations, or editorial material. Connect product-specific structured facts dynamically. Add an app block only where its function belongs in the reading and interaction sequence.

Test a normal item, unavailable combination, sale item, missing optional field, long translated title, and product assigned to an alternate template. Reorder a block, hide a section, and preview mobile. Verify that state remains clear and the editor does not expose empty or misleading controls. This short exercise reveals whether content belongs at template, section, block, app, or data scope.

Platform limits are guardrails, not design goals

Shopify publishes limits for sections, blocks, nesting, and templates, and theme code can impose narrower limits. Those numbers describe allowed structure, not a recommended amount of content. A page approaching a technical ceiling likely creates a customer hierarchy and maintenance problem first. Prefer fewer meaningful modules, clear names, and reusable data over maximizing the editor’s capacity.

Availability also depends on presets and schema restrictions. A section without an eligible preset might not appear in Add section even though its file exists. A block may only work inside particular parents. Required blocks might be configurable or hideable but not removable. Read the picker and documentation as a contract; do not modify JSON blindly to force an unsupported relationship.

1. Choose the compatible template and confirm which resources are assigned to it.
2. Use sections for substantial page jobs and settings that affect the complete module.
3. Use blocks for smaller, reorderable content or controls inside a supported parent.
4. Prefer app blocks over pasted global code when the integration provides them.
5. Connect structured resource facts through compatible dynamic sources and test absence.
6. Preview shared regions, alternate templates, mobile order, keyboard behavior, and difficult content.

Common architecture mistakes

The first mistake is editing the wrong scope. A merchant changes a default template while viewing one product and unintentionally updates hundreds. Recover by restoring the prior draft arrangement, creating an alternate only if necessary, and reviewing assignments before publication. The second is copying an entire section to change one product fact; recover by defining the fact as structured data and connecting it dynamically.

The third is installing an app for a simple layout gap without understanding ownership. The result can add scripts, duplicate content, or introduce controls outside the theme system. Confirm native section and block options first, then evaluate an app’s permissions, performance, accessibility, support, and removal path. The fourth is hiding abandoned experiments instead of removing or documenting them, leaving future editors unable to distinguish deliberate states from debris.

Developers can also create editor failures by assuming page-load JavaScript runs whenever a section re-renders. Theme editor operations can replace markup dynamically. Custom interactive sections need lifecycle handling consistent with the theme. Merchants should report the exact add, reorder, select, or duplicate action that fails rather than accepting an editor-only defect because the public page initially looks correct.

Plan an editorial landing page

Consider a campaign landing page reused for seasonal collections. The template provides the arrangement and assignment boundary. A hero section owns its image, heading, supporting copy, and action blocks. A product-list section owns merchandising and card presentation. A reusable editorial theme block can appear in compatible sections, while a loyalty app block occupies the point where its member benefit becomes relevant. Campaign facts stored in a metaobject feed eligible settings through dynamic sources.

The editor tests a winter record with long copy, an empty secondary action, six products, and a missing editorial image. They reorder the supporting modules and inspect keyboard plus mobile reading sequence. The hero handles absence without leaving a blank container, the product section keeps truthful inventory state, and the loyalty surface remains clearly app-owned. One template now supports repeated campaigns without copying sections or detaching facts into prose.

A request to place the product grid inside the hero is rejected because neither module supports that relationship and the resulting nesting would mix distinct responsibilities. The team instead keeps the sections adjacent and adjusts their supported spacing. Architecture becomes a product decision: preserving understandable ownership is more valuable than reproducing a mockup literally. If a future theme component supports the combined job accessibly, it can be evaluated as an explicit replacement.

Document the template assignment, accepted section types, reusable block contract, app dependency, dynamic records, and fallback states. This small map helps content editors know where to make changes and lets developers assess updates without rediscovering the page during every seasonal content and design review. A composable storefront remains flexible because its boundaries are visible, testable, and owned, not because every element can be dropped anywhere.

Before handoff, ask a second editor to locate and replace one campaign record without developer guidance. Their path through the editor verifies whether those architectural boundaries are understandable in daily use.

Conclusion

Online Store 2.0 is easiest to maintain when every decision lives at its natural scope. Templates arrange resource pages, sections perform major jobs, blocks compose their internal content, app blocks place integrations, and dynamic sources supply structured facts. Use the installed theme as the capability contract, keep page hierarchy well below technical limits, and test assignments plus edge states before publishing.

Frequently asked questions

Can any section be added to every page?

No. Availability depends on template type, theme version, section presets, and schema restrictions. Confirm it in the target editor.

What is the difference between a section block and a theme block?

A section block is defined for one section. A theme block is a reusable file that compatible sections can accept, subject to the theme’s architecture and constraints.

Does hiding a section delete its content?

Behavior depends on the editor action and architecture. Hiding typically preserves configuration while preventing rendering; deletion removes the instance. Confirm before cleanup.

Are dynamic sources the same as app blocks?

No. A dynamic source supplies compatible stored data to a setting. An app block supplies application-owned storefront functionality or content.