Update 10/20/2013: This was a great intro post to using Vagrant for WordPress development. If you’d like more, see my talk from WordCamp Vancouver, also titled “Hi WordPress, Meet Vagrant“, as well as the accompanying slides and context. Also, I called out WordPress.com at the end of this post with the hopes that a Vagrant environment could be built for that environment as well. Automattic came through with the VIP Quickstart repository, which is coming closer and closer to the WordPress.com environment every day.
Over the last few months I’ve been planting seeds with every WordPress developer I run into with the hope of convincing them to use Vagrant to manage their development environment. The basic pitch has evolved with time and now that I’ve had the chance to fine tune it for 10up’s recent developer summit, I’m going to lay it out here as well.
LAMP via MAMP / XAMPP / WAMP
It helps to start with what we’ve been working with so far. The first step to developing for WordPress is to make sure your environment meets the minimum requirements. As of today, these are PHP 5.2.4 and MySQL version 5.0 or greater.
The beginning of WordPress development was often like the wild west. Cowboys abound, PHP files were edited in some form of a text editor and uploaded directly to the server for testing. White screens were a good indicator when things went wrong.
As familiarity with WordPress, PHP and MySQL progressed, local LAMP environments arrived. Apache, PHP and MySQL all had binaries that could be installed in Windows or Mac and a basic development environment could be setup with relative ease. White screens now happened locally first and more rarely in production.
MAMP, XAMPP and WAMP came along and provided a few click method of creating a stable LAMP sandbox for us to play in. With the minimum requirements for WordPress development met, things got stable and stale.
Meeting Environment Requirements
Rather than meeting minimum requirements, Vagrant provides a flexible way for a developer to meet environment requirements.
How about a server running Ubuntu 12.0.4, nginx, PHP-FPM, MySQL, memcached and the PECL memcache extension? Vagrant does that.
And CentOS 6.4 with nginx, PHP-FPM, MySQL, memcached and the PECL memcached extension? This too.
Or Debian 6 with page caching provided by Varnish or Redis… Can also do.
But wait.. still working with that project hosted on Apache, MySQL and PHP?
Vagrant does that.
This Matters?
This matters. The closer you can be to your production environment during development, the more confident you can be that the code you are pushing has been tested properly.
When that tricky cache expiration issue appears, the tools will be immediately available to confirm and troubleshoot it. When somebody on your team needs to jump in to help on a project, only a couple commands stand between them and a full matching system.
And at the end of the day, when you are done with development, one command powers off this amazing virtual environment and leaves you with a personal computer.
Go Try It and Chime In
10up has a pretty decent setup going over at Varying Vagrant Vagrants. A walkthrough from a few weeks ago is up at Evolving WordPress Development With Vagrant. We’re continuing to cruise ahead with a common nginx, MySQL, PHP-FPM and memcached setup, but we’ll be branching off to our other environments shortly as well. If you have an environment you’d like to see matched, fork the repository and give it a go.
And If Your Name Is Mo Or Barry…
Hi!
What we have in our default provisioning so far is pretty close to a basic version of the WordPress.com server environment. We would love to help create a Vagrant setup that matches production as closely as possible and can be used by anybody developing a project with that in mind. Ping me when you’re game. 🙂
Cache issues be gone!
Responses and reactions
Replies
So you have VVV up and running on your local machine and you want to replicate that setup (i.e. software (Ubuntu, nginx, PHP...) and its settings) on VPS (or any production setup).
How?
That's going to be a bit tough with VVV. Theoretically, the provisioning script included could be run on a fresh Ubuntu 12.10 box and the proper software would be setup. You would likely need to do some additional work with config files.
If you're looking to do exact mirrors of production and development, it may be worth looking into other provisioners such as Salt, Puppet, or Chef. These do a more comprehensive job of maintaining the state of a machine through provisioning rather than the basic checks we do in VVV.
Fantastic work here, guys. I've been using a hacky shell script + virtualbox for a while and have been wanting to switch over to vagrant, but never managed to find the time to get it working. Plus the rest of the dev team here at PMC has been wanting something exactly like this for quite a while, but what we have has worked "good enough" so we never managed to find the time.
This makes is *so easy* to put together a standardized development environment without shuttling 1gb VM images back and forth, and *so easy* to get up and running with a new VM environment with all the tools we need.
So, thanks for doing the hard part!
Absolutely! Glad to hear VVV is serving its purpose well. Thanks for your contribution too!
[…] HI WORDPRESS, MEET VAGRANT http://jeremyfelt.com/code/2013/04/08/hi-wordpress-meet-vagrant/ […]
Thanks for this! I wanted to build something like this on my own. Luckily I found your post before! ;-)
[...] Hi WordPress Meet Vagrant [...]
[...] 29. WordPress, Meet Vagrant [...]
[...] Pingback: Hi WordPress, Meet Vagrant | Jeremy Felt [...]
Thanks for all of your work on this. I have been using this for a couple of sites and it has worked pretty well. One question I have is what is the default login info for the Wordpress environment? I was able to login in a previous version, but I don't remember how I did the initial set-up for a new site I am working on.
It's pretty amazing that I've forgotten to document that anywhere. :)
Default user/pass combo for both installations is admin/password.
Will add better docs on that to the next version. Thanks!
You know, I bet you did document that somewhere at some point. Because I have been using this—and have logged in—after following your docs.
Thanks for the awesomeness.
I have yet to see where the added overhead of Vagrant would be worth it for me for most of the sites I work on.
I do however see it's value in it in some cases. For example I would really love to have a true perfect local representation of WP Engine's server config. I love WPE, but FML I've bad more problems with server config there then anywhere else, except maybe Page.ly and their damned symlinks... come to think of it they all have their nuanced issues, but still vagrant configs maintained by the majors hosts (WP managed and otherwise) would be pretty cool.
+1 to John's comment. I'd love to see this. A vagrant file with WPE specs would be awesome! I'm sure $x developer on $y hosting platform would love to see this.
Hi Jeremy, thanks for doing this, it's been on our plate to do this for a while, and we have various versions of it up on Github. Someone from our team will be reaching out to help shortly, expect issues/pull requests etc soon :).
This is fantastic! I'm going to have to go GitHub spelunking. :)
We're very much willing to chat. IMO, the best solution would be for a maintained ZippyKid Vagrant repository on GitHub that you can point developers to that are working in the ZippyKid environment. Having this in a library of available Vagrant setups for WordPress would be amazing.
The only requirement for your mention to be recognized is a link to this post in your post's content. You can update or delete your post and then re-submit the URL in the form to update or remove your response from this page.
Learn more about Webmentions.