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.