Per-Collection Hero Banner Driven Entirely by Collection Metafields

One section instance in the collection template serves every collection: its heading, copy and two separately cropped artworks are bound to collection metafields through dynamic sources, and it renders two independent breakpoint layouts from them, so launching a collection is a merchandising task rather than a theme edit.

A collection template's section settings are shared by every collection that uses the template, so a hero typed into the theme editor is the same hero on every collection. This section keeps plain heading, text and image settings and binds them to four collection metafields through dynamic sources — two of them separately cropped artworks — so a new collection gets its own hero by filling four fields, and the theme never changes.

The Problem

A Shopify collection carries one image and one description, and a collection template is one file shared by every collection assigned to it. Whatever a merchandiser types into a section on that template — a heading, a subheading, an uploaded banner — appears on every collection the template serves. The platform offers two ways out, and both are bad at scale: make a template per collection, so that each has its own settings and the theme grows by one template per launch, or have someone edit the theme every time a collection launches.

LUS Brands needed every collection to have its own full-bleed hero: distinct desktop and mobile artwork, its own headline, its own description. Not a colored band with the collection title in it. A hero.

The Constraint

The values couldn't live in the theme editor, because the theme editor's values are per template. Shopify's dynamic sources solve exactly this — a setting can be connected to a metafield instead of typed — but a dynamic source only maps a metafield onto a setting of a compatible type. A text metafield feeds a text setting; a file metafield feeds an image picker. The section has to be designed so that its settings are the shape of the data.

The artwork was the harder half. The desktop banner is a wide 1440-by-630 composition; the mobile banner is a taller crop with different framing. One responsive image can't serve both, because they aren't the same picture at two sizes. They're two pictures. That meant two file metafields, two settings and two complete image pipelines in one section — and a mobile layout that could differ from the desktop one in more than width.

The section also had to render nothing at all for a collection with no banner metafields, rather than an empty band, because not every collection would have art on day one.

What We Built

de_collection_banner.liquid exposes ordinary settings — a heading, a description, an image picker for desktop and one for mobile — and the collection.json template connects them to dynamic sources: collection.metafields.custom.collection_banner_title, collection.metafields.custom.collection_banner_text, collection.metafields.custom.coll_banner_desktop and collection.metafields.custom.coll_banner_mobile. The section code knows nothing about metafields. It reads settings; the template decides where the settings come from.

Two wrappers, not one responsive one. The section renders .luc-hero__desktop-wrap and .luc-hero__mobile-wrap as independent trees. Each has its own image with its own WebP srcset ladder, its own optional product overlay image, its own fixed-height setting and its own text block. That independence is what lets the desktop layout be a half-width text column over a right-side product shot while the mobile layout is bottom-anchored, centered text over a portrait crop. They share the four metafields and nothing else.

Layout controls. Colors, per-breakpoint heading sizes and heights are section settings, so the merchandising team can tune the frame in the theme editor while the content inside it comes from the collection. The desktop text column's left padding is computed as calc((100vw - min(100vw, var(--page-width))) / 2 + 4rem), which aligns the copy to the theme's content width without wrapping the image in a page-width container that would constrain it.

Its own loading priority. The section checks section.index == 1 and, when it's the first section on the page, promotes its image to loading="eager" with fetchpriority="high"; otherwise it lazy-loads. It behaves correctly as a hero and correctly as a mid-page banner without a setting to get wrong.

Why This Way

Binding the section to metafields moves collection launches out of engineering. A merchandiser creates the collection, fills four fields on it and assigns the existing template; the banner appears. There's no template to duplicate and nothing to deploy. Keeping the section's settings ordinary — a heading, a text, two images — is what makes that binding possible, and it also means the same section could be dropped onto a page template with typed values if someone ever wanted that.

Keying the loading priority to section.index rather than to a checkbox means the hero is prioritized when it's the page's first element and not otherwise. Merchandisers can reorder sections without accidentally deprioritizing the largest image on the page.

The trade is on the content side. Four fields per collection, two of them artwork in specific crops, with nothing in the admin to tell a merchandiser that the mobile file is the wrong shape. And two independent wrappers mean two layouts to maintain: a copy change is one field, but a layout change is two code paths, and the mobile text colors are forced with !important over the shared color settings so light artwork can't wash out the mobile copy — a rule that has to be remembered when the shared settings change.

Why Not an App

Collection-banner apps exist for precisely this, and they work by holding the per-collection art in the app and injecting it into the page. The metafield binding gives the same per-collection authoring with no app, no app block and no extra request — and the artwork lives on the collection record, next to the collection it describes, where a bulk export or a future theme can find it.

