Can you say which plugin version runs on your site and who uploaded it?

On Bedrock plugins are not installed in the admin, they are declared in the dependency file together with a version. Thanks to the WPackagist registry that covers ordinary plugins from the official directory, and paid licences are added through a private repository. The lock file then states exactly what runs in production, so an update is a change in the repository rather than a click that leaves no trace. If a new version breaks something, rolling back is one command and one deploy, not a hunt for the backup from the right night.

• Plugin and core versions recorded in the repository
• The official plugin directory through WPackagist
• Licensed premium plugins from a private repository
• An update is a reviewable change, not an invisible click
• Rolling back is a single deploy

Part of a site's functionality has no business being toggleable in the admin. Registering custom post types, an integration with an invoicing system, security restrictions or a mail gateway connection are part of the project, not optional add-ons. I write those as mu-plugins, which always load and cannot be deactivated with one click in the plugin list. It also separates client-specific code from the theme, so the theme can be replaced later without half the site's logic disappearing with it.

• Critical functionality cannot be deactivated by accident
• Custom post types and integrations live outside the theme
• The theme can be replaced without losing logic
• A clear boundary between appearance and function
• Fewer third-party plugins in the project

Bedrock splits configuration into a shared part and a per-environment part, with credentials read from environment variables kept outside the repository. Development can have debugging on and indexing off while production does the opposite, and nobody has to flip switches by hand before a deploy. Only the webroot directory is publicly reachable, while dependencies and configuration sit above it and cannot be fetched through a browser. That layout alone removes a whole class of common vulnerabilities that exist purely because something is sitting in the web root that should not be.

• Separate config for local, staging and production
• Credentials in environment variables, not in the repository
• Only the webroot is public, everything else is out of reach
• Debugging and indexing are not toggled manually
• Less surface for the usual vulnerabilities

Once the project is a repository, deployment stops being a ritual. A change is built, the whole prepared state is uploaded and then switched to, so the live site never sits in a half-uploaded directory. The same procedure runs for staging and production, which removes the it-works-on-my-machine surprises. Database and uploaded files are backed up outside the repository, because content does not belong in code. The result is a site where you can say exactly what was deployed, when, and what that change contained.

• A deploy is one step, not an hour in an FTP client
• The site never runs in a half-uploaded state
• The same procedure for staging and production
• A change history you can roll back through
• Content and uploads kept separate from code

Moving to Bedrock is not a rewrite. I keep the existing theme and content, convert plugins into versioned dependencies, move custom tweaks into mu-plugins and set the environments up so staging can be cloned from production at any time. The work happens on a copy and production is switched over only once the new version has been verified. I work at 40 EUR per hour including VAT. Moving a typical business site onto Bedrock is usually 8 to 20 hours, and a new project built on Bedrock from the start costs no more than a classic install.

• Content and theme stay, the arrangement changes
• Custom tweaks move into mu-plugins
• The switch happens only after verification on a copy
• Migrating a site roughly 8 to 20 hours
• 40 EUR per hour including VAT, no premium on new projects