External systems
Services the storefront depends on that this repository does not configure, what each one owns, and how each one fails.
When one of these services fails, the theme cannot work around it, and no error reporting will tell you.
Active dependencies
| Service | Owns | Configured in | Fails as |
|---|---|---|---|
| Shopify | Pages, cart, checkout, customer accounts, metafields, metaobjects | Shopify admin | Nothing works |
| Sesami | Treatment availability, slot reservation | Sesami's dashboard | Booking calendar renders as empty space |
| Downpay | Deposit selling plans | The Downpay app | Deposit payment option is absent |
| Klaviyo | Email capture forms and popups | Klaviyo, with form IDs in theme settings or metafields | Popups do not appear |
| Zapier | Receives a copy of Klaviyo booking submissions | The webhook URL in theme settings | Copies stop. Forms still work |
| Google Tag Manager | Analytics | Theme settings, GTM Tracking group | Tracking gaps |
| Plug in SEO | Page titles, meta descriptions, structured data | Its own settings groups in the theme editor | SEO output reverts to defaults |
| Cloudflare Tunnel | Public URL for local development only | scripts/start-cloudflare-tunnel.mjs | Local device testing only |
| GitHub Actions | Pulls the live theme into the production branch | .github/workflows/theme-pull.yml | The git record of Shopify changes stops |
How the theme talks to each service
Sesami. The booking calendar waits for window.SesamiSDK using deferJS, which checks every 50 milliseconds and
never stops. A blocked script leaves the calendar area empty, with no visible error. A product needs the
sesami-service tag to show the calendar.
Downpay. The theme only reads Downpay data. sections/product-calendar-config.liquid looks through
product.selling_plan_groups for a group whose app_id is downpay, and outputs the first selling plan in it as JSON.
The calendar fetches that section when it needs it, with products/<handle>?sections=product-calendar-config.
Klaviyo. Klaviyo's own script adds forms to the DOM. The popup manager's sniffer watches for them and registers each one, because the theme cannot know in advance when they appear. Form IDs come from theme settings, product metafields, or collection metafields.
Zapier. CalendarRoot sends one POST request when the klaviyoForms window event reports a submission. It goes to
the URL in the Medispa Booking Form Submit URL setting, and the payload type is KlaviyoZapierPayload. Klaviyo
still receives the submission itself. Zapier gets a copy.
Secrets and credentials
One credential is connected to this repository, the Shopify CLI theme token that the GitHub Actions workflow uses. It is
stored as the SHOPIFY_CLI_THEME_TOKEN repository secret and never appears in theme files.
The storefront serves everything in src/, in section schemas and in theme settings to the shopper, and anyone can read
it. No API key, token or password belongs in any of them. The exception is a key built to be public, such as a Klaviyo
company ID.
The workflow also needs the SHOPIFY_FLAG_STORE and SHOPIFY_FLAG_LIVE repository variables. SHOPIFY_FLAG_LIVE must
be true, which makes the pull read the live theme instead of a development theme.
No error reporting
src/@types/global.ts declares window.Sentry, and @sentry/browser is a dev dependency, but nothing in the theme
initialises Sentry. Nothing collects errors.
A JavaScript error on the storefront stays invisible until someone reports it or a developer reproduces it. When you diagnose a problem, assume there is no history and start by reproducing it. See Runbooks.
Apps that still have code in the theme
Templates, snippets and metafields still reference several apps the store no longer uses. Legacy and unused code lists them. Check an app's status in Settings > Apps and sales channels before you treat its code as live.
Related
- Architecture explains how these services fit into each subsystem.
- Deploy and roll back covers the GitHub Actions workflow.