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?
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.
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).
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.
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.
...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...
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!
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...
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.
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 :)
