---
title: Shopify GitHub Theme Sync Rejected a File and Left the Old Code Live
url: https://ilogr.com/shopify-github-theme-sync-rejected-file/
published: 2026-10-24
updated: 2026-11-07
author: iLogr
categories: Shopify
reading_time: 10 min
description: A Liquid syntax error can stop Shopify applying a GitHub file, leaving the old version live. Read the sync log, gate merges, compare the published file.
---

# Shopify GitHub Theme Sync Rejected a File and Left the Old Code Live

**In short:** A Liquid syntax error in one file can stop Shopify applying it from a connected GitHub branch, leaving the old version live while the branch looks merged and healthy. Read the sync log, fail merges on Theme Check’s Liquid syntax check, and compare the published file with the branch.

## How do you fix a file that Shopify GitHub sync rejected?

1. **Read the sync log.** On the theme card in the theme library, select **View logs** beside the **Last saved** timestamp to see the last few version control events [1]. Look for the file name and a Liquid error such as `Unknown tag 'endcomment'`.
2. **Fix the syntax on the branch** and commit. The integration updates the theme whenever the connected branch is updated [1], so the corrected file goes in with the next commit once it parses.
3. **Keep the work that failed to deploy.** The branch copy is the one with your changes in it. Repair it. Do not replace it with the copy from the live theme, which is the old version.
4. **Confirm the published theme has the new file.** Make a separate empty folder and run `shopify theme pull` there with `--only` and either `--live` or `--theme` naming the currently published theme [2]. Never run the pull in your working theme folder. If the downloaded file matches the branch copy, the published theme had that file at the time of the pull.
5. **Stop it happening again.** Run Theme Check before merging and fail the merge on Liquid syntax errors only (the command is further down), and repeat the published-file comparison after any merge that touched a file you care about.

## What does a rejected sync look like on a connected theme?

Nothing obvious breaks. The storefront keeps working, because the theme still has the last version of the file it accepted. GitHub shows your change merged. And changes made in the admin still produce commits on the connected branch, with Shopify's bot as the author [1], so new commits keep arriving and the connection looks healthy.

Shopify's GitHub documentation does not describe what happens to one file it cannot apply. The field note below shows what we saw. A Shopify staff reply on Shopify's developer forum, about the stricter Liquid parsing introduced in January 2026, says that pushes and saves are blocked "in the same way that other syntax errors are blocked today" [3].

A missing visible change gets noticed. A missing performance change, such as a preload in `<head>`, does not: the page looks the same, and only the page source or a Lighthouse run shows it.

## Why did one missing comment tag keep the old file live?

A Liquid comment is a block. `{% comment %}` opens it and `{% endcomment %}` closes it; nothing between them is output, and any Liquid inside is parsed but not executed [4]. Remove the opening tag and the closing tag stands alone. The Liquid parser treats a tag it does not recognise at that level as an error, "Unknown tag 'endcomment'" [5], so the whole file fails to parse.

How does an opening tag go missing? In our case, through a merge conflict at the end of a file:

- A commit made by Shopify on the connected branch rewrote some conditions in a snippet and appended a comment block explaining the changes. Shopify announced in January 2026 that theme files not meeting its stricter Liquid parsing would be rewritten automatically, with a comment explaining what changed [6]. The commit itself does not say which process made it.
- A performance branch changed the lines just above, at the same end of the same snippet.
- Git reported a conflict there. It was resolved by hand, and the resolution kept the performance branch's new lines and the body of the comment, including `{% endcomment %}`, but not the `{% comment %}` line above it.

This is an easy mistake at the end of a file: the opening tag sits next to the lines being replaced, and the closing tag sits well below them. To see what a merge resolution kept and dropped, `git show --remerge-diff` on the merge commit compares the result with git's own automatic merge, conflict markers included [7]. In a test and on the real merge, it showed `-{% comment %}` on a line of its own. The default combined view of a merge can leave out hunks where the resolution took one side unchanged [7], so do not rely on it alone.

## What happened on a Shopify theme connected to GitHub?

**Field note.** An Online Store 2.0 theme connected through the Shopify GitHub integration, reconstructed from its version history.

- Two performance changes in one snippet were merged into the connected branch. The merge dropped the opening comment tag described above.
- Shopify reported "Unknown tag 'endcomment'" for the snippet, and the notes made when it was fixed say the live theme kept serving an older version of it.
- Before the fix, further theme editor changes kept producing Shopify commits on the connected branch. The connection looked healthy despite the rejected snippet.
- When the file was pulled from the live theme several days after the merge, it matched the pre-merge version byte for byte, with the same git blob hash. Neither performance change was in that live copy. With the recorded rejection, this suggests the file had stayed unchanged since the merge.
- The fix restored a valid file with both performance changes. The same snippet also held the conditions that Shopify's rewrite had changed, and the fix rewrote those as well. Read any rewrite commit that arrives on your branch as carefully as a pull request.

