WordCamp Chicago 2013

Download Slides: WordCamp Chicago 2013 – “Hi WordPress, Meet Vagrant”

Talk Goals

I want each one of you to leave this talk amped up to use Vagrant for WordPress development.

I know this sounds crazy because I haven’t even told you what Vagrant is all about yet, but I’m really not going to be satisfied until the WordPress community starts to forget what the acronym LAMP even stood for in the first place. As we’re going through this together, I encourage you to imagine ways that Vagrant can fit into your development work flow, how it may have helped you solve problems faster in the past, and how it’s going to make you solve problems faster in the future.

This Post Goals

In the past I’ve used the follow up post with slides to provide a large amount of context for those who came through a bit later. That ends up being a massive dump of information, so I’m going to use this post to highlight a few of the key concepts that I’m hoping everybody took away from the talk. As time progresses, there will be several places on my site to point you to for information on using Vagrant with WordPress.

Vagrant & Magic

“any sufficiently advanced technology is indistinguishable from magic.” – Arthur C. Clark

When I sat down and used Vagrant for the first time, it was magic. I had no idea what was going on, but it was going on and I liked it. And it makes sense that it seem like magic at first because really cool things happened without much effort.

“Witchcraft to the ignorant, …. Simple science to the learned” – Leigh Brackett

Over the last 7 months I’ve gotten deeper and deeper into what Vagrant is and what it means for development and I can now appreciate it as a piece of advanced technology with many possibilities for expansion and use rather than the magic it started as.

This is what we’re going to cover. The transition from magic to approachable advanced technology. I’ll walk through and explain why and how you should start using Vagrant to manage your development environment when creating plugins and themes for WordPress. Together we’ll demystify things a bit so that you’ll immediately want to uninstall XAMPP or MAMP and Vagrant becomes something you’re excited to start using.

30,000 Feet

Your computer is a beautiful lawn. It starts off well manicured, with nicely defined paths around kept gardens that have some wrought iron fencing around them, helping to keep things clean. There may even be a couple police officers hanging out to make sure that nothing bad is going on.

A server is a large, beautiful beach connected to the ocean. So many possibilities for digging holes and building sand castles and creating complex moats for waves to come through to visualize how well your sand castle was constructed.

XAMPP/MAMP is a small sandbox in your yard. You have an old tire, maybe a pail. Some shovels and a few rocks that you can play with. You can test out some structures in the sand if you’d like in preparation for the big beach day. If you get real fancy, you might even drag over a hose to spray down the sand castle just to see what happens.

Installing server software directly on your computer is like having a load of sand delivered to your house and dumped on your front lawn. You can probably do a bunch with it, lay out as if it was a beach and build a sand castle or two, but that well manicured look you started with will go away and over time it’s going to become harder and harder to keep track of where all that sand went.

Are you ready for what Vagrant is?

Vagrant is an extreme sandbox. You can do whatever the heck you want with a beach worth of sand, moving it around and building and getting in trouble. If you flip a front loader or a bulldozer goes crazy and starts running things over, no big deal. Hit the reset button and you get to start over.

And when you’re done for the day, only one command stands between you and the personal computer that remains a beautiful garden.

Ground Level

Now that we have a picture of what we’re shooting for, let’s back up again and start over on the ground.

Where did the WordPress community come from?

A World of LAMP

For quite a while in the WordPress community, LAMP was the answer. Many people still consider it to be a perfectly fine answer. All you needed was some sort of LAM stack – Linux, Apache, MySQL – with a PHP, Perl, or Python tossed on. Big applications and web sites could be developed this way.

What was great about the LAMP stack is that it became pretty reproducible on our local machines. We saw this earlier with our hand raising exercise. Almost every WordPress developer has probably used some form of XAMPP, MAMP, or WAMP to manage their local environment. This focused sandbox environment goes a long way when building basic WordPress themes or plugins for customers.

That said.

Over time, as a community, we get better at this stuff.

That’s our goal. We don’t strive to do the same, we strive to do better. This is how technology works, and this is what’s required of us to use that technology in better ways.

Breaking Up With MAMP


I got a couple replies to this tweet, one of them asking if I had looked into using Vagrant. I had seen Vagrant mentioned a few months earlier but hadn’t taken the time to grasp what was going on and had kind of dismissed it as something that would be nice to learn, but that wasn’t for me. This time, faced with installing Nginx locally and destroying my beautiful garden, I decided to give it a another chance.

