The Problem
A merchant wanted the ability to turn off the "Sale" badge on product cards independently from the sold-out badge — useful when running a discount quietly, without visually flagging it storewide.
The Investigation
Before writing anything new, the first step was checking whether Dawn already had sale badge logic built in — and it did, living in snippets/card-product.liquid. The badge condition already checked for a real discount and product availability; it just had no merchant-facing toggle. The compare-at price display (strikethrough old price alongside the new price) was already working correctly on product cards everywhere — homepage, collections, and beyond. This wasn't a build-from-scratch job — it was finding existing logic and extending it safely, without disturbing what already worked.
The Fix
Two changes.
First, a new checkbox setting added to the "Badges" group in config/settings_schema.json:
Unlike an opt-in feature, this defaults to true — sale badges are generally wanted, so the merchant is choosing to turn the badge off, not turn it on from nothing.
Second, the existing badge condition in card-product.liquid was extended, not replaced:
Adding and settings.show_sale_badge to the existing elsif means the badge now requires three things to all be true: a real discount, availability, and the merchant's toggle being switched on.
One detail worth flagging: this same condition appears twice in card-product.liquid, once per card layout variant. Both needed the identical edit for the toggle to work consistently everywhere the badge could appear:
Seeing it in action
The new toggle sits in Theme Settings → Badges, alongside the theme's existing badge options:
With the toggle switched off, the same product card still shows its reduced price — just without the badge drawing attention to it:
Why it works
settings.show_sale_badge reads from global theme settings, not a section's own settings — which is why it's found under Theme Settings → Badges in the Theme Editor, not inside any individual section's settings panel. Using and in the existing condition keeps all prior logic fully intact while layering in one more requirement — a minimal, safe change to code that already worked.
Workflow
Feature branch → commit → PR → merge — this was the first job done with the full branch/PR/merge workflow rather than direct edits, establishing the Git discipline carried through every job since.
Full recipe: View on GitHub →
Running into this on your own store? I fix theme issues like this for Shopify merchants — get in touch if you'd like a hand.
