Hacker News new | past | comments | ask | show | jobs | submit login
Bedrock: a modern WordPress stack (github.com)
82 points by bretthopper on Dec 18, 2013 | hide | past | web | favorite | 42 comments

I'm one of the creators of this (we're the same people behind http://roots.io) so I'm happy to answer any questions. We're just trying to make developing WordPress sites a little more bearable :)

This looks like a much more formalized structure than what we do. Do you use it in production currently or is this a prototype?

This is my primary new WP project approach (which isn't perfect):

    mkdir Example-Project
    cd Example-Project

    # Grab the latest wordpress, www is our DocumentRoot
    curl wordpress.org/latest.tar.gz | tar -xvz --
    mv wordpress www
    cd www

    # Drop the default wp-content and symlink so we dont need to
    # keep all of wp in Git
    mv wp-content ..
    ln -s ../wp-content
    echo 'www/' >> .gitignore

    # Make the repo
    git init
    git add . && git commit -m 'First!'
The main problem I run into is with the symlink'd wp-content directory. WP seems to not interpret it well and I have to set up Alias directives in the virtualhost configuration to compensate. Are you doing anything similar with the app/ directory?

It's being used in production for roots.io right now but it's still a work in progress.

Seems like your issue has to do with your symlink setup. We don't need to do any special configuration with the web server. Here's the configuration that deals with app/: https://github.com/roots/bedrock/blob/master/config/applicat...

I believe you're missing Options +FollowSymLinks from your Apache configuration and is not a problem with WP actually.

Congrats. This looks pretty neat, especially since it uses Composer.

Does it do the whole autoloader song and dance with Composer?

Example: If I add Guzzle to Composer, can I call it from my plugin's code the way you can with other frameworks?

Only thing I would change is to swap out Capistrano with Fabric. But that's a personal choice.

The autoloader is required in wp-config to get access to Dotenv: https://github.com/roots/bedrock/blob/master/wp-config.php#L...

But in the example you gave, ideally your custom plugin is itself a Composer package which requires Guzzle in its composer.json file. Then you'd require your plugin in the project's composer.json :)

Re: Capistrano. We're really trying to encourage people to fork this and modify it to their needs. So you could easily rip Cap out and integrate Fabric in your own fork. We're just providing some sensible defaults that we're familiar with.

I know it's just an example, but: if you're doing HTTP in WordPress, please use WP HTTP rather than Guzzle. It has compatibility with many more hosts (since it uses sockets as well as cURL), plus it's already built-in.

nice pun: "song and dance with Composer"

Will updating Wordpress be the same as usual, or will we have to modify/get custom builds?

Updating WP is just a matter of bumping the version in the composer.json file and running `composer update`. We believe it's better to manually do this and be explicit about it rather than letting WP update itself. This way you can quickly just look in the composer.json to see the versions of everything being used (WP, plugins, etc).

"composer update" maybe?

"composer install" will install from composer.lock.

pan69: correct. Updated my reply to fix that.

Hi, I have not written a single of line of php. How hard would it be to get started with a Ruby/Node/.NET background?

You probably won't have too hard a time. With that background, your main challenge will be overcoming the wave of nausea that will sweep across you when you realize that WordPress is a gigantic mass of procedural code studded with inconsistently documented hooks and filters rather than something with a nice, clean, easily extensible OO architecture. But with liberal applications of patience and Pepto-Bismol, this feeling eventually passes.

I believe WordPress is moving forward. Here is just one of the many OO classes. You can also do OO in plugin development as well.


lol :)

WordPress is known for being "easy" but that depends on what you want to do with it. It's definitely easy to get a simple blog up and running since it's mostly done for you. But WP can quickly get complicated since it isn't designed well and the documentation is pretty bad surprisingly. There's a ton of resources online but the quality of it is hit and miss.

Not hard at all. PHP is incredibly easy. Wordpress is very well documented, and the enormous community support (plugins) means that you can do quite a lot without having to get your hands dirty with the code. And believe me, that's not an analogy. Wordpress is a great example of how NOT to code, regardless of the language being used.

PHP isn't the most fun language, but it's not that hard either. It's unusually quirky, but not unusable. As for WordPress, though — if you're used to a nice, sane API like you get in Rails or .NET, you're probably going to find the massive heap of cruft that we call WordPress a little bit aggravating.

Yes, it's probably worth mentioning that even people willing to deal with PHP find Wordpress code to be 'aggravating'. It is, unfortunately, not an example of PHP application design at its best...

Upshot, though, there's plenty of documentation and SO threads out there and a huge ecosystem of plugins. Most of the time you never even need to look at the actual source code.