Life changed.

“There’s life before Vagrant, and life after Vagrant. The former ain’t pretty.” – @danielbachhuber

What is Vagrant?

Vagrant is open source software for “creating and configuring lightweight, reproducible, and portable development environments.”

These lightweight, reproducible development environments exist on your computer through Virtualization.

Virtualization is “the facility that allows multiple operating systems to simultaneously share x86 processor resources in a safe and efficient manner.”

Virtualbox is software that provides virtualization and is “installed on an existing host operating system as an application; this host application allows additional guest operating systems, each known as a Guest OS, to be loaded and run, each with its own virtual environment.”

A great part about both Virtualbox and Vagrant is that installers for each are available for Mac, Windows, and Linux. This means that rather than juggling various MAMP/WAMP/XAMPP/LAMP acronyms, we can all be on the same base platform.

What does this combination let us do?

Allows a guest machine to boot as a sandboxed environment inside a host machine using a combination of a base box and some sort of provisioning.

Getting Started

Let’s walk through the step by step of getting a base.

  1. (Install Virtualbox) Download and install Virtualbox
  2. (Install Vagrant) Download and install Vagrant
  3. (vagrant init) Create and then navigate to an empty directory on your computer via the command line and type `vagrant init`
    • This creates a `Vagrantfile` file in this empty directory that describes the virtual machine you are looking to start.
  4. (edit Vagrantfile)
    • In this file we tell the machine what base it should load, what network information it should use, and then how it should be provisioned. For the first go, we’ll leave just a box specified.
  5. (vagrant up) Type `vagrant up`.

This is the magic part. At this point, through no additional interaction, an empty Ubuntu box is available for my use on my computer. All I need to do is go to a command prompt, type `vagrant ssh` and I’m in. From there I can do anything that I would normally do with a fresh server instance.

As I’m biased to the stuff we do at 10up, I’m going to use an example of shell provisioning taken from our open sourced Varying Vagrant Vagrants.

This Vagrant configuration is an opinionated attempt to mimic a fairly common server configuration used for performant WordPress projects. We’ve put quite a bit of work into this and have had a great number of contributions from the community already, so I really would recommend grabbing this and using it to get your feet wet if not to use as your daily development environment for WordPress projects.

I uninstalled MAMP shortly after creating this and haven’t looked back.

And now, only a couple minutes stand between my beautiful lawn and having an extreme sandbox up and running. In fact, if I power off the virtual machine without destroying it completely, we’re looking at an extremely short start up time whenever I want to dive in.


Why should you develop in an environment that matches production?

Over time, as a community, we get better at this stuff.

To make and then meet expectations. There are a variety of issues that can arise between various PHP versions and large differences between how various object caching methods store and expire data. In fact, with a basic LAMP stack using MAMP or XAMPP it may not be entirely obvious how to begin troubleshooting any type of caching issue with WordPress and while APC and Memcached often act the same, it is nice to know that when an issue arises somewhere in your code that you don’t have to question the development environment being used.

During the town hall yesterday, Matt told all of us that he learned to code because of WordPress. I’d venture to guess that quite a few of us also learned to code because of this.

And look at where the community has come since then. We’ve gotten better at UI and UX over the last few years. Accessibility and language translations are both major focuses that have excellent contributors. We have talented business people driving the use of WordPress throughout all types of industries.

Not only does Vagrant help us become better developers by encouraging carelessness and a willingness to experiment with our development environments.

Vagrant allows us to start enlisting devops people into the community. So many problems have been solved in technology by devops already. Think of the server problems that Twitter had when they were growing to scale. Devops solved that. Google and Facebook have both scaled to billions of page views. Devops solved that. An amazing team at Automattic is working constantly to increase the abilities and the stability of the WordPress.com environment. Devops solved that.

Devops can also help to continue WordPress’s growth as a CMS and an application platform. And Vagrant provides a vessel for this to happen.

Imagine working for a customer that is going to host their site on WPEngine and knowing with absolute confidence that the theme you created locally will work without issue.

Or knowing that customers using default WordPress installations on Dreamhost or Bluehost will have not troubles using the plugin that your about to publish to the repo.

And I should stress that while Vagrant is very much going to replace MAMP for you, it is not a MAMP replacement.

