Shopify Sections vs Framer Components: Who Can Edit What

Shopify sections are theme blocks a merchant can reorder, duplicate and configure inside Shopify's theme editor — and nothing more than that. In Framer the equivalent is a component with props and variants, which a client edits directly on the canvas instead of through a settings panel. The practical difference is not visual: it is that a Shopify section's options were frozen by whoever wrote its schema, while a Framer component's options are whatever the designer decided to expose, changeable in an afternoon.

That distinction is the whole handoff conversation. Every agency that has shipped a Liquid theme knows the follow-up email: can you just make the headline smaller on mobile? This post maps exactly who can make which change in each model, with the real limits attached.

How Shopify Sections Work: Schema, Settings, and Section Groups

A section is a .liquid file plus a {% schema %} tag, and that schema is the contract. The schema declares the section settings a merchant will see — the Shopify schema settings types available are a fixed list (text, richtext, image_picker, color, range, select, and so on), and anything not declared there simply does not appear in the editor.

Blocks are the repeatable items inside a section: one slide, one testimonial, one feature row. Online Store 2.0 themes then organise sections into section groups — header, template body, footer — so a change propagates across pages. Shopify caps this: each template can hold up to 25 sections and 1,250 blocks in total, nested up to eight levels deep, and an individual section can carry up to 50 blocks.

Those numbers are generous. The ceiling that actually bites is narrower, and it is written into Shopify's own documentation.

Custom settings or options that the theme doesn't provide require editing theme code or contacting the theme developer.

— Shopify Help Center, Sections and blocks

Who Can Edit What: Shopify Sections vs Framer Components

This is the table to send a client before the build starts. "Merchant" means someone working only in the Shopify admin or the Framer editor with content access; "designer" means someone with full canvas or theme-editor design access; "developer" means someone writing Liquid, JSON or React.

Read the middle column top to bottom and the pattern is obvious: the merchant boundary sits exactly where new structure begins. Rearranging what exists is self-serve; defining what can exist is code. Framer moves that boundary one role to the left — the person who designed the site can change its structure without a deploy, because a component's props, variants and breakpoints are design-surface, not source files. Our guide to Shopify product page customization walks through the same wall on the highest-traffic template in a store.

Where Does the Shopify Section Ceiling Actually Hit?

Three places, consistently.

The first is a missing setting. A merchant wants the hero's overlay opacity at 40% instead of 60%, the schema exposes no opacity control, and a two-character change becomes a ticket. Shopify is explicit that merchants cannot add custom settings the theme does not provide.

The second is block-type rigidity. Shopify section settings allow reordering and moving compatible blocks between sections, but a Slide block only goes in a Slideshow section, required blocks cannot be deleted, and theme blocks and section blocks cannot be mixed in one section. Each of those rules is sensible and each one produces a support request.

The third is the long landing page. Merchants hit 25 sections on campaign pages built module-by-module, and the editor stops offering more. At that point the usual workaround is a custom Liquid section containing half the page — which hands all of it back to the developer. We covered the compounding version of this in why brands stop editing Shopify themes every launch.

What Replaces Sections When the Storefront Is Designed in Framer?

A component with properties and variants. One component, defined once; every instance on the site inherits the design and exposes only the fields the designer chose. Variants replace what Shopify handles with separate section types — a card with default, featured and sold out states is one component, not three sections. Breakpoint variants cover mobile, which in Liquid usually means media queries inside the section's CSS.

The equivalent of adding a schema setting is adding a property, and that is a design action rather than a code one. Nothing is validated, committed or deployed; the change lands on every instance at once. For catalog data the component reads from a CMS collection or, with FramerLink, straight from the Shopify Storefront API — so products, prices and stock stay in Shopify while the layout lives in Framer.

Can a Client Edit a Framer Site Without Breaking the Design?

Yes, and the mechanism is a role rather than a permissions guess. Framer's Content Editor role covers CMS content, localization and on-page editing across a workspace — copy, images and CMS entries, not the canvas structure. It bills at $10 per editor per month against $20 for a full editor seat, so handing a marketing team write access to text does not mean handing them the layout.

That is the closest structural analogue to the Shopify theme editor, and it draws the line in roughly the same place — with the difference that moving the line is a designer's decision, not a developer's sprint. The same role model is what makes a filtered collection page maintainable after launch, as in our Shopify collection page build in Framer.

Which Model Fits Your Handoff?

Stay on sections when the store's design is settled and the merchant's job is merchandising: swapping heroes, reordering proof, publishing campaigns inside an agreed system. Section groups and a well-written schema make that genuinely pleasant, and Shopify's own best-practice guidance is to group related settings rather than expose dozens of granular ones.

Move the front end to Framer when the design is still moving — when quarterly rebrands, new page types and layout experiments are the normal workload rather than the exception. In that world the expensive part is not building the section, it is waiting for the section to be built.

Either way, write the capability table into the handoff document. Most of the friction in a Shopify build is not technical; it is a client who believed "fully customizable" meant something the schema never promised.