Technical pain

Why Your Shopify Calculator Breaks (and How to Stop It)

Published June 2, 2026 · 9 min read · By Nelson Migueles, founder of Plomly

If you're reading this, you've probably had this exact moment: a customer emails you at 11 PM saying "your calculator on the bathroom tile page isn't working." You check on mobile — yep, the input field shows but the button does nothing. You panic, log into Shopify, and nothing's been touched in a week. So what changed?

The answer, almost always: the theme. Either Shopify pushed an update to the theme you're using, or you (or a designer) edited a section that lives in the same DOM tree as the calculator, and the JavaScript hook the calculator depended on no longer exists.

This article covers exactly why this happens technically, the 4 architectures merchants use for calculators on Shopify, and how to stop the cycle. Written for store owners who have already lost a working calculator once and don't want to do it again.

The short answer: it's the integration model

A calculator widget on a product page is JavaScript + HTML. The question is where that JavaScript lives and how it finds the page. There are four common models, and only one of them survives theme updates reliably.

1. Inline custom code — added to product.liquid by a developer or via the theme code editor.
2. Theme asset upload — a JS file dropped into the theme's assets/ folder and included via {{ 'calculator.js' | asset_url | script_tag }}.
3. External script — a Shopify app that injects a script tag into your theme using ScriptTag API (the old way).
4. Theme App Extension / App Block — Shopify's modern integration where the app provides a section that the merchant adds via the theme editor.

Models 1, 2, and 3 break. Model 4 doesn't. Here's why.

How each integration breaks

1. Inline custom code in product.liquid

You hire a developer. They open the theme code editor, find sections/product.liquid, and paste 200 lines of HTML + JavaScript inside the existing markup. It works on Tuesday. On Friday you switch themes (maybe a Black Friday redesign, maybe a Shopify-suggested upgrade), and the new theme has its own product.liquid with completely different structure. Your calculator code is gone, because it lived inside the old file.

Even if you don't switch themes, this fails when:

• You edit the product template in the theme editor and Shopify regenerates the JSON template, dropping anything that wasn't in the new section schema.
• Your developer updates jQuery (or the theme drops jQuery in a refresh — Dawn, Sense, Trade, Horizon, etc. don't include jQuery by default). Calculator selectors break.
• The product template moves from sectioned to non-sectioned or vice versa during a redesign.

The fundamental problem: the calculator code is tightly coupled to the theme version that existed when it was written. Themes evolve. Code doesn't.

2. Theme asset upload

Slightly better than inline. The calculator lives in assets/calculator.js, loaded via a script tag in theme.liquid or a snippet. When the theme updates, your assets folder usually survives — but the script tag often doesn't, because it was added to a section that got replaced.

You also still have the jQuery dependency problem. And the DOM selectors. If the new theme uses data-product-form instead of #product-form, your calculator can't find the form to inject into.

This model fails more silently than option 1 — the JavaScript loads, the console doesn't throw, but the widget doesn't appear because its target element doesn't exist in the new theme.

3. External script (legacy app, ScriptTag API)

Before 2021 this was the standard for Shopify apps. Your calculator app would call Shopify's ScriptTag API to inject <script src="https://app.example.com/widget.js"></script> into your theme. The script loaded on every page, sniffed the URL, and decided whether to render.

Problems:

• Performance. The script loaded on every page, including pages where the calculator wasn't needed. Bad for Core Web Vitals.
• DOM hunting. The script had to guess where on the page to render — looking for .product-form__buttons, #AddToCart, [data-product], etc. Different themes used different selectors. The script tried 5-10 patterns and gave up if none matched.
• Theme update collateral damage. When a theme refactored its DOM (which happens regularly), the calculator silently disappeared from product pages because none of the selectors matched any more.
• Shopify deprecation. As of 2024, Shopify has been pushing apps off ScriptTag toward Theme App Extensions. New apps submitted to the App Store can't use ScriptTag for theme injection.

4. Theme App Extension / App Block

This is the modern model and the only one that survives theme updates cleanly. Here's how it works:

1. The app developer ships an "app block" — a Liquid section file that lives inside the app, not inside your theme.
2. You open your theme editor → click on a product page section → "Add block" → select "Plomly calculator" (or whatever the app is called).
3. Shopify renders the block by calling the app's section template at runtime. The DOM structure is owned by the app, not the theme.
4. When you change themes, you re-add the block in the new theme editor. Two clicks.

The critical difference: the calculator's HTML/JS lives in the app, not in your theme. Theme updates can't break it because there's nothing to break. The integration point is a single block reference (a string in your theme's JSON template), not embedded code.

Comparing the four models

Model	Survives theme switch?	Survives theme edit?	Performance	Maintenance
Inline custom code	❌ Lost	⚠️ Often lost	Good	High (re-port every theme change)
Theme asset upload	⚠️ Sometimes survives	⚠️ Often breaks	Good	Medium
External script (ScriptTag)	⚠️ Often breaks	⚠️ Sometimes breaks	Bad (loads everywhere)	None (app handles), but unreliable
App Block (Theme App Extension)	✅ Easy re-add	✅ Survives	Best (only loads where used)	None

