The short answer: extend Online Store 2.0 rather than creating an unmaintainable theme fork
Good Shopify theme customization delivers a validated business requirement without sacrificing merchant editing, performance, accessibility, or a practical upgrade path. It uses Liquid, JSON templates, sections, blocks, snippets, assets, app blocks, and settings according to their current roles. Shopify does not have the WordPress parent–child theme inheritance model, and there is no official root theme.json file that inherits another theme. Current themes use standard directories including layout, templates, sections, blocks, snippets, assets, config, and locales.
Shopify's theme architecture reference explains that a layout provides the document foundation, a template controls the page type, and sections and blocks form reusable editor-managed modules. Only layout/theme.liquid is strictly required to upload a theme. Any legacy brief that proposes parent themes, child themes, a root theme.json, or PHP template inheritance is describing a different platform and should be corrected before estimation.
| Requirement | Preferred implementation surface | Why | Avoid |
|---|---|---|---|
| Merchant-editable page composition | JSON template and sections | Merchandisers can add, order, and configure modules | One hard-coded monolithic Liquid page |
| Repeated interface detail | Snippet or reusable theme block | Clear parameters and one maintained implementation | Copies spread across several sections |
| Application feature | App block or app embed | Install, disable, and upgrade boundaries are clearer | Permanent edits injected into core theme files |
| Global visual options | Theme/section settings and CSS custom properties | Controlled configuration supports a design system | Unique hard-coded spacing and colors everywhere |
| Complex business rules | Application, Function, or backend service | A theme is not a secure transactional backend | Secrets, permissions, or inventory workflows simulated in Liquid |
1. Prove that customization is the appropriate layer
Write the requirement, user problem, and acceptance criteria before selecting a technical layer. Typography, colors, section ordering, and basic content may already be available in the editor. Reviews, subscriptions, bundles, or filtering may have a suitable app block. Add custom code only when standard capabilities cannot meet a validated need at lower risk. A design should also accommodate changing products, collections, markets, translations, and merchandising—not freeze every pixel from a static mockup.
Record the current theme name, version, source and licence, code modifications, app embeds, template assignments, performance baseline, and update history. Shopify recommends duplicating a theme before customization. A duplicate is a recoverable copy, not a child theme that inherits updates. WESWOO's Shopify delivery services and project library can help structure scope, but no example should be treated as a fixed performance or conversion promise.
2. Assign responsibilities to the current theme structure
layout/theme.liquid holds the shared document shell, head output, global section groups, and essential resource entry points. It should not accumulate every page feature. Files in templates/*.json define which sections compose a page and their settings. Shopify's JSON template documentation explains that merchants can add, remove, and reorder sections in the editor. A JSON template can render up to 25 sections, each with up to 50 blocks, so unlimited nesting is not a sound content model.
sections/*.liquid provides configurable modules with schema; blocks/*.liquid can provide reusable theme blocks; snippets/*.liquid contains smaller reusable code that is not independently managed in the editor. Assets hold styles, scripts, and static resources. Locales hold translatable interface strings. config/settings_schema.json defines theme-level settings, while config/settings_data.json stores the configured values. Product-specific structured content should generally be evaluated for metafields and metaobjects instead of being hard-coded into a template.
Section settings need clear labels, defaults, constraints, and empty-state behavior. When a merchant can select an image, text, product, collection, color, or spacing, the frontend should degrade safely if that data is absent. Repeated blocks need sensible limits and presets. Interface labels should use locale keys, while product and campaign content should remain in the correct content system so localization tools can find it.
3. Keep Liquid presentational and use JavaScript as enhancement
Liquid renders HTML from Shopify objects and theme configuration. It is suitable for products, collections, menus, metafields, and settings. Snippets should accept explicit parameters rather than relying on obscure global side effects. Limit collections before looping, and avoid repeated whole-catalogue filtering in nested loops. Use semantic HTML, purposeful links and buttons, image dimensions and responsive sources, labelled forms, understandable errors, and visible keyboard focus.
JavaScript should enhance usable HTML rather than making primary product information or navigation wait for a client application. Split scripts by section or feature, defer noncritical behavior, and do not load every carousel, popup, and tracker on every page. Shopify's theme best practices recommend modern browser capabilities and minimal JavaScript. Test with real products, applications, mobile devices, and realistic networks—not only a clean development store.
If performance is already the main concern, establish the bottleneck with a Shopify speed audit before expanding scope. Every new font, image, application, and interaction needs a performance budget from the start.
4. Use CLI, source control, and a reversible release path
Shopify CLI supports development themes, local preview, hot reload, Theme Check, push, and publish. The official theme CLI guide describes development themes as temporary hidden themes backed by store data; for a review link that must persist, push an unpublished theme. Store source in Git, associate branches with a task or release, and write commits that explain intent and impact. Treat environment configuration such as settings_data.json carefully so a code deployment does not erase a merchandiser's recent changes.
A practical workflow is to establish a known baseline, run Theme Check and formatting in a development branch, build against a development theme, push to an unpublished theme for content, translation, application, mobile, and accessibility acceptance, record the target theme and rollback copy, and publish through an authorized owner. Run a minimum buying journey immediately afterward. Avoid large untracked edits in the production theme's web code editor.
Prefer Theme App Extension app blocks and embeds when an application supports them. When disabling, uninstalling, or updating an app, check for orphaned snippets, scripts, and settings. Every third-party script should have an owner, loading scope, privacy classification, and removal plan.
5. Design for upstream updates rather than postponing them
Theme Store releases can be added as draft themes. Shopify's theme update guidance describes which editor customizations can carry over and where code changes may need attention. The more a project scatters edits through vendor core files, the more conflict and migration work it creates. Because Shopify has no child-theme inheritance, maintainability comes from source history, modular extensions, a customization register, and regression tests.
For every update, read release notes, add the update to drafts, compare templates, settings, sections, app extensions, and custom code, then test home, collection, search, variants, add to cart, cart drawer, account, language and currency, checkout handoff, and analytics. Treat an update as a controlled migration, not as replacing the production folder and hoping settings survive.
Theme customization acceptance checklist
- [ ] The requirement cannot be met more safely through the editor or a suitable app block.
- [ ] Architecture documentation does not use
theme.jsonor parent–child theme claims. - [ ] JSON templates, sections, blocks, and snippets have clear responsibilities.
- [ ] Merchant editing, empty states, translation, and accessibility pass acceptance.
- [ ] JavaScript is scoped, and mobile performance is tested with actual applications.
- [ ] Git, Theme Check, development/draft themes, and rollback are operational.
- [ ] Apps, analytics, consent, markets, and the buying journey pass regression tests.
- [ ] A named owner periodically reviews upstream theme updates.
Frequently asked questions
Does Shopify have child themes like WordPress?
No official parent–child inheritance mechanism exists. A duplicate is a backup copy, not an inheriting child. Use Git history, modular code, and a controlled update process.
Is there a root theme.json configuration file in Shopify themes?
No. Shopify themes use the documented standard directories. Configuration files live under config, while JSON page templates live under templates.
Can Liquid implement any business logic?
It should not. Liquid is a presentation template language. Secrets, privileged operations, durable workflows, and order-side logic belong in applications, Shopify Functions, or appropriate backend services.
Can a customized theme still receive vendor updates?
Often yes, but broad edits to vendor files increase merge and regression work. Evaluate the new version in a draft theme, compare in source control, and test the complete buying path.
Is customization always better than selecting another theme?
No. If the current foundation has poor accessibility, performance, or architectural fit, migrating to a better theme can cost less than permanent patching. Compare requirements, migration risk, and ongoing maintenance.