Bedrock

You recognize a Bedrock site by its tree: composer.json at the root, config/application.php plus config/environments/*.php, a .env file, and web/ holding index.php, wp-config.php, wp/ for core, and app/ in place of wp-content. Plugins come from wpackagist.org or private repos and land in web/app/plugins.

Versions are fixed in composer.lock. To audit a site, run composer show --direct and compare it with what wp plugin list reports on the server; any difference is a manual change.

An agency runs 18 client sites on Bedrock, each deployed with composer install --no-dev from CI. A client editor uploads a plugin zip through wp-admin on the staging site. The next deploy wipes it, since web/app/plugins is rebuilt from composer.lock.

The fix is a line in composer.json requiring wpackagist-plugin/redirection at 5.4.2. The agency now sees every plugin version in a pull request instead of discovering them over SSH.

Bedrock is a project structure and Composer is the tool that does the installing. You can use Composer on any PHP project without Bedrock's folder layout, and you can copy Bedrock's layout without ever running an update. Bedrock also disables the plugin and theme file editor and installation in wp-admin by default, which plain Composer does not.

Editing files in web/wp/ and losing the changes at the next install. Committing .env with live database credentials. Expecting web/app/uploads to be in git, when it should be on shared storage or object storage. Forgetting that the document root must point at web/, not the repository root. Installing a paid plugin with no Composer repository and having no way to deploy it.

Before moving a client to Bedrock, list which plugins lack a Composer source. Test the document root and an uploads path on staging first. Keep a separate .env.example in the repo so a new developer knows which keys the site needs.