Research: Bedrock vs WP Starter (by @gmazzap)

Hey all. Has anybody here worked with Bedrock vs and can compare the two? Are there any important differences to favor one or the other for a project?

I haven’t personally used WP Starter (on a real project), but from a quick install this is what I observe:


  1. Both use Composer to install plugins/themes (and WordPress itself).
  2. Both create a separated web root.
    • Bedrock: web
    • WP Starter: public
  3. Both install WordPress in a directory called wp within the web root.
    • Bedrock: web/wp
    • WP Starter: public/wp
  4. Both create a separate content directory.
    • Bedrock: web/app
    • WP Starter: public/content
  5. Both follow PSR-2.
  6. Both support using standard plugins as must-use plugins.
    • Bedrock uses it’s own must-use plugin to do this.
    • WP Starter does this with it’s own autoloaded classes (didn’t really dig into it).
  7. Both use environment variables.
  8. Both contain defaults for different environments.

As you can see a lot of the similarities here are just semantic.


  1. Bedrock does not encourage (or support) unsupported versions of PHP, while WP Starter does.
  2. WP Starter uses the Composer post install command hook to create its project structure while Bedrock just includes it.
    • There’s really no advantage to using the post install command hook, in fact, from the outside it makes it harder to grasp as a newcomer IMO and you need to remove everything that you’ll be editing from the .gitignore (i.e. public, public/content). Other than that this has no bearing on you as a user.
  3. Bedrock works with Trellis w/o modifications, WP Starter does not.
    • This is a bit unfair to compare, however, since this is the Roots Discourse, it makes sense to note this.
  4. Bedrock separates the configs per environment (see config/environments), WP Starter uses switch statements within wp-config.
  5. Bedrock works out of the box, so far (in my experience) I’m running into issues with WP Starter (from missing config on my part?).

In Summary

There could very well be something I missed, but I hope this gives you a good comparison. It makes sense that both of these project have a lot of similarities and I’m happy to see more WordPress project boilerplates adopting Composer. There’s not a lot of (non-semantic) differences. Use whatever works for you, but I know that Roots will always be pushing the bar standards-wise, so they got my vote (I’m biased — but for good reason :wink: ).

Further reading:


Tyvm for your analysis. :vulcan_salute:

PS For I would also add “Better advanced (X)debugging” to the benefits, and this was actually my main initial driver.

Using, for example PhpStorm (as everyone should be), with a standard WP install, it probably won’t work out well to add your whole web document root to Project > Libraries. Reason: there’s a lot of meaningless cruft, that slows down IDE indexing, requires exclusion micro-management work etc.

You could add WP as a Project > Library from an outside source directory, but this, for one, will not allow debugger to match breakpoints directly to execution path. You have to resort to path mappings, and this would mean path mapping ALL your libraries. Annoying busywork.

But with WP sitting in an isolated directory, that’s also live execution path, you can succeed without any path mapping micro-management work. Now can just add WP and any plugins you want as a Project > Library, done.

Regarding WP Starter and Bedrock: the latter is more a “boilerplate” for your project, the previous is more a library that you require in your project. It is a different approach, and one is not necessarily better or worse than the other.

As a boilerplate Bedrock is more opinionated on several decisions, e.g. folder structure or some libraries to use (see the list of Bedrock “require”

Being a boilerplate, you need to clone Bedrock and edit its source if you really want to customize something (but probably you loose one of biggest pros of a boilerplate: a standardized setup).

If you use WP Starter, you require it and use its configuration if you want to change something, like folder structure, and in case you want to use Bedrock/Roots libraries… (or anything else) you just require them.

If we consider WP Starter 2, beside of this difference there was no much more to say. Maybe that WP Starter 2 has better support for dropins and that Bedrock has a better support to use regular plugin as MU plugin.

Being a boilerplate, getting started in Bedrock is easier than WP Starter 2, because in the latter you had to configure your Composer “scripts” manually, in Bedrock you get them already when you clone the project.

With WP Starter 3, which will be released in 2019, and the conversion to a Composer plugin, this latter point is not true anymore: as written in the article being a Composer plugin allows to run scripts without them being configured by end user on project composer.json.

The end goal of Bedrock is to have a standardized (and so, opinionated) way to use WP + Composer + ENV + a set of libraries.

The end goal of WP Starter is to provide tools to build a different WP + Composer + ENV setup per project, based on project needs and requirements, or why not, build a standardized boilerplate to reuse (company-wide, team-wide…), if wanted.

In theory, people at Roots could use WP Starter 3 to build Bedrock: they would require it, their additional libraries and would ship the WP Starter configuration that would setup the site (starting from folder structure) like Bedrock do it now.

Would they find any value in doing that? Well, this is not a question for me :slightly_smiling_face: I can say that if they would express the will to do so, I could offer my effort to make this as smooth as possible.

With WP Starter v3 some additional technical differences are there e.g. the usage of Symfony Dotenv component to parse .env files instead of vlucas/phpdotenv that is used in Bedrock (and was used in v2) and minimum PHP version that, as of now, is PHP 7.0 for WP Starter v3 and 5.6 for Bedrock.

Moreover, WP Starter v3 explicitly supports packages of type “WP Starter Extension”, so you can expect that in future some extensions will be created to enable more features on WP Starter, but always in a way that is end-users call to add them, if they wish. Spoiler: the first of them will handle installation of translation files for plugin and themes.