roots/sage: A WordPress Starter Theme Built on Blade and Vite

What roots/sage replaces in a WordPress theme

A conventional WordPress theme mixes PHP control structures with HTML in template files, and the result tends to drift toward a handful of large files that no one wants to touch. Sage's stated goal is to bring "proper PHP templating and modern JavaScript tooling to WordPress themes", and the repository layout reflects that: an app/ directory, a resources/ directory, a public/ directory, functions.php and index.php at the root, plus theme.json for block editor settings. The README describes it as an "Advanced hybrid WordPress starter theme with Laravel Blade and Tailwind CSS".

The audience is narrow on purpose. This is for developers who are building a custom theme from scratch and want Blade's template inheritance and component syntax instead of raw PHP includes. It is not a theme you install on an existing site to restyle it. The README points readers to the installation docs rather than describing an install path inline, which is a signal about who the project expects: someone following a documented setup, not someone clicking through the WordPress theme installer.

Blade templates, Acorn, and the Vite asset pipeline

Three mechanisms carry the theme. The first is Blade, which gives you .blade.php templates with directives and layouts instead of PHP includes. The second is Acorn, linked from the README as the way Sage gains "Laravel's robust feature set" inside WordPress. The third is Vite, which the README calls the "Modern front-end development workflow" and which handles builds and CSS hot-reloading.

The package.json makes the Vite side concrete. The theme is declared as an ES module with "type": "module", and its scripts are dev, build, translate, translate:pot, translate:update, translate:compile, translate:js and translate:mo. The devDependencies list @roots/vite-plugin, @tailwindcss/vite, laravel-vite-plugin, tailwindcss and vite, with Tailwind at ^4.0.0 and Vite at ^8.0.0. There is a vite.config.js at the repository root. So the front-end is not a WordPress enqueue of a prebuilt stylesheet; it is a Vite build whose output lands in public/, and the theme entry points live in resources/.

The translation scripts are worth noting because they show the theme expects a real toolchain. translate:pot runs wp i18n make-pot with an explicit include list of theme.json, patterns, app and resources, and translate:update loops over ./resources/lang/*.po files. That means internationalization is wired to the WP-CLI i18n commands, not to a plugin.

Installing roots/sage and running the first build

The README does not inline installation steps; it links to https://roots.io/sage/docs/installation/ and says "Read the docs to get started". What the repository does tell you is the runtime requirement, which sits in package.json and is the first thing to check before anything else.

"engines": {
  "node": "^20.19.0 || >=22.12.0"
}

If your Node version falls outside that range, the build tooling is not supported. The theme also declares Composer as part of its stack through composer.json at the repository root, which is how Acorn and the PHP dependencies arrive.

Once dependencies are installed, the two commands that matter day to day are the ones defined in the scripts block.

npm run dev

This starts Vite in development mode. The README describes the workflow as offering "instant builds and CSS hot-reloading", so the expectation is that your local WordPress site points at the Vite dev server while you work.

npm run build

This produces the production assets. In a deployment pipeline this is the command that must run before the theme is served, because the built output is what the theme references.

If you need translations, the scripts chain WP-CLI commands, so WP-CLI has to be available on the machine running them.

npm run translate

That runs translate:pot and then translate:update, regenerating ./resources/lang/sage.pot and refreshing the .po files in ./resources/lang.

Where roots/sage is the wrong tool

The clearest limitation is the build step. Because assets are produced by Vite and Tailwind runs through @tailwindcss/vite, there is no committed stylesheet you can edit in place. A host or workflow that cannot run npm run build has no supported path here, and a developer who wants to tweak one rule in a live theme file will find nothing to tweak.

The second limitation is the knowledge floor. Blade, Acorn, Vite and Tailwind are four separate systems layered onto WordPress. A team that knows WordPress but not Laravel will spend its first days reading Blade directive syntax and Vite config rather than building pages. The README's own framing, "Advanced hybrid WordPress starter theme", is honest about this.

The third is the block editor. The README lists "Block editor support built-in" and the repository carries theme.json, so block editor integration exists, but it sits alongside a PHP templating system rather than replacing it. Teams that have moved fully to block themes with site editing in the admin are solving a different problem, and Sage's center of gravity is still server-rendered Blade templates.

Finally, the documentation for day-two operations is thin in the repository itself. The README does not document rollback, upgrade procedures or what happens to a customized theme when a new Sage release lands. That material, if it exists, lives in the linked docs site rather than in the repo.

How Sage differs from a conventional starter theme

The obvious comparison is a conventional WordPress starter theme such as Underscores, which ships plain PHP templates with the standard WordPress loop and no build system beyond whatever you add yourself. The difference in approach is structural rather than cosmetic. Underscores gives you WordPress's own templating conventions and leaves the tooling decision to you; Sage makes the tooling decision for you and replaces the templating conventions with Blade. If you pick Underscores you inherit WordPress idioms and can hand the theme to any WordPress developer. If you pick Sage you inherit a Laravel-flavored idiom and need someone who knows it.

A second comparison point is the block theme route. A pure block theme built around theme.json and the site editor removes PHP templates from the picture almost entirely, and editing happens in the admin. Sage also ships theme.json, so it is not hostile to blocks, but its templating story is Blade files in resources/, not block markup edited in the browser. The two approaches answer different questions: block themes optimize for editor control, Sage optimizes for developer control.

Maintenance, licensing, and what an upgrade costs

Sage is MIT licensed, which is permissive and places few obligations on how you use or redistribute it. That is a statement about the licence text, not advice about your situation; if you are redistributing a theme built on Sage, read LICENSE.md and your own legal guidance. The README also notes that Roots is an independent open source org funded by sponsorship, with Radicle purchases and GitHub sponsorships supporting the ecosystem, and that sponsors get access to a private Discord. That funding model is worth knowing because it explains the project's cadence.

On cadence: the repository is not archived, and the last push was on 2026-06-01. The releases listed are v11.1.0 on 2026-03-23, v11.2.0 on 2026-03-25 and v11.2.1 on 2026-04-26. Those dates describe what the repository shows; they are not a promise about the next release.

The upgrade cost is the part most teams underestimate. Because Sage is a starter theme rather than a parent theme, you are expected to modify it, and there is no upstream merge path documented in the README. Every release you want to absorb has to be diffed against your own changes by hand. Combined with major-version jumps in the toolchain (Tailwind 4, Vite 8 in the current package.json), a Sage upgrade is a project, not a command.

Editorial conclusion

Adopt roots/sage if your team already writes PHP in a framework style and is comfortable running Composer, npm and Vite as part of the theme build; the Blade component model and Acorn integration are the reasons to pick it over a plain starter. Do not adopt it if the site must be maintained by editors who only touch the WordPress admin, or if the host cannot run a Node build step, because the theme's assets come from Vite rather than from committed CSS files. Before committing, verify two things in your own environment: that the Node version satisfies the engines field in package.json, which requires ^20.19.0 or >=22.12.0, and that your deployment pipeline runs npm run build rather than shipping the source tree. The last push to the repository was on 2026-06-01, and the most recent tagged release listed is v11.2.1 from 2026-04-26.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. roots/sage on GitHub