How to tell which model your current calculator uses

If you don't know which model your current calculator is using, here's how to check:

1. Open a product page where the calculator appears.
2. View page source (Ctrl+U or Cmd+Option+U).
3. Search for the script tag that loads the calculator JavaScript.

What you'll find:

• If the JavaScript is inline (a big block of <script>...</script> with calculator code embedded), it's model 1.
• If it's a script with a path like /cdn/shop/t/2/assets/calculator.js, it's model 2.
• If it's a script from an external domain (e.g. https://yourcalculatorapp.com/widget.js) loaded everywhere on the site, it's model 3.
• If the calculator's HTML is inside a <div> with attributes like data-shopify-app-block or the script loads only on pages where the block is added, it's model 4.

Open the theme editor and check the section list on a product page — if you see your calculator listed as a block alongside "Buy buttons", "Product description", etc., it's a Theme App Extension. That's model 4.

What to do if you're on models 1, 2, or 3

Three paths, ranked by long-term sanity:

A. Migrate to an app with Theme App Extension (recommended)

Install a calculator app that's built on Theme App Extension. Add the block to your product template. Configure your products through the app's admin. Delete the old custom code or uninstall the old app.

This is what Plomly does — every calculator on every product is an app block, not theme code. Theme updates are inert. We've watched merchants switch from Dawn to Sense to Horizon without re-doing anything.

Cost: usually $10-35/month for a paid app, free tiers for new apps.

B. Stay on custom code but document the integration ruthlessly

If you have a developer relationship that works and you want full control, document exactly:

• Which file the calculator code lives in.
• Which DOM elements it depends on (selectors).
• Which JavaScript libraries it requires (jQuery? Vanilla? Alpine?).
• How to re-port it to a new theme.

Keep a backup of the calculator code in a Git repo or a doc. When you switch themes, your developer can re-port in 2-4 hours instead of starting from scratch.

C. Hybrid: app for the calculator, theme for the styling

Some merchants want full visual control. The app provides the calculator logic and a default style; you override the CSS via your theme's theme.css to match your brand exactly. This keeps the logic update-safe while keeping the look custom.

Plomly supports this — every widget element has a stable CSS class you can override from your theme.

How Plomly is built to never break

For transparency, here's the architecture:

• Theme App Extension — every calculator and the AI chat are app blocks. You add them to your product template via the standard theme editor.
• Per-block configuration — when you add a block, the theme editor shows the block's settings (waste factor, primary color, default unit, etc.). The settings live in the theme's JSON template, not in our database, so they survive theme changes.
• Server-side calculation — the heavy logic runs on our backend, not in browser JavaScript. The widget calls our API, gets back a calculation, and renders. No DOM hunting, no library conflicts.
• Vanilla JS, no jQuery, no React — the widget weighs <15KB minified, no dependencies. Loads only on pages where the block is added.
• Catalog cached server-side — when the AI chat reads your catalog to propose products, it's our backend reading from our copy synced via webhooks. Customer-facing calls don't hit Shopify's API.

The net effect: when Shopify pushed the Horizon theme update last quarter, Plomly merchants saw no change in their calculator widget. Theme code merchants saw a flurry of "the calculator isn't working" tickets.

Frequently asked questions

I have a custom calculator that works fine right now. Should I migrate preemptively?

Honest answer: not necessarily. If you're on a stable theme and don't plan to redesign, the calculator will keep working. But the next time you switch themes or do a major redesign, expect to rebuild. If you redesign every 12-24 months, migration usually pays back within one redesign cycle.

I'm on an app that uses ScriptTag. When will it stop working?

Shopify hasn't published a deprecation deadline as of mid-2026. Existing ScriptTag injections still work. But Shopify is clearly pushing the ecosystem toward Theme App Extensions — every new app submitted has to use the modern approach. We expect a phased deprecation announcement at some point in the next 12-18 months.

Can I have the calculator on collection pages or only on product pages?

Theme App Extensions can target multiple page types. Plomly's block can be added to product pages (the main use case), collection pages (for a "quick calculator" filter), and even custom pages. Each block is independently configured.

What if my theme doesn't support app blocks at all?

Themes older than 2.0 (released 2021) don't support app blocks. If you're on Brooklyn, Debut, Narrative, Express, or other Vintage themes, you'd need to either upgrade to a 2.0 theme (Dawn, Sense, Trade, Horizon are all free) or use a calculator app that falls back to ScriptTag injection. Plomly requires a 2.0 theme — there are no Vintage theme workarounds.

Does the app block load on mobile?

Yes. The block is server-rendered HTML — it works on every device the storefront renders on, including mobile, tablet, and POS preview.

Will switching to Plomly cause downtime?

The migration is two steps: install Plomly, add the block to your product template. The old calculator continues to work until you remove it. Most merchants run both in parallel for a day, verify the new one works, then remove the old one. Zero downtime if you do it that way.

← Back to all articles