Using Vagrant for WordPress

In the beginning, we had M/W/X/AMP(/P/S)

One common way to spin up a server for local WordPress development involves using an Acronym Soup server locally, AMPPS, MAMP, Bitnami MAMP Stack, WAMP, XAMPP, or a built-in development server (like the Apache that ships on Mac OS).

The upside to this is that you can quickly spin up a local server and start banging out some code for your project.

The downside to this is that your local development environment may not match your staging and/or production environment(s). You may have to maintain multiple versions of tools locally on your desktop or laptop that are unwieldy or cumbersome from one project to the next. You may need to share a configuration with your team mates that can’t be replicated without giving them a list of tools they need to install and the instructions to do so. You may be using Apache locally, and have Nginx on production. You may be using PHP 5.4 locally, and have PHP 5.3 on production. PHP libraries may be missing from your local dev server, or vice versa. Your installed version control system may have a different binary version locally than it does on production.

Then we had the VM

This is where a virtual machine (VM) can be very useful.

Traditionally, spinning up a VM involved downloading pre-configured boxes for Virtualbox or VMWare that were sort of like the target production environment. They might be overloaded with lots of preconfigured software that may not be necessary, or have a complete GUI attached to them, making the VM large and unwieldy. They might be missing some packages that you need that are specific to your production environment. Depending on how the box was created, you may end up with bloated boxes that are a pain to manage, and sharing the 10 GB VM amongst a team that includes remote workers may be unfeasible. Do you check the VM into version control for the project? How large do you want your version control repository to be on initial checkout for that newb on the project?

Then came Vagrant

This is where Vagrant comes in.

From Vagrant’s About page :

Vagrant is a tool for building complete development environments. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time, increases development/production parity, and makes the “works on my machine” excuse a relic of the past.

Using Vagrant, you can define and spin up a headless server environment that can be used for local development. Some cloud providers, such as Amazon Web Service and Rackspace, even support Vagrant boxes as production servers.

You could start with a base box definition that closely resembles your destination production environment by finding one at the Hashicorp Vagrant community box repository, or from the repository.

Technically you could configure a Vagrant box, spin it up, and begin installing all the necessary packages for your server at the command line with apt-get, yum, or whatever package manager the OS of the Vagrant box provides.

Managing installed packages

Fortunately, there are tools to automate and assist with package management as well.


Puppet is a tool designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively. You can use Puppet to manage packages for you.

You can use Puppet to install Apache, or Nginx, MySQL, PHP and other packages that your Vagrant box needs to match production. With Puppet and Vagrant together, you can create virtual machines that reliably match your production environment to a tee.


PuPHPet is and online “wizard” that allows you to create a Puppet and Vagrant configuration without a deep knowledge of either tool’s specific configuration formats and directives. You could go to the PuPHPet website, spec out the OS, hostname, memory allocation, installed packages, etc., and download a zip archive that contains the configurations. Unzip the archive on your local machine, cd into it, run vagrant up, and your server is ready, without learning all the details of configuring Vagrant or Puppet directly.

Using a tool like PuPHPet, it is a breeze to define the Vagrant box, the OS and installed packages, the whole nine yards, and check the entire configuration into version control. While still being lightweight, your team can check out the configuration, run vagrant up, and start developing in a production environment quickly.

WordPress Vagrants

There are a number of WordPress specific Vagrant Projects that you could use to jumpstart your WordPress development, depending on your needs.

WordPress specific Vagrant boxes aren’t typically aimed at helping you match a specific server environment. They are usually intended to quickly spin up a type of WordPress project setup, i.e. for WP Core contributions, WP Theme Reviews, WP theme development, WP plugin development, or even client site development. They often come pre-loaded and configured with WordPress development tools, and some of them follow best practices for large scale WordPress production environments. They can be quite useful, for example, if you need to share a server configuration amongst a team, or if you need to do VIP development.

VIP Quickstart

VIP Quickstart is a local development environment created by Automattic for VIP developers. The goal is to provide developers with an environment that closely mirrors along with all the tools they recommend developers use.

Varying Vagrant Vagrants

The “big guy” in WP specific Vagrant boxes, this is the one you will hear of most often when researching Vagrant with WP.
Although it started as a 10up project, it has transitioned to a community project.


Chassis is a virtual server for your WordPress site, built using Vagrant.
From the project README: You can imagine it as MAMP/WAMP on steroids.

Primary Vagrant

