Spots

Taking Over a Shopify Store: What Our First Audit Looks For

Shopify's own help centre says it plainly: "Some apps add code to your online store theme that isn't automatically removed when you uninstall the app." On a store that has been through two agencies and a dozen app trials, that one sentence explains a good part of what an audit turns up.

So when a merchant asks us to take

So when a merchant asks us to take on a store someone else built, we do not start with the feature list. We start with an audit of what the storefront is actually running and where each piece came from. It is useful even if the merchant decides not to work with us afterwards, and it usually changes what the first piece of paid work should be. Three kinds of code, and why the split matters Everything a Shopify storefront loads comes from one of three places, and each one gets removed differently.

Theme code. Liquid, JavaScript and CSS in the

Theme code. Liquid, JavaScript and CSS in the theme files: layouts, sections, snippets, assets. It belongs to whoever edits the theme, and it stays until someone deletes it.

App-injected code. Modern apps ship as theme app

App-injected code. Modern apps ship as theme app extensions: app blocks and app embeds whose assets live on Shopify's side, not in your theme files. Shopify's documentation is explicit that "when merchants uninstall apps, blocks associated with the apps are automatically and entirely removed from online store themes." Older apps did it differently. Some registered a script tag through the Admin API, which Shopify injects into every storefront page without touching the theme. Others, or their install guides, pasted snippets straight into theme.liquid.

Orphaned leftovers. This is what the help centre

Orphaned leftovers. This is what the help centre sentence is about. When an app is uninstalled it loses access to the store at once, so it cannot clean up after itself. A snippet it pasted into the theme keeps rendering, and if it still calls the app's servers, it keeps making requests that nobody is reading the responses to.

The split matters because the fix is different

The split matters because the fix is different for each. Theme code gets reviewed. An app embed gets switched off in the theme editor. A leftover gets deleted, but only once you have proved it is a leftover. Step one: compare what the theme references with what the page loads

The first pass is two lists and a

The first pass is two lists and a diff. The first list is what the theme files ask for: pull the live theme with Shopify CLI, commit it untouched, and collect every external script it references.

The second list is what a real page

The second list is what a real page load actually fetches. On the live storefront, with the cookie banner accepted the way a customer would, the browser's Resource Timing API gives it to you in a few lines:

Run it on the home page, a collection

Run it on the home page, a collection, a product and the cart, because apps scope themselves differently. Every host in the second list but not the first came from outside the theme files: an app embed or a script tag. Every host in the first list with no installed app behind it is a candidate leftover. Theme Check (shopify theme check) is worth running on the same pull for a quick read on the Liquid quality you are inheriting. Step two: tie every script to an app, a person or nobody

Now the lists get owners. For each host

Now the lists get owners. For each host we want one of three answers: an installed app that uses it, a person on the merchant's team who asked for it (an analytics tag, a chat widget), or nobody.

News

Taking Over a Shopify Store: What Our First Audit Looks For

Shopify's own help centre says it plainly: "Some apps add code to your online store theme that isn't automatically removed when you uninstall the app." On a store that has been through two agencies…

@spots #dev
Source: Dev.to
See more like this