How to review a Shopify theme course for updates

Scope the review before you start

“Shopify course” covers wildly different material. Review one area at a time, and write down which one. A theme-architecture review covers theme structure, layouts, templates, sections and the files that make them up. It does not cover checkout, apps, admin workflows, payments or marketing features — those have their own release cadence and their own sources, and mixing them makes the review unmanageable.

Record the version you taught

Note the theme generation and approximate date the course was recorded against. A course recorded against an older theme generation is not automatically broken; it is a course about that generation. Deciding this first prevents the most expensive mistake in theme-course maintenance: rewriting an entire course because the ecosystem moved on, when a version note and three lesson edits would have served students better.

Check against official documentation, per claim

Work claim by claim, and always against Shopify’s own theme documentation rather than tutorials or forum threads. For each claim, record the page you read and the date you read it. Typical claims worth checking in a theme course:

• Where a kind of file belongs in the theme folder structure, and what the folder is called.
• Which template a given storefront page uses, and how a template connects to a layout.
• How sections are added, configured and reordered, and what a merchant can change without editing code.
• Names of settings, panels and editor areas students are told to open.
• Whether an approach you demonstrate is still the documented one, or is now discouraged.

Verify these details against current Shopify documentation as you go — this guide deliberately does not restate specific file names or folder layouts, because a guide that hardcodes them becomes the outdated thing it warns about.

Tell migration advice apart from an error

Documentation that recommends a newer approach is not the same as your lesson being wrong. Three distinct situations, three different fixes:

1. Still works, still documented — no change. Resist editing for fashion.
2. Still works, no longer recommended — keep the lesson, add a dated note explaining the current recommendation and when a student should prefer it.
3. No longer works as shown — the student gets stuck. This needs a real edit, and it goes to the top of the list.

The only reliable way to tell two from three is to follow your own steps in a development store once. A single reproduction settles arguments that changelog reading cannot.

Plan the smallest fix that unblocks students

Cheapest to most expensive, in the order worth trying:

• A dated lesson note or pinned correction.
• An updated written lesson description or resource file.
• A short re-recorded segment spliced into the existing lesson.
• A full lesson re-record.
• A new lesson, with the old one retired and cross-linked.

Most theme-course findings are solved in the first two rows. Reserve re-recording for steps that genuinely fail.

An illustrative example

This example is synthetic, not a real course review. Suppose a lesson walks a student through adding a section and, at 06:40, names an editor panel. The current documentation shows that panel under a different name in a different place, but the underlying steps are unchanged. That is category two: keep the video, add a note naming the current location, and record the decision with the documentation URL and date. Total cost: minutes, not a re-record.