Developed as a VVV alternative that uses Apache instead of Nginx.

Useful WordPress Vagrant Tools

VVV Site Wizard

An Alison Barrett project (Nerdery Alum, former Automattician, current 10up).
A Bash script to automate setting up new WordPress sites with Varying Vagrant Vagrants.

Variable VVV

A fork of VVV Site Wizard that adds a number of useful features, including deployment options.
Although I have not had a chance to test it, it looks like a very interesting project tool worth exploring.

WordPress Theme Review VVV

A VVV setup script intended as a WPTRT theme review environment.

Vagrant Manager

A handy tool (available for OS X and Windows) to manage your Vagrant boxes right from the desktop.
See which Vagrants are running or halted, and issue commands to them from an easy to use menu.

Hey, where’s the tutorial, code, or in-depth walk-through?

This post isn’t a tutorial. This post is a brief intro to what Vagrant is, and why you should consider using it for WordPress development.

I hope to inspire WordPress developers who may have “heard” of Vagrant, but aren’t sure how it can be useful for them, or don’t know where to start, to dig in a little deeper. Look into some of the GitHub repos I’ve linked to, and see if one of them might work for your next project. Try using PuPHPet to build your own ideal Vagrant setup for your next WordPress project.

My advice, if you haven’t used Vagrant before, and you just want to get started with using Vagrant, clone Alison Barrett’s VVV Site Wizard and follow the directions. You’ll have a WP specific Vagrant box up and running in no time.

If you want a little more fine grain control over your Vagrant box setup, go to the PuPHPet website and spec out your ideal box. Then the rest… setting up a DB, installing WP, etc., is in your complete control.

Hey, what about Chef / Berkshelf, or Ansible, or SaltStack, or (insert yet another tool name here)?

Yup. Those are other tools that you can use, rather than Puppet. I’ve heard great things about them, however, I have not had the time to dig into all of them myself.

If you have the time to research them, and you find a compelling reason to use one over another, by all means, use it, write about it, then share your discoveries and experiences. The single greatest thing about the WordPress community, I have found through the years, is all the knowledge that the community shares.

24 Hours of Madness (for a good cause) – The 2014 Overnight Website Challenge

Adam Richards and myself pressing all the words.
Adam Richards and myself pressing all the words.

24 hours of no sleep.

Well, it’s actually more like 30 hours or so.

No sleep.
Coding through the night.
In a mad dash to help a non-profit in need.

For the second year in a row, I participated in the Overnight Website Challenge in Minneapolis.

Last year’s Overnight Website Challenge was a disappointment for me. My 2013 team put all of our best effort and our hearts into it, but we ran into insurmountable problems that prevented us from completing the challenge in the 24 hour allotment. The few of us who had a passion to complete the project, did so months later, after a lot of additional work. I told myself “I’m not doing the OWC again,” I didn’t want to feel that disappointment all over again, and lose precious sleep to boot. But, some of my teammates from 2013 wanted to participate again, and I felt the need to support them, and do a good deed for a non-profit.

I had a damn fine team this year. Adam Richards , Brant Day, Bree Compton, Chris Bennett, Corey Stern, Jon Winton, Scott Garrison, Shane Smith, Sherman Bausch, and myself, flying under the banner of Team Raxacoricofallapatorius. We had UX, QA, front end, Javascript, and WordPress back end devs represented on the team. A well rounded, complimentary skill set, and we all worked well together. Tensions and frustration were minimal, technical glitches were few, everyone knew their role and played their part.

We gave our all for 24 hours straight. Coding through the night, until eyes were sore, blurry, bloodshot, filled with tears, with eyelids so heavy it hurt. Committing code up until the last minute, barely able to form complete sentences for git commit messages, but we carried on, doing whatever was needed. We created a fine product for a fine non-profit, and the product was “launchable” at the end of the challenge.

When the challenge was complete, I made the trek home, fell into the most comfy bed I have ever slept in, and slept for 12 hours straight. My family came home. I awoke long enough to hug each of the children, tell my wife I love her, and I fell asleep again, for another 6 hours or so.

Monday was a blur, much like the weekend, and all I could think of is more sleep.


And Batman.


Why Most Stories About WordPress Security Are Wrong

This article originally appeared on the blog on September 11, 2013 under the title “Why Most Stories About WordPress Security Are Wrong.”

I have often heard the remark “WordPress is insecure!” My response is “Where did you hear that?” and “When did you hear that?”

