Why I moved a client site onto Bedrock WordPress

Turner & Pooch is a dog grooming business, and their site is a straightforward WordPress build — but I moved it onto Bedrock rather than a standard install, and it’s worth explaining why for anyone still on vanilla WordPress deployments.

The problem with a stock WordPress folder

Wp-config values in version control, plugins committed as binary blobs, no clear separation between what’s “the site” and what’s “the environment”. It works fine right up until you need a second environment, or a second developer, or both.

What Bedrock changes

• Environment config lives in .env, not in a committed wp-config.php — so secrets stay out of git and staging/production can differ without any code changes.
• Dependencies (WordPress core included) are managed with Composer, so “what plugins are installed” is a diff in composer.lock, not a mystery.
• The web root only contains what needs to be public, which quietly closes off a whole category of “someone found the uploads folder” problems.

For a single-site client build like this, the migration itself was mechanical: pull the theme and uploads across, rebuild the plugin list through Composer, move config into .env, and repoint the database. The satisfying part is what happens afterwards — deploys become “push and pull”, not “remember which seventeen files changed”.

It’s a bit more setup up front for what’s otherwise a fairly small brochure-and-booking site, but it’s the same setup every time, which is the whole point.