From MAMP to Vagrant

Moving from MAMP to Vagrant for WordPress

Why Vagrant?

Over the years I have been a faithful user of MAMP, WAMP, and even XXAMP. As a freelancer, I don’t have much occasion to share my development environment and most of my clients have similar environments- shared servers in the low to mid range using a LAMP stack. I almost always have a staging server that allows me to build the site before pushing it live. This allows the client to approve everything before the site is launched or before changes are deployed. I honestly haven’t had too many problems with this system. I won’t say that the occasional bug doesn’t crop up but nothing that has made it worth my while to consider fixing something that isn’t broken.

Until this: https://make.wordpress.org/themes/handbook/get-involved/become-a-reviewer/

I write themes. I use WordPress. I want to improve my coding skills. I seek to maintain a good karmic balance 🙂 Plus fixing stuff that’s not broken when you don’t have to is much more fun than fixing broken stuff when you must.

What does Vagrant do that MAMP, WAMP, or XXAMP do not?

The main selling point of Vagrant is that you can pass around a development server and even synchronise it- using Git or some other version control system. It also allows you to bundle other tools into your server environment. In the case of MAMP there always seem to be caveats when installing server side tools. I won’t tell you how many weird problems I ran into when installing WP-CLI on MAMP. A lot of these are due to path configuration differences between a more typical local server environment and one using a package. Similar problems occur when one’s version of the package becomes outdated or when encountering a bug that can be fixed by upgrading to the latest version of part of the stack. The longer one uses a package such as MAMP, WAMP or XXAMP, the more these limitations seem to become apparent.

Also MAMP doesn’t come with tools specifically for WordPress. WP-CLI (see above) has to be installed separately and versioning a whole WordPress instance would be tricky to say the least.

On one of these such occasions I decided to take the plunge and move over to Vagrant. I wasn’t wholly convinced that it was going to be of any great benefit to me but as I was working on a site using Nginx rather than Apache and having the odd annoyance with my latest version of MAMP. I decided now was the time.

In following the instructions here (https://make.wordpress.org/meta/handbook/about/get-involved/setting-up-your-machine/) I ended up with VVV (Varying Vagrant Vagrants)

Once you go through the instructions you end up with three sites all set up and ready for development. You also end up with all sorts of extra goodies that I’m not going to bother listing here but can be found on VVV’s Github Page

One thing to note is that VVV uses Nginx so if your goal is to replicate the server environment of a site running on Apache it may not be your best bet. To create a server environment that more closely mirrors a what one typically sees with MAMP, WAMP or XXAMP I would suggest Primary Vagrant as it offers a lot of the same things that come with VVV.

With either Primary Vagrant of VVV, WP-CLI is included and makes short work of setting up and configuring new sites. If you are new to WP-CLI it is worth having a look at and learning some basic commands.

Using VVV

VVV is particularly useful if you are a theme or plugin developer and I would suggest installing A WordPress Theme Reviewers VVV (to be cloned in your www folder.) This essentially Installs WordPress and imports the “Theme Unit Test Data” along with several development plugins useful for testing. It will also install any zipped files that it finds in the root.

In order to get comfortable with using Vagrant I would highly suggest moving a development site from you *AMP installation to Vagrant. This wiki article might be helpful to those using VVV. Another tool I found helpful in determining what was going on with my new setup was Simon Wheatly’s vvv-demo-1(also vvv-demo-2 and vvv-demo-3.)

Once comfortable with the basic functionality there are a several site wizards to make setting up a new site a breeze. It becomes very quick and easy to set up a site complete with plugins and themes activated and to set up a new dev environment in a matter of minutes. Most of these minutes are while running vagrant up --provision and provide an excellent excuse for a tea of coffee break 😉 Eventually you might want to use a dependancy manager like Composer (vvv-skeleton for example) and it is always a good idea to use some sort of version control. To do so you only need to create a git repository in the the folder you wish to version with git init. With a bit of additional reading and some tweaking you should then be able to version your whole WordPress installation and pass it off to other developers.

Please feel free to post any questions in the comments section and to read the additional resources below.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

Click to view allowed tags

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>