Roots Sage: The Modern WordPress Starter Theme (Blade, Vite, Tailwind)

If you are starting a custom WordPress theme in 2026 and do not want an aging PHP-template spaghetti pile, roots/sage is still the professional default. It sits around ~13k GitHub stars, ships Laravel Blade components and templates, a Vite + Tailwind pipeline, and first-class block editor support. Sage is not a theme you install and tweak colors on — it is a starter you fork, rename, and own for the life of the project.

What problem Sage solves

Classic starter themes give you header.php, footer.php, and a loop — then leave build tooling as homework. Teams end up with Gulp configs from 2016, jQuery bundles nobody understands, and PHP templates where HTML and logic are inseparable. Sage assumes you want:

• A maintained front-end toolchain (Vite) instead of an ad-hoc Gulp setup
• Tailwind for utility-first styling with a design system mindset
• Blade templates so markup stays readable and components are reusable
• A structure that scales past a two-page brochure site
• Block editor compatibility without abandoning custom PHP views

That is why agencies and serious freelancers fork Sage instead of Underscores when the project expects a year of iteration — not a weekend child theme. Sage trades "zero dependencies" for "sane defaults you would have added anyway."

Who Sage is for

• Developers comfortable with Composer, npm, and Git-based deploys
• Teams building bespoke marketing sites, product landers, or content-heavy properties
• Projects where Tailwind utility classes beat maintaining a giant SCSS architecture
• Agencies that want every new client theme to start from the same proven scaffold

When NOT to use Sage

• Tiny brochure sites on Elementor/Divi — the toolchain overhead is not worth it
• Client teams that only know Site Editor — a block theme may be easier to hand off
• Hosts that forbid Composer or Node on deploy — Sage expects a build step
• Plugins-only customization — if the "theme" is twenty lines in a child of Twenty Twenty-Four, skip Sage

Quick start (fork and build)

# From a Bedrock or classic wp-content/themes directory
composer create-project roots/sage your-theme-name
cd your-theme-name
npm install
npm run build
npm run dev

Activate the theme in WordPress, point your local HTTPS site at it, and start editing Blade views under the theme's resources/views directory. Exact paths follow the Sage version you installed — always check the repo README for the current major version layout.

Core concepts: Blade, Vite, and Tailwind

Blade brings Laravel's templating syntax to WordPress. Partials become @include directives; layouts wrap pages with @extends; components encapsulate cards, heroes, and navigation. The PHP in your theme focuses on data (view composers, app/View/Composers), while markup lives in .blade.php files that designers can read without tracing <?php ?> blocks.

Vite handles hot module replacement in development and optimized bundles in production. Run npm run dev while building templates; commit built assets or run npm run build in CI before deploy depending on your pipeline.

Tailwind ships as the default styling approach. Customize tailwind.config.js with brand colors, fonts, and spacing tokens. Sage's integration means you rarely fight WordPress enqueue order — assets wire through the theme's modern entry points.

Typical project workflow

1. Scaffold with composer create-project roots/sage inside Bedrock or classic wp-content/themes.
2. Rename theme slug, text domain, and namespace per Sage docs.
3. Define Tailwind tokens matching the design system.
4. Build Blade components for header, footer, cards, and ACF-driven sections.
5. Register ACF field groups (JSON sync recommended) for page modules.
6. Use Query Monitor during development to catch slow queries from custom loops.
7. Hand off content editing — if ACF fields are page-heavy, add Quickfields Bulk Editor for ACF for spreadsheet bulk edits.

Sage vs Underscores vs block themes

Gotchas

• Major version jumps — Sage 9 → 10 → 11 changed structure significantly; read upgrade guides before bumping.
• Build on deploy — forgetting npm run build ships unstyled pages.
• ACF + Blade — pass field data through view composers; avoid calling get_field() deep inside nested partials without a plan.
• Plugin CSS conflicts — some plugins enqueue global styles; use Tailwind's layer strategy and scoped wrappers.

Pair Sage with Bedrock and real content tools

Sage is the theme layer. For a Composer-managed WordPress install, use Roots Bedrock. For scripted deploys and search-replace, use WP-CLI. For debugging during theme work, install Query Monitor.

After the theme ships, content editors still drown in per-page ACF edits. For bulk text and textarea updates across pages, use our open-source Quickfields Bulk Editor for ACF — spreadsheet UI with autosave. Walkthrough: Quickfields blog post. Product page: Quickfields Pro when you need CSV and image workflows.

FAQ

Is Sage a parent theme? No — you fork it and the fork becomes your project theme.

Does Sage work with page builders? Technically yes, but mixing Blade-first development with Elementor rarely ends well. Pick a architecture.

Can I use SCSS instead of Tailwind? Sage's defaults center on Tailwind; diverging is possible but you maintain more yourself.

Repo

github.com/roots/sage