WordPress Is the Most Popular Content Management System on the Planet.

My first question, “WHERE did you hear that?” is a very important question. As of this writing, “WordPress powers roughly 18% of the top 10 million websites on the planet, making it the most widely used CMS in the world. The next largest CMS is Joomla, with 3% of the top 10 million sites, and followed by Drupal at 2%.” [1] [2] [3] That’s a lot of websites running WordPress! This popularity and widespread usage means that WordPress has a much higher profile than other Content Management Systems (CMS). [4] [5]  A larger install base means a larger target for attackers looking for low-hanging fruit. The popularity of WordPress brings with it inaccurate or ill-informed attention from journalists and bloggers. Many of those who report on technology matters are not security experts, and often they lack a thorough understanding of the issue. A reporter saying “(WordPress is) pretty easy to hack” in reference to a scripted brute force attack against weak passwords, does not make it so.   The high profile nature of WordPress solicits the attention of security firms who may have an interest in attracting new customers to a product they offer. By issuing vague security white papers directly to the media, these firms might demonstrate that they are more interested in public relations and “free ink” than actually benefitting the WordPress community.   And just like the “Mac versus PC” debates, and the “Ford versus Chevy” debates, there is often a personal preference involved. A developer may prefer Drupal or SharePoint over WordPress, they may honestly believe that their preferred CMS has a better security model. But without being able to cite specifics, they may rely on the rallying cry “WordPress is insecure!” Just as a Macintosh enthusiast may (incorrectly) say “Windows gets viruses and Macs don’t.”

WordPress Is Secure, You Are Not.

WordPress core is, in fact, very secure, just as secure as any other Content Management System, just as secure as any other software suite or Operating System. Security issues most often arise from administrators and users. In other words, you are the weakest link. A weak password and/or a password used across multiple services, in conjunction with an easily guessable username, is typically the vector of attack against any website. A weak password means a brute force attack script can hammer away on your website until it hits just the right combination to get in, open a back door, add your site to a botnet, lock you out of your site, and potentially infect the computers of your site visitors. This is not a WordPress specific security issue, this is a user issue. If you administer a website, you are an IT professional, own a computer, or have used a computer in the last 20 years, then you should already be aware of the risks of weak passwords. The strategy for preventing exploitation of this attack vector is simple, do not use weak passwords, do not reuse passwords, and do not use easily guessable usernames (like “admin”). The next likely attack vector is an attack at the file system level of a shared web hosting server. A shared host could be running hundreds of websites on one server. An exploit might not come from an attack directly against your website, but your site can be incidentally compromised if an attack was successful against another site on the same server. The simple solution to this is to use a dedicated or virtual server, avoid shared hosting. For script kiddies, crackers, and botnet operators, the ever-growing pool of WordPress installs means that there are more sites to check for “low hanging fruit” vulnerabilities. Old versions of software can be compromised because of known vulnerabilities and exploits. The “bad guys” run automated scripts that check what version of a CMS you have, and if they find a version with a known vulnerability, they deploy an exploit and compromise your site. This is not a WordPress specific security issue, this happens with all major software. The solution is to keep your software and all associated add-ons up to date. With WordPress, all it takes is a simple click to keep your installation upgraded. While it is true that WordPress core is quite stable and secure, security issues can be introduced by third-party software. For instance, a few years ago, there was a widespread attack against websites that implemented the TimThumb image processing script. [6] Though the TimThumb script is not part of WordPress core, some third-party themes and plugins were using it as an image processor. As a result, an incredible number of websites (estimated in the millions) were compromised, which included non-WordPress sites that had TimThumb installed. [7] Again, this is not an issue with WordPress core security. This is an issue with third-party software, plugins and themes. The solution to avoid this attack vector is to use themes and plugins listed on Do not use themes and plugins from untrusted sources.

Historical Legacy and the Current State of WordPress Core Security.

My next question, “WHEN did you hear that?” is an equally important question in response to worry over . Around 2007–2008, WordPress garnered some unwanted (though admittedly deserved) attention as a number of security issues (in particular SQL injection and code execution vulnerabilities) in WordPress core were exposed. [8] Of course, these security holes were patched by WordPress developers upon discovery. Those vulnerabilities apply to legacy branches of WordPress and are not present in the most recent WordPress release, 3.6. However, the buzz surrounding those vulnerabilities gave some the feeling that WordPress core was, is, and will forever be insecure. That is an inaccurate and invalid assessment when it comes to security. Based on the same criteria, I would argue that your preferred Operating System, software suite, and CMS, was, is, and will forever be insecure. Security breaches and vulnerabilities have been discovered, exploited, and patched in all software. All software is terribly complex, be it an OS, a CMS, or your favorite Word Processor. Due to that complexity, all software suffers from some vulnerabilities (known and unknown) of some kind. All responsible software vendors and developers actively investigate and address vulnerabilities as part of their release cycle. WordPress, Joomla, Drupal, SharePoint, or any other major CMS is no different.