And in the WordPress core developers' defense, it has been getting steadily better as time goes on. It's still a long way from perfect, of course, but they're working on it.

things like this need to stop though:

   <?php /* pointless comment */ ?>
   <?php echo $something; ?><div><?php if($blah){ echo stuff(); ?></div><?php } ?>...
...keeping track of that context switching in a complex theme can be maddening. Especially if it includes inline css and javascript or (heavens forfend) mixes php in with the inline css and javascript...

Unfortunately, this is precisely the only thing PHP was invented for. It is a templating engine planned to be used exactly how you quoted.

Everything else is just accidental complexity.

I know. Doesn't mean I have to like it though.

If you're interested in doing wordpress in a Rails style, you should checkout my repo wordpress-haml-sass on GitHub! Directory structure and files like Rails, compiles to a Wordpress theme. You're still writing Php but it doesn't feel like it!


Are you hiring freelancers/contractors?

Roots isn't actually a "company". Just an open source organization although we do sell a few things like screencasts.

If you're interested in work to do with WP/Roots you can check out this thread on our forum: http://discourse.roots.io/t/looking-for-work-post-your-info-...

Interesting. It looks like this completely circumvents the normal user-configurable WordPress plugins and update architecture, such that the only way to change anything is to update it in the source tree and redeploy like you would with a normal monolithic app. I feel like this might be kinda impractical for a lot of the cases where you would normally want to use WordPress, but I suppose in the right situation it would be nifty.

Correct. It's definitely targeted towards developers and WP sites that are controlled by them rather than front-end users.

It's usually not a great idea to let normal users install plugins and update WordPress. For an analogy, you definitely wouldn't have users installing Gems in a Rails app.

> It's usually not a great idea to let normal users install plugins and update WordPress. For an analogy, you definitely wouldn't have users installing Gems in a Rails app.

that's not the same thing, Installing a gem wont magically add a feature to your rails app. Non developpers cant do it either(let alone deploying any ruby app on a server).Installing Plugins on wordpress dont require any developper knowledge.

Obviously it's not the exact same, but my argument is they should be treated the same (when possible). First, a lot of WP plugins do require some dev work to integrate. Second, non-developers have no idea what a plugin might change. It could easily break your entire site.

Plugins should be installed on dev/staging and tested before just adding them in production. Plugins in WP are a double-edged sword.

That's how some of us (me, for instance) do it anyway -- it makes supporting clients a lot easier when things like new plugins get managed in version control -- so it's nice (for me, at least) to see that approach moving from an ad-hoc thing to something more formal that takes advantage of good tools...

It's not a big deal, but in case you weren't aware:


It was posted here a few months ago: https://news.ycombinator.com/item?id=6504878

I thought maybe paradigm got tired of Linux and picked up Wordpress when I saw this.

Looks nice. Special kudos for managing much of the wp-config though the built in config constants.

Only thing I don't like is the renaming of the root `wp-config` folder to `app`. I'd much rather have the app reflect the underlying wordpress conventions than to change it to look like something else. Yeah, consistency, but boo for barrier of entry or having to remember that `app` == `wp-config` when not everything we get to work on will get to use the shiny fandangled tool.

Even Mark Jaquith's (WP core team member) WP Skeleton (https://github.com/markjaquith/WordPress-Skeleton) renames it to `content`. If that's the only thing you don't like, then you can easily just fork it and rename app to wp-content and change the couple config settings :)

I've been using a similar setup with Pomander and the Pomander-Wordpress plugin. It's got a similar setup, but is 100% PHP-based, so I don't need to have ruby on all my servers. Been using it in production on about 15 servers for well over a year, and I'm pretty happy with it.


I looked at Pomander briefly before. It would be nice to use a pure PHP solution and eliminate the Ruby dependency. So I'll have to give Pomander a better look and if it works well, I have no problem replacing Capistrano with it.

Is it possible to still use the Composer-goodness of this stack with your own deployment (or something like ftploy)?

How do you guys handle database syncing / deployment / rollback (if at all)?

Of course! If you read down the README there's a section on every part about how to remove it if you don't want it. So you can either just not use Capistrano or remove the files it uses as well.

We don't do anything about DB syncing for now. That's next big thing once we get the Vagrant/server config work done. It's a popular topic but also complicated since everyone has different use cases.

Any thoughts on creating docker images as alternative to capistrano ? There's a couple of projects that can help on it (a Dockerfile could help on it) Good job :)

wow, this is so nice, i don't like wordpress, but this changes everything


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact