Why we build WordPress on Bedrock, Sage and Acorn

What stays the same

Clients sometimes worry that a “custom stack” means a custom admin. It does not. With the Roots stack, editors log into the same WordPress dashboard, write in the same editor, manage media the same way and use the same plugins for forms, SEO or WooCommerce. What changes is how the project is organized, built and deployed. We have used it on the clinic rebuild, the transmission shop redesign and the automotive lighting studio, among others.

Bedrock: WordPress as a proper project

Bedrock is a WordPress boilerplate. It changes three things that matter in practice:

• Dependencies through Composer. WordPress core, plugins and themes are listed in composer.json with versions, and the committed composer.lock pins them exactly. A new environment is one install away, and an update is a reviewed change rather than a click on the live site.
• Configuration in environment files. Database credentials, salts and environment-specific settings live in a .env file per server, not in a committed wp-config.php. Development, staging and production can differ safely.
• A cleaner folder structure. Core sits in its own directory, your code in another, and the web root exposes only what needs to be public.

The effect is that the whole site, minus content and uploads, can be versioned in Git and deployed the same way every time.

Sage: a theme that reads like an application

Sage is a starter theme. Templates are written in Blade, the templating language from Laravel, so a page is assembled from small components and layouts instead of long PHP files mixing logic and markup. Sage 11 builds assets with Vite, which gives fast development reloads and compact production builds; its Tailwind setup generates only the utility classes the templates actually use.

For a business, the benefit is indirect but real: a readable theme makes future changes easier to scope and implement. A new section on a service page means adding a component, not untangling a template.

Acorn: Laravel structure inside WordPress

Acorn brings parts of Laravel into WordPress: its service container, service providers, configuration and view composers. In a Sage theme, view composers prepare the data a template needs, so templates stay simple and the logic sits in one testable place. It also lets us use familiar Laravel packages when a project needs them, without leaving WordPress.

The trade-offs

• Hosting. The deployment needs Composer, though dependencies and assets can be built before upload. The host must meet the project’s PHP requirement and let the document root point at Bedrock’s web directory, which some basic shared hosting does not allow.
• Plugins that assume standard paths. A few plugins expect the classic folder layout. They are rare, but worth checking before a migration.
• Handover. Another developer needs to know the stack. It is widely used and documented, and we leave a README covering setup, build and deployment, but it is not the same as a theme anyone can edit in a file manager.
• Page builders. The stack works best with custom templates and the block editor. If you want a visual page builder to control every layout, a different approach may suit you better.

When we choose it, and when we do not

We choose the Roots stack for custom business websites that will grow and be maintained over years, where a clean codebase and predictable deployments pay off. For a small site that the owner wants to manage entirely alone, or one built around a page builder, a classic theme can be the more practical choice. We would rather explain that than force a stack onto a project.

More on how we approach builds is on our WordPress development page.