If you build WordPress sites, chances are you either know about VVV or are using it. If not, go ahead and get it set up! It is (in my opinion) the best way to handle local site development. Forget MAMP- the future is now.

Alright, enough about that. If you’re here it’s most likely because you want to share your local development environment quickly and easily. Well, you have come to the right place. I wrote another article on how to use ngrok and Vagrant together– this is the same thing.. but more updated and includes a necessary step for using it with Varying Vagrant Vagrants (VVV).

An awesome thing happened recently- Shia LaBeouf filmed a motivational speech in front of a green screen. People ran with it, and, if you go looking, you’ll likely find some pretty hilarious adaptations.

Somewhere between seeing Shia show up at someone’s door and watching him help Luke use the force, I realized that this wasn’t just some hilarious meme. Or, at the very least, it didn’t HAVE to be. Somewhere between the laughs I actually felt inspired. “Just do it.” It can’t be that simple, can it?

No matter what you are engineering, there are a number of principles that stay the same. D.R.Y (don’t repeat yourself) is one of those principles. While building out your WordPress theme, you’ll likely notice that there are a few different chunks that are the same across the site. Let’s make them D.R.Y!

Recently I needed to send emails locally. My local dev environment uses Vagrant, so I researched some options and tried installing MailCatcher. I was able to successfully install MailCatcher and run it locally, however I couldn’t access it from my host machine. If I used curl on my virtual machine I could see the HTML for MailCatcher, but trying to visit the same URL from my host machine would result in a never ending page load.

Have you ever heard the saying “code is poetry”? Probably. I think every engineer has heard that phrase before. I have known it for a long time, and I thought I knew what it meant. It wasn’t until sometime relatively recently (within the past year) that I really started to understand what it meant. Once I did, I started to see code in an entirely different light.

If you’ve worked with WooCommerce, then you know that it is PACKED with features. These are awesome! Sometimes, however, you need to get rid of some of the stuff that WooCommerce spits out by default. Luckily, we can do that relatively easily.

Recently, I had to restart my Vagrant to apply some changes. When I went to vagrant up, a scary thing happened: vagrant started to download the entire box over again. Vagrant wasn’t detecting my existing box! Not only is this inconvenient if you have specific configurations you made to your Vagrant after the initial install, but it could be detrimental if you use Vagrant to hold your database and didn’t have a backup handy. Luckily, I was able to point Vagrant back in the right direction.

This one goes out to all you web developers out there. If you are developing sites, you are probably using version control & working locally (if you’re not- you should be). Your current workflow probably looks something like: make changes locally, push them to staging evnironment, test, push to live. Thats a perfectly good workflow.. for a solo developer.