Implementation Notes

• The whole section is wrapped in {% if desktop_banner_image != blank or mobile_banner_image != blank %}, so a collection with no banner metafields renders nothing at all rather than an empty colored band.
• The section carries data-de-section-reveal-skip, which tells the theme's global section-reveal animation to leave the hero alone: the first thing on the page shouldn't fade in.
• Images are served with explicit width and height attributes from the image object, so the box is reserved before decode and the page below doesn't shift.
• The desktop text column's padding is a calc() against --page-width, aligning copy to the content width while the image runs full-bleed.
• Alt text falls back from the image's own alt to the heading setting, so a banner uploaded without alt still has an accessible name that matches its headline.
• The metafield names are declared in the template's dynamic-source bindings, not in the section — the section stays a plain settings consumer.

Edge Cases

• Desktop-only or mobile-only artwork still renders: each wrapper is independently guarded, so a collection with one crop gets a banner on that breakpoint.
• The button renders only when both a label and a link are set, so a half-filled button setting produces nothing rather than a dead control.
• Overlay product images are optional and configured independently per breakpoint, so a desktop composition with a product shot doesn't force one onto mobile.
• Mobile text colors are forced with !important over the shared heading and description colors, so a light mobile crop doesn't wash out the copy.

Platform Primitives Used

• metafields — four collection metafields carry the title, the text and the two artworks; the section never reads them directly.
• dynamic-sources — the template connects each plain setting to its metafield, and that binding is what lets one section instance serve every collection.
• liquid-schema-settings — heading, text, two image pickers, colors, heights and per-breakpoint heading sizes are all section schema.

Where It Runs

On the collection listing, through one template: the standard collection template. Because the content is bound per collection, that single template placement is every collection that carries the four metafields — one section instance, as many heroes as there are collections with art.

What This Demonstrates

• Art-directed hero and banner system — the primary capability. Two artworks in two crops, two layouts, and a loading priority that's correct whether or not the hero is first.
• Metafield-driven PDP content blocks — the same storage decision, applied to a collection rather than a product: the content lives on the record, and the section reads it through a binding.

How We Know

One section file of roughly 460 lines, read from the theme, plus four metafield-export records that document the four collection metafields as new for the 2026 redesign, a technical meeting record from 2025 and two working-session records from spring 2026. The requirement predates the redesign: a banner for collection pages supporting both desktop and mobile was confirmed as desired in 2025, and in spring 2026 it hardened into two approved collection-page views, one with a hero image and one with a category-matched background color. The export's four new fields are precisely the desktop/mobile split the code renders. The binding itself is read from the template's dynamic-source declarations rather than from the section.

Related Builds

• Marketing image banner with mobile art, typography controls and highlight headings — the same storefront's typed banner: same two-crop problem, but its values live in the theme editor because it's placed per page, not per collection.
• DE Hero: art-directed image/video hero with layout controls — the campaign hero, where art direction goes through a single <picture> rather than two independent wrappers.
• Vertical filter rail and an in-place mobile filter accordion replacing Dawn's drill-down drawer — what sits under this banner on the same collection template.
• Collection page: three filter modes, in-grid promo blocks and infinite scroll — a different storefront's collection page, where the per-collection content is promotional tiles inside the grid rather than a hero above it.

The Buy-vs-Build Question

A banner app buys per-collection art held in the app and injected after paint. Building it bought art on the collection record, in the initial HTML, with the right loading priority — and cost four fields per collection and two layouts to maintain. Where structured content should live, and when a metafield is the right home for it rather than an app's database, is the question on the metafields and metaobjects architecture decision page.

Provenance & Evidence

• Client: LUS Brands — loveurcurls.com
• Surface: Collection listing
• Templates served: one — the collection template, bound per collection
• Complexity: Medium
• Attribution: Deploi-authored. The section and the dynamic-source bindings in the collection template are ours. They run in a theme built on Dawn 15.4.1, alongside Dawn's own collection sections.
• Status: Live, verified 2026-09-06
• Evidence: One Liquid section, four metafield-export records, a technical meeting record from 2025 and two client working-session records from spring 2026
• Confidence: Strong — the export's four new collection metafields are the split the code renders
• Primary capability: Art-directed hero and banner system

Ready to Give Every Collection Its Own Front Door?

You dream it. We build it. If a new collection on your store still means a ticket to a developer, Contact us today and we'll show you what it looks like when the hero is four fields on the collection itself.