The Real Indication of How Secure a CMS Is, Is Determined by the Vendor’s and Developers’ Response to Security Issues.

For WordPress, the response was to implement an easy “click to update” functionality in WordPress’s Admin Dashboard, a regular release cycle to continually patch and improve core, and a full-time security team to continuously address security issues. Upgrading WordPress core is easy, it is so “WordPress.” When an administrator with proper privileges accesses the WordPress Dashboard, and an update to WordPress core is available, a simple “WordPress x.x is available! Please update now.” banner displays at the top of the screen. “Update now” is a link to initiate the upgrade process. Additionally, an “Update to x.x” button displays in the “Right Now” metabox. Clicking the “Update” button also initiates the upgrade process. The upgrade process itself consists of clicking a button, waiting a couple of minutes, and you’re done. This makes it easy for a site administrator to keep their installation patched for the latest security fixes. This simplicity is akin to the simplified update systems that the major OS vendors have implemented. Making updates simple means that users are more likely to keep their software patched. And of course keeping software secure means continuously applying security patches. A regular, ongoing release cycle addresses WordPress core security issues as they are discovered or reported. The release cycle consists of major version upgrades to add features to WordPress, and minor release versions as needed to address security vulnerabilities and critical bugs. [9] If a critical security vulnerability is identified in core, a security release that addresses the vulnerability is released as quickly as possible (usually within days, sometimes even faster). The number of critical or severe vulnerabilities discovered in WordPress core has decreased significantly since the 2007–2008 years, in part due to the regular release cycle, the simplicity of upgrading, and of course, the security team. WordPress has a dedicated security team that actively investigates and patches core to address security concerns. This team keeps abreast of all security issues, and enforces security procedures within core. The WordPress security team has a standardized process to address security reports: [10]

  1. Receive and acknowledge security report
  2. Work to confirm the report and its severity
  3. Plan and develop initial patch to address the security report
  4. All of this typically happens within 48–72 hours of receiving a security report.

“The WordPress security team is made up of 25 experts including lead developers and security researchers — about half are employees of Automattic, and a number work in the web security field. We consult with well-known and trusted security researchers and hosting companies.” — Andrew Nacin, WordPress Lead Developer, in a presentation “ & Optimizing Security for your WordPress sites,” June 2013. [11]

In conclusion, the vast majority of fear surrounding “WordPress insecurity” is unfounded, and most often is completely unrelated to WordPress core itself. WordPress is secure. What you do with it, how you deploy it, how you administer it, that’s where the real security concerns lay. Here are some helpful guidelines to keeping your WordPress website safe (for more in-depth security hardening guidelines, visit the Hardening WordPress page in the Codex)

  • Use a dedicated or virtual server, avoid shared hosting
  • Back up your site (files and database) regularly (consider a service such as VaultPress)
  • Keep your WordPress core installation up to date
  • Keep your WordPress plugins up to date
  • Keep your WordPress themes up to date
  • Uninstall (not just disable) any unused plugins or themes
  • Avoid plugins and themes from untrusted sources
  • Do not use admin (or other easily guessable usernames)
  • Use a strong password!
  • Ensure your own PC is malware free (to keep keyloggers and malware from stealing your credentials)
  • Monitor your server and user stats
  • Restrict WP-Admin to your VPN or proxy
  • Restrict WP-Admin using HTTP Basic Auth
  • Restrict WP-Admin to your IP address
  • Deny access to wp-content directories
  • Remove WordPress version from meta
  • Protect WP-Admin with authentication
  • Force SSL
  • Get a security audit
  • Report potential core vulnerabilities
  • Report potential plugin vulnerabilities

If you’re interested in notable WordPress users, there is an ever growing list of government entities, educational institutions, major brands, celebrities, and musicians that rely on WordPress as a secure Content Management System to power their websites and blogs. Visit the WordPress Showcase to see some of the big names that trust WordPress security.