## Does Theme Check catch the missing tag before the merge?

Yes, if you look for the right check. **Field note (test, Shopify CLI 4.9.3).**

We rebuilt the merge on a small test theme: one branch appended a comment block to a snippet, the other replaced a script tag above it with a preload, git reported a conflict, and we applied the same resolution. Both branches passed `shopify theme check` with no offences before the merge. After it, Theme Check reported two errors on the closing tag, from `LiquidSyntaxError` and `LiquidHTMLSyntaxError`, both reading "Attempting to close LiquidTag 'comment' before it was opened without a matching 'comment'". The real merged file gave the same two errors. The versions before the merge and after the fix gave neither.

The difficulty is the rest of the report. Theme Check on the whole real theme at the merge reported about 200 errors and nearly 600 warnings across almost a hundred files, mostly translation and naming checks. By default Theme Check exits with code 1 when it finds any issue of error severity [8], so a gate built on that default failed at both the merge and the fix, and one syntax error is easy to miss among hundreds. A check limited to one rule avoids that noise, and [Catching Deleted Theme Assets Before a Shopify Deploy](https://ilogr.com/shopify-deleted-theme-assets-missingasset/) sets one up for missing asset files.

Only one file in the whole theme had a `LiquidSyntaxError`: the one Shopify rejected. Another section had a `LiquidHTMLSyntaxError` for a separate HTML-nesting error, and a version with the same offence had been committed by Shopify's bot from the theme editor months earlier, so Shopify had saved it. Theme Check lists `LiquidHTMLSyntaxError` as covering Liquid and HTML syntax errors and `LiquidSyntaxError` as covering Liquid syntax errors [9], and Shopify's page for the second says to fix them "so Theme Check and Shopify can parse the file consistently" [10]. In this theme, `LiquidSyntaxError` matched Shopify's own rejection.

A gate that fails only on that check takes three commands. It needs Bash, Shopify CLI and jq, reads the theme files and writes one report file outside the theme.

These commands only read theme files and write one temporary report, but test any change to a theme on an unpublished copy of the theme or a development store first, never on the live theme, and take a backup of the theme before editing it. You use this information at your own risk, and iLogr accepts no responsibility for any loss or damage.

```bash
report=$(mktemp "${TMPDIR:-/tmp}/theme-check.XXXXXX")
shopify theme check --config theme-check:recommended --output json > "$report" || true
jq -e '[.[].offenses[] | select(.check == "LiquidSyntaxError")] | length == 0' "$report"
```

Run them in Bash from the theme folder, on macOS, Linux or WSL. The first creates a separate report file for this run, so two CI jobs on the same machine cannot read each other's results. The last command decides: it prints `true` and exits with 0 when no file has a Liquid syntax error, prints `false` and exits with 1 when one does, and fails if the report is empty or broken, so a CI job or a pre-merge hook can stop on it. Three more details make it hard to fool. `--config theme-check:recommended` overrides any `.theme-check.yml` in the theme [11], so a repository setting that disables the check or ignores a folder cannot switch it off. Writing the report to a file means the result comes from jq, not from Theme Check's own exit code, which is 1 whenever any unrelated error exists. And `|| true` keeps a shell that stops on the first failure from stopping before jq runs. In a test, the gate still failed with the check disabled, folders ignored or an inline disable comment, passed on valid Liquid with an unrelated error, failed when Theme Check or the report was missing, and kept parallel runs apart.

Two limits. `LiquidSyntaxError` was added to Theme Check in July 2026 [12]; on an older Shopify CLI the check does not exist, and the gate prints `true` whatever the files contain, so update the CLI first, then test the gate once on an unpublished copy with a deliberate Liquid syntax error and confirm that it fails. And Theme Check's parser is not the one Shopify runs on its servers (the messages differ), so treat a pass as a strong sign, not a guarantee, and still compare the live file after the sync.

![What the branch showed, and what the live theme had, for one snippet, from the platform commit to the fix; the live file was checked once, not watched. Two lanes, GitHub branch, headed by the GitHub mark, and live theme. First, Shopify's bot rewrites a snippet and adds a comment block; on the live theme, a later live pull matches this version. A gate before the merge: fail on LiquidSyntaxError and the broken file never reaches the branch. Then the merge keeps {% endcomment %} and drops {% comment %}; on the live theme, Shopify reports Unknown tag 'endcomment' and keeps an older version. Admin changes keep producing commits on the branch; on the live theme, a snapshot: a pull days later matches the pre-merge file. Last, the fix: valid Liquid, with both performance changes kept; on the live theme, next: pull the published theme's file and compare. A band at the foot says a live copy is evidence, not a fix: repair the branch file, then compare the published copy.](https://ilogr.com/wp-content/uploads/2026/10/shopify-github-branch-versus-live-theme.webp)

*What the connected branch showed against what one pull from the live theme returned. The live file was checked once, so compare the published copy after each sync.*

## Why is copying the live file back the wrong fix?

When a branch file breaks, the quickest way to clear the error is to replace it with the copy from the live theme. Here, that copy was the pre-merge version. A quick fix on a side branch did exactly that: the Liquid error went away, and both performance changes went with it, the very work that had failed to deploy. It stayed on that branch, because the connected branch got its own fix that kept the changes, and later merges kept that version.

A cleared error is also what you see when a file has lost the change, so treat the live copy as evidence, not a fix. Compare it with the branch copy, list the differences and repair the branch file so it keeps the new work. Then run the gate above before you call it done, and compare the published file again after the next sync.

## Should you deploy through the GitHub integration or Shopify CLI?

Both routes are Shopify's own and free, and the choice decides where a gate like this can sit. The GitHub integration keeps the theme and the branch in step both ways, because edits made in the admin come back as commits [1], which suits a team where others also work in the theme editor. Its weak point is the one in this article: a file Shopify will not apply. Pushing from a CI job with `shopify theme push` puts your own checks in front of every upload, and its `--strict` option requires Theme Check to pass without errors first [13]; on a theme that already has hundreds of errors, use a narrower gate like the one above instead.

**Next step:** Open View logs on your connected theme’s card, then pull one recently merged file from the published theme into an empty folder and compare it with the branch.

## References

1. [Shopify.dev, "Shopify GitHub integration for themes"](https://shopify.dev/docs/storefronts/themes/tools/github). Used for: View logs, two-way sync and bot commits from admin edits.
2. [Shopify.dev, Shopify CLI "theme pull"](https://shopify.dev/docs/api/shopify-cli/theme/theme-pull). Used for: The only, live and theme options for pulling one published file.
3. [Shopify Developer Community, "Stricter Liquid parsing for themes and theme app extensions" (Shopify staff reply, 16 January 2026)](https://community.shopify.dev/t/stricter-liquid-parsing-for-themes-and-theme-app-extensions/28294). Used for: Shopify staff saying syntax errors block pushes and saves.
4. [Shopify.dev, Liquid tag "comment"](https://shopify.dev/docs/api/liquid/tags/comment). Used for: How Liquid comment blocks open, close and treat their content.
5. [Shopify/liquid on GitHub, `lib/liquid/document.rb` and `lib/liquid/locales/en.yml`](https://github.com/Shopify/liquid/blob/4e39ae4cc3da73921923c0669e0fc84a66b2f696/lib/liquid/document.rb). Used for: The Unknown tag error raised for an unmatched end tag.
6. [Shopify.dev changelog, "Stricter Liquid parsing for themes and theme app extensions" (13 January 2026)](https://shopify.dev/changelog/liquid-is-getting-faster-and-ready-to-evolve). Used for: Automatic rewrites with an explanatory comment under stricter parsing.
7. [Git documentation, "git-show"](https://git-scm.com/docs/git-show). Used for: The remerge-diff option and what the combined merge view leaves out.
8. [Shopify.dev, "Theme Check configuration"](https://shopify.dev/docs/storefronts/themes/tools/theme-check/configuration). Used for: Theme Check failing with exit code 1 on any error by default.
9. [Shopify.dev, Theme Check "Checks reference"](https://shopify.dev/docs/storefronts/themes/tools/theme-check/checks). Used for: What LiquidSyntaxError and LiquidHTMLSyntaxError each cover.
10. [Shopify.dev, "LiquidSyntaxError"](https://shopify.dev/docs/storefronts/themes/tools/theme-check/checks/liquid-syntax-error). Used for: Fixing syntax errors so Theme Check and Shopify parse files alike.
11. [Shopify.dev, Shopify CLI "theme check"](https://shopify.dev/docs/api/shopify-cli/theme/theme-check). Used for: The config option overriding a theme's own Theme Check settings.
12. [Shopify/theme-tools on GitHub, `theme-check-common` changelog (version 3.28.0, released 17 July 2026)](https://github.com/Shopify/theme-tools/blob/main/packages/theme-check-common/CHANGELOG.md). Used for: When LiquidSyntaxError was added to Theme Check.
13. [Shopify.dev, Shopify CLI "theme push"](https://shopify.dev/docs/api/shopify-cli/theme/theme-push). Used for: The strict option requiring Theme Check to pass before a push.