Tips for local WordPress development with Varying Vagrant Vagrants (VVV)

vvv-tipsI’ve used local development environments for as long as I can remember.  They’ve always been a fluid part of being a developer.  The biggest pain point was keeping everything upgraded at all times and switching from one stack to another.

In case you didn’t notice, I said ”was”.  This is because in the Spring of 2013 I found Varying Vagrant Vagrants, or VVV.  With VVV you can have your local WordPress development environment virtually silo’d in it’s own container.

There are many tutorials out there explaining the what and why you should use a virtualized development environment, how to setup Vagrant, and how to setup VVV so I won’t dive deep there.

My take away is just that I want to be able to have an environment that’s flexible, quick, and not so dependent upon the hardware and software installed on my computer.

With that, here are my most used tips for everyday usage of VVV.  I do mention some of the initial pain points I had with VVV, but with some digging around I found solutions that I would like to share with you.

1. Creating a new site

TL;DR vvv new mysite.dev -v 3.9.1

I’m not a systems engineer by any means.  I know enough to be helpful, but not enough to build a full stack.  So when I jumped into VVV for the first time, I had an issue with trying to get my existing sites into the /www root directory.

The way I work is that I have a /Sites directory, then under that is each website that I am working on.  When I installed VVV for the first time, I installed it in that /Sites folder only to realize that I probably should’ve installed it outside of that.

But that was an easy fix.  vagrant destroy and start again where I wanted.

Once I created a site or two I realized that I wanted to automate this process a bit more than the Auto site Setup that VVV has built in.  After a quick search I found VVV Site Wizard.

This great script allowed me to create a new site with any version of WP I wanted simply by typing vvv new mysite.dev -v 3.9.1 where the -v grabs the version of WordPress I want and installs it.  If left off, then it’ll grab the latest.

I didn’t have to mess with database or nginx files, or provision scripts either.  After typing in that simple command, I had a brand new site installed and ready to go in seconds.

2. Connecting to MySQL

At first glance, I was unsure on using MySQL as I had in the past since I didn’t like using phpMyAdmin for database work.  I like to use Sequel Pro (on OS X) to run queries and look at the data.

I wasn’t sure how I was going to connect to MySQL since normally I would just put in my connection string with the host information and it would connect.  With VVV I wouldn’t be able to put in localhost and the user credentials and have it connect, since technically my sites were no longer on my localhost.

The way to do it is via SSH Tunnel.  In layman’s terms, that’s just relaying the information via SSH.

So whether you are using Sequel Pro or some other MySQL application, look for SSH Tunnel when setting up your connection.

Here’s what mine looks like:

sequel-pro-vvv

Yes I know it’s bad practice to have root user, but if you have my laptop, then it doesn’t matter what the password is.

3. Restarting Services

This isn’t something that I do all that often, but there are times that I will need to do this often enough that I wanted to share it.

Sometimes when I run vagrant up MySQL doesn’t start and I’ll get the WordPress “Error Establishing a Database Connection”.

With two commands, this is easily fixed.  First type vagrant ssh and then type sudo service mysql start.  After a few seconds, you should be good to go.

One of the great features of VVV is that unless you destroy your setup, any changes you make within the instance will persist.  So there are times when I have to setup custom nginx directives and restart the service.

sudo service nginx restart does the trick.

Clean slate

After a long day of WordPress development, it’s great to just type vagrant halt, watch my resources come back available, and know that my laptop is free of any development environment burden.

Since 2013 when I really went neck deep into virtualizing my development environment, I can’t tell you how awesome it is to see the WordPress community embracing this as well.  This only serves us as developers more ability to push forward with the latest and greatest plugins, themes, and core as the architectures we work on mature.