Because that’s not what you should want. Instead of one environment restricted to technology that the community covered years ago, you should want a flexible environment that can adapt seamlessly to the technologies that the community must work with today.


Check out the open source Vagrant project at github.com/mitchellh/vagrant.

Check out a provisioned Vagrant setup at github.com/10up/varying-vagrant-vagrants/

Read through the material I’ve posted on Vagrant over the last several months on jeremyfelt.com

And ask questions. Drop an issue on the VVV repo, or send me an email or a tweet @jeremyfelt.

My First WordCamp Talk

On Saturday I had the great pleasure of speaking at WordCamp Vancouver. It was my first time speaking at a WordCamp, and my first time ever really speaking about anything at length. I really, really didn’t want to bomb this, because the idea of talking WordPress and geek in general with a bunch of likeminded folks is awesome and I wanted to kind of mitigate the possibility of a discouraging first experience.

So I picked the brain of friend, coworker and amazing speaker, Zack Tollman, and got a few tips.

The biggest takeaways were preparedness and practice.

  • Really researching and knowing the material rather than winging it.
  • Actually going through your talk a few times so that you know where your problem areas are before you get to them.

He also recommended Confessions of a Public Speaker [Scott Burkun], which turned out to be a fantastic read. Because of Zack’s advice and the added info from Scott, I actually ended up doing a bunch of mental preparation about the approach I wanted to take before I finally dove in on the presentation itself.

When I did dive into the presentation, I decided to try and get as many of my thoughts down and organized before worrying about a slide. For this I used an outlining tool, WorkFlowy, and ended up creating the entire talk this way. It did become difficult to transfer this data in the way I wanted for my article and slides after the talk, but other than that it was perfect. I may explore different outline options directly in WordPress for the next one.

After completing a decent draft of the talk, I then gave it a few practice runs to make sure things were feeling right. At this point I was able to remove material that didn’t flow and sharpen a few points that were getting lost. Once I started to feel satisfied that the stuff was working, I dove into Keynote land to create the slides.

Keynote ended up working out so much more awesome than I thought it would. I think next time I’ll leave myself with a lot more time to create the slides as I think I could have been more efficient and creative at the same time. Being able to use my iPhone as a Keynote remote was an added benefit, though the presenter notes ended up being a bit of a crutch.

I went through the full presentation a couple more times after the slides were created. This enabled me to figure out where I needed notes and to take out some stuff that was still feeling forced. I ended up not doing a full run through in the morning before my talk in favor of an extra hour of sleep, but I think that was one of those good decisions.

At first I wasn’t sure about being first on the schedule, but I think that played to my benefit. I was able to sneak into the room alone, walk around and kind of get a feel for how people saw the front and how it felt to say a few words. The tech setup was great, so I really didn’t have much to worry about.

The talk itself went well. I was less nervous than expected, though any time I lost track of my thoughts and tried to cheat with the presenter notes I felt it. The reaction from everybody throughout the talk was wonderful and I was surprised many times at how well less obvious humor got across. Everything went super fast and I was on the last set of slides before I knew it. I only forgot a few things, but nothing that hurt any of the points I was making. And the Q&A session went perfect. We had some really good questions and I find a lot of comfort in that back and forth discussion.

My overall thought on the next talk is to move prep time back by at least a week. I’d love to be in a place where the last week is less about slide prep or content creation and more about practicing the talk itself. I think I’ll try to find an alternative to the presenter notes in Keynote Remote. The iPhone was a perfect slide switcher, but the small screen is too distracting when you want to take a quick look. Depending on the room, a piece of paper with a few notes would have probably turned out better.

And that’s it. Eating my own dog food and documenting myself.

Anybody that was there – thanks a ton for sharing that experience with me and for the positive reaction throughout. I had a blast.

And now, a bunch of tweets from awesome people! Thanks, #wcyvr!

Continue reading “My First WordCamp Talk”

Calm and Simple Code With Purpose WordCamp Vancouver 2012

Calm and Simple Code With Purpose – WordCamp Vancouver 2012

The slides for my talk at WordCamp Vancouver are available in PDF via the link above. I’ve put my notes together in a decent enough form below to help provide context for each of the slides as they’re pretty content light. Enjoy!

Continue reading “Calm and Simple Code With Purpose WordCamp Vancouver 2012”