Liquid themes explained: one theme, every page
Liquid themes explained: a layout, a template per content type and a template per section. Write it once and every page on the site renders from it.
Most agencies have built the same site twice. Once as a design, once as a set of pages that look like the design. Then the client adds a page, and somebody has to make sure it still looks like the design. That gap between "the design" and "the pages" is where a lot of unbilled time lives.
A theme closes it. You write how each kind of thing looks, once, and every page of that kind renders from it. Here is Liquid themes explained without the jargon: what Liquid is, how a theme is put together, and what it asks of you in return.
What Liquid is
Liquid is a templating language. Shopify created it and made it popular, which is why a lot of front-end developers have already written some without thinking of it as a language. It's deliberately small. It can output a value, loop over a list, make a decision and include another file. It cannot reach into a database, call an API or run arbitrary code.
That smallness is the point. A template says "put the title here, then each section in order", and the platform supplies the content. Two kinds of tag do nearly all the work. Double braces output a value: {{ page.title }}. Brace-percent tags control flow: {% for item in menu.items %} repeats what follows for every item, and {% if location.phone %} shows a block only when there's a number to show.
Why a template language rather than a framework build
The alternative is a front end built in a JavaScript framework, compiled into a bundle and deployed as a separate project. That's the right answer for an app, and for some sites. For most client sites it creates a second codebase to keep running, a build step between a content change and the live page, and a deployment the client can't do without you.
A template language keeps the theme as files the platform reads at render time. Nothing is compiled per page. There's no build to fail on a Friday afternoon because a dependency changed. If you need the framework route for a particular site, a generated content API is the escape hatch, but it shouldn't be the default for a brochure site with a blog.
The anatomy of a theme
A theme is a handful of kinds of file, each with one job.
The layout is the frame every page shares: the document head, the header, the footer, the navigation. It's written once and wraps everything else.
A template per content type. A blog post has a template. A location has a template. A team member has a template. Every location page on the site renders through the same location template, so twelve locations look consistent because there's only one description of what a location page looks like.
A template per section. If pages are composed from reusable sections (a hero, a gallery, a pricing table), each section has its own small template. A page is the layout, then each of its sections rendered in order.
Partials are fragments included from other templates: a card, a button, a byline. They keep the same markup from being copied into six places.
CSS and JavaScript files for the theme as a whole, and sometimes per template, so a page that needs a map script doesn't make every other page load it.
That's the whole shape. A competent front-end developer can hold it in their head after an afternoon.
Why content and design stop fighting
Because the theme describes kinds of things rather than individual pages, the two halves of the site change independently.
A content edit needs no redeploy. The client adds a location, publishes it, and it renders through the location template that already exists. Nothing about the theme changed, so nothing about the theme needs shipping.
A design change needs no content migration. Redesign the location page and every location picks up the new design at once, because none of them stored their own layout. There's no going through forty pages to apply the new style, and no page that got missed.
This is also why a theme protects a site from its editors. The client edits fields, not markup, so there's nothing in their editor that can move a column. We make the longer case in why we don't have a drag-and-drop editor.
How the workflow runs in Contentive
Contentive renders every new site through a Liquid theme. The theme lives as files in your own git repository, and the contentive command-line tool moves them. contentive theme dev renders the site on your machine against the workspace's live content, drafts included, with hot reload, through the same renderer production uses, so what you see locally is what ships. contentive theme check validates the theme before it goes anywhere. contentive theme push sends it to staging and only staging. Going live is a separate promote step, which a person takes deliberately.
The Studio shows which theme version is on staging and on production, when it was deployed and any rendering problems, and can deploy a starter theme to a workspace that has none. If you've worked with Craft's Twig templates the shape will feel familiar; we compare the two directly in Contentive vs Craft CMS.
What it costs
Someone has to write templates. A theme is code. It's small, readable code, but there's no version of this where a non-developer produces a bespoke theme by dragging things. If your team has no front-end developer, that's a real gap.
There's no visual theme editor in the Studio, on purpose. Theme authoring happens in your editor, in your repository, with your version control, which is where developers already work. The Studio is for content. Agencies used to tweaking a theme in a browser window will miss that, at least at first.
The structure has to exist first. A template per content type means the content types have to be decided. That's good discipline, but it means design can't run far ahead of the model. If the separation itself is new to you, what is a headless CMS covers why content and presentation are kept apart in the first place.
Where the payoff shows up
The first theme is the slowest. The layout, the partials, the card markup and the section templates are all being written for the first time.
The second is faster, and by the tenth you're not writing themes from scratch at all. A hero section template, a team-member card, an opening-hours partial: they move from project to project with a restyle. Your tenth theme starts from your ninth. That reuse, more than any single feature, is what makes a template language worth the effort for an agency.