My Blog

Shopify Theme or App Conflict? A Safe Diagnosis Sequence

A product option stops responding after a theme change, or an app feature appears on one page but not another. The cause might be a template setting, an…

Blue storefront illustrations compare a protected original with a draft, where a magnifying glass highlights an isolated app tile and a two-way arrow marks its return path.

A product option stops responding after a theme change, or an app feature appears on one page but not another. The cause might be a template setting, an app block, an embed or code added to the theme. Disabling several apps at once may hide the symptom without identifying the cause. Record what fails, reproduce it in an unpublished theme, and change one thing at a time.

Record a repeatable symptom

Start with the exact storefront URL and the action a visitor takes. Write down the expected and observed results separately: “Selecting the second product option leaves the displayed selection unchanged” is more useful than “product page broken”. Note the published theme name and version, device, browser and approximate time. Capture a screenshot or short sequence that shows the failure.

Compare another page using the same template with one using a different template. If only one product fails, record its assigned template and any relevant differences in options or content. If all product pages fail but collection pages work, that boundary is useful too. Check at mobile and desktop widths when the feature is intended to appear at both. Mark each result as reproduced, unaffected or not tested; an untested page is not evidence that the feature works there.

If browser developer tools show an error, copy its text and note the action that produced it. The error is a lead, not proof that the app named nearby caused the failure. Record recent theme edits, app setting changes and theme updates in the same way: possible explanations to test rather than a verdict. Keep the observations in order, including checks that worked, so another person can repeat the sequence without guessing which page or setting you used.

Reproduce the failure in an unpublished theme

Duplicate the published theme and label the copy clearly as a diagnosis draft. Shopify recommends a duplicate before customising a theme so that you can return to the original. Its theme duplication instructions explain the process. Confirm that the original is still published, then open the affected URL in the draft preview.

Repeat the recorded action before editing anything. Check the same product or page, assigned template and relevant settings. If the symptom does not occur in the draft, stop the isolation test: a change that appears to “fix” a problem the draft never had tells you little about the published theme. Record the difference and look for conditions the preview does not reproduce.

When the failure began around an update, identify the version of each theme being compared. Shopify allows an updated theme to be reviewed among draft themes without changing the published one. It warns that some apps might not be compatible with a new theme; editor customisations and theme code changes may also carry over differently. Review Shopify’s theme update guidance before treating a difference between versions as an app fault.

Find the integration path

Inspect the affected template in the draft theme editor beside an unaffected template. Look for the feature in sections and app blocks. Is its block present, enabled and in the expected position? Shopify says app blocks can be placed within sections or as sections in a template, but some are limited to particular page types and some theme sections do not support them. A missing block can therefore be a placement or compatibility issue. Shopify’s guide to extending themes with apps explains these integration paths.

Check app embeds separately. An embed may display an overlay or add code without a visible widget. Record whether the relevant embed is active in the draft and whether its settings differ from the published theme. Do not use the absence of a visible element as evidence that an embed is inactive. Compare the same route and action after each controlled change.

Some apps add custom code directly to theme files. If the feature follows that path, ask someone familiar with the theme to compare the relevant files with a known working copy. Record the file, the change and its apparent purpose. Do not remove an unfamiliar snippet simply because it mentions the app: other pages may use it, and surrounding theme code may be involved. Keep this review tied to the failing action rather than auditing every installed app.

Test one reversible change

Before changing the draft, write down the current setting, the single change proposed, the route and action to retest, and how to restore the original state. Capture a settings screenshot if the control has several options. For an app block, remove or reposition that block in the draft. For an embed, toggle only that embed. For custom code, preserve the original file and let a qualified person isolate a specific understood edit. Shopify advises making a theme copy before editing code and explains the limits of file history. Its code editing guidance explains those limits.

Retest the exact action on the affected route. Then check a comparison route where the feature should still work. If the symptom disappears, restore the integration and see whether the symptom returns. A repeatable change in behaviour supports a connection between the integration and the failure; it does not prove that the app itself is defective. The template, settings, theme code or another script could be part of that connection.

If nothing changes, restore the draft before testing the next candidate and record the negative result. Do not combine several toggles into one experiment: you would lose the ability to tell which mattered. Note whether a test removed the whole feature or merely changed the faulty behaviour; those outcomes support different conclusions. If the draft cannot reproduce the failure, or the only remaining test would interrupt an essential live feature, stop experimenting and prepare a support case from the evidence you have.

Give support a focused case

Send the theme or app developer the affected URL, theme name and version, device and browser, exact steps, expected and observed results, and an unaffected comparison route. Include the draft tests, screenshots and relevant error text, with the action that produced each. Identify whether the suspected path is an app block, app embed or direct code change. Ask a question that can be answered: does this block support the page type and section, should this embed be active in the theme, or what is the supported way to remove a particular code change?

Do not uninstall an app as a quick isolation test. Shopify warns that uninstalling can leave theme code behind and affect store features or workflows; it directs merchants to review any additional removal steps. Shopify’s uninstall guidance sets out these considerations. An uninstall also changes more than the single theme setting you are trying to test.

Keep a compact diagnosis record

  • Failure: exact URL, template, device, browser, action, expected result and observed result.
  • Comparison: one affected and one unaffected route, with untested checks marked clearly.
  • Integration: the relevant block, embed or code change, its location and current state.
  • Draft test: one change, both route results and the step used to restore the draft.
  • Support question: the specific compatibility or removal question and who can answer it.

Finish the record with the narrowest conclusion the tests support: which symptom you reproduced, where it occurs and which draft change affected it. If results are mixed, state that plainly. Test any proposed fix against the same steps before considering a change to the published theme.