The problem, and why it is worse than it sounds
You bought a theme. Six months later there is a new version with a fix you want.
For almost every theme sold outside the Shopify Theme Store, taking it means downloading a zip, uploading it as a new theme, and then rebuilding by hand everything you did in the theme editor: the sections you arranged on the homepage, the copy you rewrote, the colours you tuned, the blocks you added to the product page. None of it travels. It belongs to the old theme.
If you paid a developer to change anything, that is gone too.
So merchants do the rational thing and stop updating. Which means the fix you wanted is one you never take, and a year later you are running a version nobody supports on a Shopify that has moved on underneath you.
This is not a small complaint about a niche product. Shopify's own newest theme, Horizon, sits at 34% positive across 198 reviews, and the thing at the top of the negative ones is that updates deleted work people had paid for. On the three biggest direct-sold themes it is the same complaint in three different vocabularies: reinstalling after every release, lifetime buyers discovering that "lifetime" did not include a usable upgrade path, updates that "require coding experience or significant time".
It is the honest weak point of this entire category. It is also, as of 2026-08-06, not ours.
What we do instead
We do not send you a zip and wish you luck. We take the theme that is running on your store, merge the new release into it, and give you back a complete, unpublished theme with your own material already in place.
Every file in your theme falls into one of seven classes, and the rule for each is fixed rather than decided case by case:
| Files | What happens |
|---|---|
Your theme settings (config/settings_data.json) | Yours, wholesale. Never written |
Your templates and section groups (templates/*.json) | Yours, wholesale. Never written |
| Liquid you or a developer edited | Yours, kept, and named in the report |
| Liquid you never touched | Updated. This is the release |
Translations (locales/*.json) | Merged — new strings underneath your wording |
| Assets, and the settings schema | Updated. They are build output |
| Files you added that we never shipped | Left alone |
Two of those deserve the detail.
"Liquid you edited" is measured, not assumed. Every release records a checksum for every file it contains. When we pull your theme we compare each Liquid file against the checksum of the exact version you were shipped, so an edit is a fact we can point at rather than a guess. There is no heuristic and no "probably fine".
Translations merge rather than choosing a side. New-wins would delete wording
you rewrote; yours-wins would leave every string added this version rendering
translation missing on your storefront. Merchants do both — retranslate strings
and add keys — so both halves have to survive.
It cannot touch the store you are running
The merged theme is uploaded as a new, unpublished theme. You preview it, and you publish it when you are satisfied. Or you never publish it, and nothing has changed.
There is deliberately no --live mode and no way for us to write into a running
theme. That is worth stating as a design decision rather than a feature: a
vendor that can push straight to your published storefront is a vendor who can
break it at 2am on a Friday, and no amount of care makes that an acceptable thing
to hand somebody. The safe version of an in-place update is one click in an
interface you already trust, made by you.
Your old theme also stays in your library. If something surfaces after you publish, republish the old one — you are back in seconds.
What stops the update, on purpose
An edited layout/theme.liquid refuses the whole thing. That file is the
frame every page renders inside, and a stale one cannot render new sections.
Merging a customised copy of it is the one case where being clever produces a
theme that is broken in a way neither side chose. So it stops, says so, and we
work through that file with you.
A file we removed this version is named, not silently dropped. If one of your templates still references a section that no longer exists, the merged theme would answer HTTP 500 on every route that uses it.
Which is why the merged theme is checked before anything is uploaded — the same structural checks the release itself has to pass, run over the merged result rather than over our build. That is the entire argument for merging the files on disk instead of patching them through the API: on disk, the finished thing can be inspected before it exists anywhere near your store.
The evidence
This is a claim about our own product, so here is the run behind it.
On 2026-08-06 a real store was taken from 0.1.0 to 0.2.0 by this process, and the result was checked against Shopify's API rather than by eye:
config/settings_data.json— byte-for-byte identical to the old theme.templates/index.json— byte-for-byte identical.assets/core.js— equal to the new build, and different from the old one. The update actually happened.- A comment left in
footer.liquid— still there. - The locale file — carrying both the store's own key and the new one 0.2.0 added.
- The live theme's last-modified date — over a week earlier. Untouched, as promised.
Two defects were found doing it, both of which only a real store could show.
--theme-name is not a flag on Shopify's CLI, which is a five-minute fix. The
second was not: Shopify writes a /* … */ banner into editor-managed JSON,
including the locale files, and the merge parsed them strictly and fell back to
an empty object on failure — silently replacing every merchant translation with
the new baseline. The exact outcome this command exists to prevent, with nothing
on screen. It now strips the banner, and an unparseable file throws instead of
guessing.
We mention that because a page claiming a mechanism works is worth less than a page showing what it got wrong on the way.
What it costs you
It is not self-service. You email us; we do not have a button in your admin.
A Theme Store theme updates without anybody being involved, and if that matters to you more than your customisations do, that is a real preference and Shopify's free themes serve it better. We are not going to pretend otherwise on the page that is trying to sell you something.
What we need from you is a Theme Access token, which you create yourself from Shopify's Theme Access app and revoke from the same place whenever you like. It grants theme files and nothing else — not orders, not customers, not payouts.
And if you would rather not hand one over at all, the manual path still works and is written up in full. You are never blocked from a new version; the merge is a service on top, not a gate in front.
Which edition
Both. This is how the theme is delivered rather than something inside the zip, so it is not a Pro feature and it is not a paid add-on. Full details of the process, including the manual path, are in updating to a new version.