9 ms·

Bedrock: a modern WordPress stack

82 points by bretthopper 13y ago

bretthopper 13y ago
I'm one of the creators of this (we're the same people behind http://roots.io http://roots.io) so I'm happy to answer any questions. We're just trying to make developing WordPress sites a little more bearable :)
- codelust 13y ago
  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.
  - bretthopper 13y ago
    The autoloader is required in wp-config to get access to Dotenv: https://github.com/roots/bedrock/blob/master/wp-config.php#L7 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.
  - squigs25 13y ago
    nice pun: "song and dance with Composer"
  - rmccue 13y ago
    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.
- Xdes 13y ago
  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?
  - bretthopper 13y ago
    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.
  - chc 13y ago
    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.
    - krapp 13y ago
      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.
      - smacktoward 13y ago
        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.
        krapp 13y ago
        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...
- MPetitt 13y ago
  Will updating Wordpress be the same as usual, or will we have to modify/get custom builds?
  - bretthopper 13y ago
    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).
    - pan69 13y ago
      "composer update" maybe? "composer install" will install from composer.lock.
    - bretthopper 13y ago
      pan69: correct. Updated my reply to fix that.
- mikegirouard 13y ago
  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?
  - bretthopper 13y ago
    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/application.php#L25-L27 https://github.com/roots/bedrock/blob/master/config/applicat...
  - pestaa 13y ago
    I believe you're missing Options +FollowSymLinks from your Apache configuration and is not a problem with WP actually.
- csomar 13y ago
  Are you hiring freelancers/contractors?
  - bretthopper 13y ago
    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-here/743 http://discourse.roots.io/t/looking-for-work-post-your-info-...
abimaelmartell 13y ago
wow, this is so nice, i don't like wordpress, but this changes everything Thanks!!
chc 13y ago
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.
- smacktoward 13y ago
  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...
- bretthopper 13y ago
  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.
  - camus2 13y ago
    > 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.
    - bretthopper 13y ago
      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.
grimgrin 13y ago
It's not a big deal, but in case you weren't aware: http://bedrocklinux.org http://bedrocklinux.org It was posted here a few months ago: https://news.ycombinator.com/item?id=6504878 https://news.ycombinator.com/item?id=6504878
- bsilvereagle 13y ago
  I thought maybe paradigm got tired of Linux and picked up Wordpress when I saw this.
dabernathy89 13y ago
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)?
- bretthopper 13y ago
  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.
Eclyps 13y ago
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. http://ripeworks.com/pomander/wordpress.html http://ripeworks.com/pomander/wordpress.html
- bretthopper 13y ago
  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.
Gipetto 13y ago
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.
- bretthopper 13y ago
  Even Mark Jaquith's (WP core team member) WP Skeleton (https://github.com/markjaquith/WordPress-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 :)
tuna 13y ago
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 :)

82 points by bretthopper 13y ago

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

codelust 13y ago
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.
- bretthopper 13y ago
  The autoloader is required in wp-config to get access to Dotenv: https://github.com/roots/bedrock/blob/master/wp-config.php#L7 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.
- squigs25 13y ago
  nice pun: "song and dance with Composer"
- rmccue 13y ago
  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.
Xdes 13y ago
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?
- bretthopper 13y ago
  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.
- chc 13y ago
  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.
  - krapp 13y ago
    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.
    - smacktoward 13y ago
      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.
      - krapp 13y ago
        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...
MPetitt 13y ago
Will updating Wordpress be the same as usual, or will we have to modify/get custom builds?
- bretthopper 13y ago
  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).
  - pan69 13y ago
    "composer update" maybe? "composer install" will install from composer.lock.
  - bretthopper 13y ago
    pan69: correct. Updated my reply to fix that.
mikegirouard 13y ago
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?
- bretthopper 13y ago
  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/application.php#L25-L27 https://github.com/roots/bedrock/blob/master/config/applicat...
- pestaa 13y ago
  I believe you're missing Options +FollowSymLinks from your Apache configuration and is not a problem with WP actually.
csomar 13y ago
Are you hiring freelancers/contractors?
- bretthopper 13y ago
  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-here/743 http://discourse.roots.io/t/looking-for-work-post-your-info-...

abimaelmartell 13y ago

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

chc 13y ago

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.

smacktoward 13y ago
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...
bretthopper 13y ago
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.
- camus2 13y ago
  > 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.
  - bretthopper 13y ago
    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.

grimgrin 13y ago

It's not a big deal, but in case you weren't aware: http://bedrocklinux.org http://bedrocklinux.org It was posted here a few months ago: https://news.ycombinator.com/item?id=6504878 https://news.ycombinator.com/item?id=6504878

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

dabernathy89 13y ago

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)?

bretthopper 13y ago
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.

Eclyps 13y ago

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. http://ripeworks.com/pomander/wordpress.html http://ripeworks.com/pomander/wordpress.html

bretthopper 13y ago
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.

Gipetto 13y ago

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.

bretthopper 13y ago
Even Mark Jaquith's (WP core team member) WP Skeleton (https://github.com/markjaquith/WordPress-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 :)

tuna 13y ago

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 :)