Posted on

VVV For WordPress Development

Now that 4.3 has been released I am taking a few days to reconfigure my production environment for WordPress plugin development. After a number of issues running the self-contained GUI development environment that included WordPress core, full plugin development, and all of my supporting infrastructure including phpStorm, SmartGit, and a series of Grunt scripts in an all-in-one Vagrant-based Virtualbox, I decided to try something new. Losing 20 minutes every few days because the self-contained GUI in Virtualbox could not sync between guest and host was too much. Something in the Virtualbox or CentOS 7 upgrades over the past year broke something fundamental in GUI I/O and I’ve been unable to track it down. Time for a change.

My change? Learning Varying Vagrant Vagrants. For those that are not familiar with VVV for WordPress development you may want to check it out here:

What is VVV?

VVV is a virtual development environment for WordPress.    It spins up a headless (no GUI interface) Virtualbox that contains three separate versions of WordPress (stable, dev, and trunk) as well as a myriad of tools like phpMyAdmin.   All of the settings are in place to allow your local system, my OS/X desktop for my setup, to interact with the local WordPress install from your preferred web browser.

The upside is there is a lot of community support , articles, and various tools-and-trick available to you for doing almost anything you want.    A lot of the “cool dev tricks” I never had fully working, like interactive XDebug support in phpStorm, are readily available.     It is also super-easy to switch between WordPress releases which is cool if you are sending core patches or need to test on the upcoming major release.

The downside is that you need to setup all of your development tools locally on your desktop.   Guess what happens if your computer dies?   Yup, another few hours of setting it up again.   With my prior custom self-contained virtual environment I only need to save my Virtualbox, usually by creating a Vagrant image, any time I made notable changes to my tool kit; by doing so I could restore it easily to ANY desktop ANYWHERE in the world and have EXACTLY the same environment in no more time than it takes to spin up a VVV based box.

In short, VVV is a virtual machine store on your local desktop with several WordPress installs ready-and-waiting behind your browser screen.

My Startup Tricks

I develop a number of WordPress plugins, so having full development tools and my source code are key to productivity.  Here are some things I needed to tweak on the default VVV setup to get going.

Linking Plugin Source

I am primarily developing plugins and I want them on all of the WordPress installs provided by VVV.  I can “take over” a VVV server-based directory with a local directory my mapping the local directory to the destination with a Vagrant Customfile.    Go to the base location where you placed your VVV install, you will know you are in the right place as it has the Vagrantfile for the VVV box, and create a new file named “Customfile”.

Here is my mapping entries to take over the plugin directory on all 3 WordPress installs that come with VVV:

config.vm.synced_folder "/Users/lancecleveland/Store Locator Plus/plugin_code", "/srv/www/wordpress-default/wp-content/plugins", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]

config.vm.synced_folder "/Users/lancecleveland/Store Locator Plus/plugin_code", "/srv/www/wordpress-develop/wp-content/plugins", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]

config.vm.synced_folder "/Users/lancecleveland/Store Locator Plus/plugin_code", "/srv/www/wordpress-trunk/wp-content/plugins", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]

Configuring XDebug

phpStorm comes with an XDebug listener.  This allows you to set breaks in your PHP code files, inspect variables in real-time, and do a lot of other things that are much more efficient than var_dump or print_r or die littered throughout the code.     The are a number of articles and videos on using XDebug with phpStorm.  Check it out, it is a great debugging tool.   For now, how to enable it with VVV:

Turning on XDebug is easy with VVV.

Go to the VVV install directory.

Enter Vagrant via SSH: vagrant ssh

Turn on Xdebug from the SSH command line on the virtual machine: xdebug_on

That’s it, I can now use my  local phpStorm tool to debug my VVV files.

Here is THE XDebug + VVV + phpStorm video to watch to do this.

Useful Meta

With VVV installed these URLs should work in your browser.

Users and passwords:

  • For the WP installs:  wp / wp
  • For WP Admin Users: admin / password
  • MySQL Root: root / root
    • Default DB Name: wordpress_default
    • Trunk DB Name: wordpress_trunk
    • Develop DB Name: wordpress_develop


  • Local directories (relative to Vagrant install): ./www
  • Server-Side directories: /srv/www
Posted on

Getting Started With SLPDev Cent 7 Vagrant Box

This article is for the Store Locator Plus development team that is helping maintain the Store Locator Plus plugin family.   It is a basic outline on how to get the SLPDev Cent 7 virtual machine, a private distribution given to qualified developers, personalized and ready for use to start working on the Store Locator Plus plugins.

Get The Box

The first step is to get the latest SLPDev Cent 7 Vagrant box image from Charleston Software Associates.   The image is approximately 2GB and requires a working Vagrant installation on your laptop or desktop computer along with a working install of VirtualBox.   You will use the provided image to create a new VirtualBox machine with the a self-contained GUI development environment for the Store Locator Plus WordPress plugin.

What Is On The Box

The box is configured according to the CentOS 7 WP Dev Kit specification with a few additions.    An ssh key has been configured to provide easy access to the repositories. The WordPress installation has been completed with a site title “SLPDev” and an admin user login of vagrant / vagrant.   You get to the WordPress site by opening Firefox via Applications/Favorites and surfing to http://localhost/.

All of the current Store Locator Plus plugins are installed via the BitBucket git repositories including:

  • Store Locator Plus
  • Contact Extender
  • Directory Builder
  • Enhanced Map
  • Enhanced Results
  • Enhanced Search
  • Event Location Manager (in development, debaat/CSA)
  • Janitor
  • Location Extender
  • Pro Pack
  • Real Estate Extender (in development, aknight/CSA)
  • Social Media Extender (debaat)
  • Store Pages
  • User Managed Locations (debaat)
  • Widgets

The Selenium IDE test suite is installed in the vagrant home directory as is the WordPress Dev Kit with the Store Locator Plus publication scripts.

Personalize The Box

Before starting development you will want to change several identifiers so your code updates can be attributed to you.    You will need to run SmartGit and enter your BitBucket username and password credentials to access the repositories.    You will also want to configure git to set your username and email as the default commit author.

Git / SmartGit Update

Run the following commands from the Linux command line terminal (Applications / Favorites):

git config --global ''

git config --global 'Your Name'

The next thing you should do for SLP development is open the SmartGit repository and pull (rebase, not merge as the default mode) and fetch the latest updates for any plugins you are going to work on.

Posted on

Creating A Self Contained WordPress GUI Dev Box

After a few days of doing a whole lot of nothing as I recover from surgery I decided that it was time to start doing some computer hacking.   I’m not nearly as tired today as I have been.    The post-surgery cobwebs are mostly gone and I’m thinking clearly enough to do some productive computer work.   I’m still not 100% so staying away from code for another day may not be a bad idea.   I figure creating an upgraded WordPress Development Kit box has no chance of wreaking havoc on my published WordPress plugins.   Today is going to be an “upgrade my virtual development environment” day.

The task at hand?   Upgrade my WordPress Development Kit Vagrant box.

The original box runs a fully self-contained GUI development box on CentOS 6.5 running a local version of WordPress 3.9 with some PHP developer tools like NetBeans at-the-ready.     This makes it easy to “pack up and move” my entire development and testing system and bring it to any laptop that can run VirtualBox.     This also gives me a solid baseline to get new developers started with the same exact tools and user experience which expedites the process of getting new people online with helping code the WordPress plugins.

Today I am upgrading the WP Dev Kit Box to run on CentOS 7.     CentOS 7 has an upgraded desktop GUI and, more importantly, is virtualization-aware with built-in OS-level tools that detect when it is running as a VirtualBox guest.   It should make for a more seamless experience when going between the virtual guest box and the host system.   I’ve also moved my development over to phpStorm versus NetBeans so an eval copy of phpStorm will be installed along with the latest free version of NetBeans.   SmartGit and grunt will remain as part of the plugin development toolkit.    WordPress will be the latest production version of 4.x.

Guest System Specifications

  • CentOS 7 with GUI
  • 2GB RAM
  • 20GB dynamic HDD
  • 4 CPU cores
  • 1x 32MB video at 1440 x 1050 resolution
  • no audio
  • USB 2 support
  • NAT networking
  • Bidirectional clipboard.
  • Bidirectional drag-and-drop.
  • Port Forwarding localhost ( port 4567 to guest port 22 (ssh).
  • Standard vagrant user credentials.

Augmenting Minimal Setup

The box is installed using minimal install for CentOS 7.  The following elements have been updated to get to a standard WordPress plugin development environment:

  • vim installed
  • gvim installed
  • vagrant user added to sudoers file
  • GNOME desktop added
  • Graphical Admin Tools added
  • GUI runlevel (5) set as default
  • Install VirtualBox guest additions
  • Run the software update for all packages to 19-Oct-2014
  • Added the vagrant “base box public key” to the authorized keys file (allows vagrant scripts to run commands)

CentOS 7 GUI Base Box

The above configuration, without the developer tools like NetBeans, phpStorm, SmartGit, and Grunt nor the WordPress install is published as the “CentOS 7 GUI Base” box on VagrantCloud.   It is this foundation on which the WP Dev Kit Box will be built.

CentOS 7 WP Dev Kit Box

Now that the base GUI box is built it is time to layer on the WordPress system and development tools.  The following items are added to the mix:

  • Install PHP and PHP MySQL library.
  • Start httpd web server at boot (note: CentOS 7 uses the systemctl app to configure startup apps)
  • Install MariaDB (public domain MySQL branch) and set to start at boot.
  • Disable SELinux
  • Create the WordPress database.
    • database name: wordpress
    • database user: wpuser
    • database password: wppasswd
  • Install WordPress 4.0 and activate up to the “Enter site title, admin username, admin password” stage.
  • Install git
  • Install SmartGit 6.0.7 eval
  • Install NetBeans 8.0.1 HTML & PHP configuration
  • Install phpStorm 8.0.1 eval
  • Add Selenium IDE with GoTo lib, LastPass, and FireBug extensions to Firefox.

The WP Dev Kit box is also available in the Vagrant Cloud


Posted on

Setting Up A WordPress Development Environment

In preparation for several new projects, some of which are outside of the Store Locator Plus realm, I have been training some new developers in WordPress plugin wizardry.    This article is meant to help new developers get started with my specific Store Locator Plus development environment.    However, most of the steps here will apply to any WordPress related development environment.

Tools Required


VirtualBox is a free virtual machine software package provided by Oracle.   It will allows us to create a self-contained WordPress web server which, when using one of my virtual machine images, will contain a GUI desktop environment with all of the tools necessary to build and distribute WordPress plugins and themes.


Vagrant is a virtual machine management tool.   Vagrant is used to transport virtual machine images, import the machine images, configure the virtual machine hardware, and communicate with VirtualBox to help us get an initial machine running.

Command Line

Some knowledge of OS/X or Windows command line is useful as running Vagrant commands from the command prompt is required.  On Windows you will want to copy the Windows/System32/cmd.exe to a local “where I work on virtual machines” folder on your system and create a shortcut to it that runs in Administrator mode.


The process to get started is simple.    Install VirtualBox, install Vagrant, go to the command line for Vagrant and fetch one of my public VirtualBox environments from the VagrantCloud server, tweak the Vagrant file that manages the config for that box to turn on GUI mode, start the box.

For my developers I provide a custom VirtualBox environment that already has the Store Locator Plus family of plugins as well as access to the code repositories installed.    I will get into that specific setup in a later article.

Getting Started

Download and Install VirtualBox

Download VirtualBox from  When installing and activating VirtualBox for the first time it should ask you to install the Extension Pack.  If it does not, go tot he same link and download and install the appropriate Extension pack as well.

Download and Install Vagrant

Do the same for Vagrant here:    Vagrant will install a command line Ruby processor on your system and may guide you toward installing additional software.   Most of what you need will be contained in the install package.

Setup A Workspace

I recommend creating a folder on your system where you will work with your virtual boxes.   I create a folder under my user home directory named “VirtualBox VMs”.      On Windows you will want to  copy the Windows\System32\cmd.exe into this folder and create a shortcut that runs this in administrator mode.  This will make it easier to run your Vagrant commands without having to constantly change directories.

Fetch A Vagrant Box Image

Vagrant is a virtual machine manager.    It will take various server images and store them in a local repository of virtual machines it controls.    Part of the process here involves getting a copy of a vagrant machine image file onto your local system and adding it to that repository with vagrant commands.

Open your command line on your host system (Windows or OS/X).

Use vagrant to fetch a cloud box.    This is an older box but has a basic CentOS 6.5 configuration with WordPress up and running and some basic GUI dev tools available.    This is a good start for a “clean WordPress development environment”.  Someday I will be publishing another box that has updated software including WordPress 4.0, phpStorm eval in place of NetBeans, and other tools.    For my developers this is a good starting point, however I do have a custom box image that I can provide privately.

At the command line use the following command:

vagrant box add charlestonsw/centos6.5-wordpress-dev-kit-base-box

This will copy a 2GB virtual box image to your system and add it to the list of supported boxes with the label “charlestonsw/centos6.5-wordpress-dev-kit-base-box”. This particular Vagrant image will be linked to the VagrantCloud server and will fetch updates whenever they are available when using a vagrant init command.

Follow the link to see what is in the latest generic WordPress Dev Kit box on VagrantCloud.

Configure The New Box Hardware

I suggest starting by creating a new folder in your “Virtual Box Stuff Here” folder you created earlier for this specific system.  I do this for every new “box” I am going to run.  Create a folder called “WP Dev Kit Test Box” and change into that directory from the command prompt.

Now create a vanilla Vagrant startup file by using this command:

vagrant init charlestonsw/centos6.5-wordpress-dev-kit-base-box

This will create a generic vagrantfile to control the hardware configuration and startup commands for the new virtual machine. Edit that file to turn on GUI mode, set your memory usage, and monitor count. The memory usage and monitor count should be based on your host system hardware. I have 3 monitors and 16GB of RAM on my MacBook Pro so I set my memory to 8MB and monitor count to 2. You should set yours to use about half your RAM and typically leave it at one monitor.

Look for these lines in the vagrantfile and uncomment them:

# Provider-specific configuration so you can fine-tune various
 # backing providers for Vagrant. These expose provider-specific options.
 # Example for VirtualBox:
 config.vm.provider "virtualbox" do |vb|
 # Don't boot with headless mode
 vb.gui = true

 # # Use VBoxManage to customize the VM. For example to change memory:
 vb.customize ["modifyvm", :id, "--memory", "1024"]

Add in your monitorcount only if you are using more than one monitor for the virtual machine:

# Provider-specific configuration so you can fine-tune various
 # backing providers for Vagrant. These expose provider-specific options.
 # Example for VirtualBox:
 config.vm.provider "virtualbox" do |vb|
 # Don't boot with headless mode
 vb.gui = true

 # # Use VBoxManage to customize the VM. For example to change memory:
 vb.customize ["modifyvm", :id, "--memory", "1024"]
 vb.customize ["modifyvm", :id, "--monitorcount", "2"]

Start The Box

Still in command line, use this command to start up the new box. This will pull the box image out of the Vagrant repository and copy it into VirtualBox for use, then talk to VirtualBox and tell it to start running the new virtual machine.

vagrant up

This process may take some time. It takes 3-4 minutes on my SSD on a new MacBook Pro but took about 15 minutes on my older Windows laptop.

VirtualBox CentOS 6.5 GUI Base Box
VirtualBox CentOS 6.5 GUI Base Box

Using The Virtual Machine

System Login

Once the new box is up and running you can login with the generic user “vagrant” with a password of “vagrant”.

CentOS 6.5 Vagrant Login Banner

Surfing Local WordPress

On the new system GUI you will have Firefox installed along with basic development tools. You can bring up the local WordPress site by opening firefox and surfing to http://localhost/


Geek Details

The default user you work with is named “vagrant”.     It has access to most of the things you need on the server.   The vagrant user is part of the dev group, as is the Apache user that runs the local web server.   All of the web files are group-write enabled which means both Apache and your vagrant user can access them.

WordPress lives in the /var/www/html folder.
Plugins are in /var/www/wpslp/wp-content/plugins.

The super user is “root”.   It has the same password as the vagrant user.

You should go to System/Administration/Software update and check for system software updates.   Install the updates.

Since these are the generic Vagrant-style access credentials I strongly recommend you do not put your virtual machine on a public network.  By default it should only be accessible to your host system and should not be visible to the general network but you will want to check that.


If I have missed a step or something is not working as you expect please leave a comment on this article.   You will need to be a registered user so purchase the free “Forum Registration” on this site to get a user account.

Posted on

Vagrant : Testing WP Plugins On Multiple PHP Versions

If you’ve followed my prior blog posts you already know that I’ve been playing with Vagrant this year in an effort to improve my workflow.   To date the biggest impact of the improved workflow is being able to recreate my self-contained WordPress plugin development system which runs a full GUI dev environment on CentOS 6.5.     While that has been great for recovering from poorly designed laptop hardware, I am not really leveraging the power of Vagrant.

Today I have a new need and thus a new reason to extend my education in Vagrant.  The WordPress plugins I develop need to function in older versions of PHP.    If I write my plugins using PHP 5.5 then I run the risk of using functions that only work in newer versions of PHP.  Since the WordPress baseline is PHP 5.2 that will prevent some percentage of users from using my plugins.    By the same token, many users run newer versions of PHP that have deprecated functions.    In those cases using PHP 5.2 specific functions will not work for those customers, again limiting my overall market.  The ultimate goal is to write my plugins so they operate properly in PHP 5.2 up through the latest version of production which currently sits at version 5.5.

Vagrant is the right tool to get this job done.

Cloudy Vagrant Boxes

Up until today I have had a baseline WP Dev Kit Vagrant box, a “Vagrantized” version of my “uncluttered” Virtual Box system that has all of the tools I like to use when writing plugins.    The box is stored on my Google Drive and served via proxy from the VagrantCloud service.    Since that is the default location for the built-in Vagrant commands that is a good place to start.

The problem is that any time I need to create a new box it has to pull down a fairly large file from Google Drive to my local box.  Depending on how much throttling the ISPs are throwing in the mix between Google servers and my house it can take anywhere from 20 minutes to 20 hours to get the file in place and spin up my box.

I need something faster.    Local drive access will suffice for this latest project and Vagrant has methods to do just that.

Making It Local

To start things off I am going to make a copy of my latest fully-baked virtual box.    This is a box that started as a vanilla WP Dev Kit box I pulled down from Vagrant Cloud and over the past month have layered on all of my code and other “special tweaks” that only I am interested in.    To make it something Vagrant can “manhandle” I need to convert the full box into a Vagrant box format.

My VirtualBox Machine Names
My VirtualBox Machine Names
vagrant package --base "SLP Dev Box 2.0"

Now I have a full copy of my current running plugin development machine complete with updated code repositories, special data sets, and other “goodies” I am in the progress of building. Now I want to clone this “vagrant style” so I can set up a series ofprovisioning commands to alter the environment “on the fly”.

I create a new directory on my Windows box and initialize a new Vagrant box with the following commands:


[box type=”alert”]Make sure you are updated to the latest version of Vagrant when you run these commands.  If you are upgrading from Vagrant versions prior to 1.6 on Windows you will want to fully uninstall Vagrant 1.x, delete the C:\Hashicorp directory and install the latest version.  A reboot is required after  the update.[/box]

vagrant box add --name slp_2_0 "C:\blah\blah\blah%20blah\one_dir_up\"

The above command adds the file that was created from the virtual box with my operating environment to the list of locally available Vagrant box images.   This will make it easier to spin up new boxes and provision updates via the Vagrant shell, or other Vagrant provisioner, commands.

The command puts the file into a usable format for Vagrant and assigns the label slp_2_0 for easier reference.

You can check your Vagrant box was added properly using the following command line command:

vagrant box list
Vagrant Box List
Vagrant Box List

Day 6 : Cloning

In case you missed it, that is meant to be a clever reference to The 6th Day… a movie about clones of former state politicians, or something like that.    No, we are not cloning politicians.  Who in the hell would want to do that?!?!    Instead we are going to clone something that is actually useful to us… the original “Vagrantized” development box.

I am going to create a new directory where I can setup my Vagrantfile and related scripts to configure the base OS and software utilities to my liking for a new test case.  In this case I want all the stuff on my main box plus some updates to PHP.

I’m sure that there is a shortcut to elminate the Vagrantfile editing by packaging the original box’s Vagrantfile in the base package but that will be a task for another blog post.

mkdir slp_2_0_with_php_5_5

vagrant init slp_2_0

This creates a Vagrantfile in the new folder that I need to edit to use the GUI.  I follow my prior post on the subject and modify the Vagrantfile.  I turn on the GUI interface and also force the display count to 1.

  config.vm.provider "virtualbox" do |vb|
    # Don't boot with headless mode
     vb.gui = true

    # Set to one monitor
    vb.customize ["modifyvm", :id, "--monitorcount", "1"]

Provisioning : The Magic Sauce

Provisioning was the last part that I needed to get in place and it took me a few tries to get it right. It is stupidly simple once you know what it is doing and how to get the commands in the right place.

The examples on the Vagrant site are a good start but are not very clear when viewing them within the context of a pre-existing Vagrantfile.    My first test is the “dump the date to a text file” test case are presented on the Vagrant site.   This will write the full date into a file named “provisioned_at”.

For this to work  you MUST have an authorized_keys file in your root user directory.   The shell provisioner logs in as ROOT.  That is important to note as I was looking inside of the “vagrant” user directory which is the one I use for my daily editing.

You will also want to place the provision commands inside of the main Vagrant.configure block to be consistent with the default Puppet, Chef, and other examples.     Below is my entire Vagrantfile with all of the comments boiled out so you can see how simple this can be.


Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| = "slp_2_0"

  config.vm.boot_timeout = 600

  config.vm.provider "virtualbox" do |vb|
    vb.gui = true
    vb.customize ["modifyvm", :id, "--monitorcount", "1"]

  config.vm.provision "shell",  inline: "date > provisioned_at"


When the system boots it will write the current date to the root home directory. If you login as vagrant you can run the sudo command to see the file:

# sudo cat /root/provisioned_at

Upgrading PHP With Provisioner

Now that the basics are working we can use some shell command sequences to force the vagrant up command to upgrade PHP when the box boots. The Vagrantfile will instruct Vagrant to take a copy of my slp_2_0 box and spin it up as a new cloned virtual machine in VirtualBox. When it finishes booting it will run the yum update command, fetch the yum repository for Webtatic that provides access to the PHP 5.5 repo for CentOS 6.5, remove the old version of PHP 5.3, install PHP 5.5 with the MySQL hooks, and restart Apache. When it is done I have a fully copy of the SLP development environment but running on a PHP 5.5 instead of PHP 5.3 install.

SLP on PHP 5.5.13 with Vagrantfile
SLP on PHP 5.5.13 with Vagrantfile

Here is my Vagrantfile to accomplish that:

# Run SLP 2.0 Box
# with PHP 5.5 instead of PHP 5.3


Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| = "slp_2_0"

  config.vm.boot_timeout = 600

  config.vm.provider "virtualbox" do |vb|
    vb.gui = true
    vb.customize ["modifyvm", :id, "--monitorcount", "1"]

  config.vm.provision "shell" do |s|
    s.inline = "date > provisioned_at"
    s.inline = "yum -y update"
    s.inline = "rpm -Uvh ;
    s.inline = "yum -y remove php-common"
    s.inline = "yum -y install php55w"
    s.inline = "yum -y install php-mysql"
    s.inline = "service httpd restart"

Posted on

Installing Sass on CentOS 6.5

SLP Sass Banner

I just discovered that Sass is missing from my WordPress Development Kit Vagrant box.   My Vagrant box is on the latest CentOS 6.5 release and, luckily, setting up Sass is very simple for vanilla CentOS 6.5 users.  It is literally a two-step process:

$ sudo yum install rubygems
$ sudo gem install sass

Now I can add this to the NetBeans executables configuration by adding the path /usr/bin/sass.

Configuring Sass in NetBeans
Configuring Sass in NetBeans

Now I can edit my .scss files and have the corresponding .css files auto-generated right from NetBeans.  Nice!

Posted on

WordPress Development Fresh Start with Vagrant and Grunt

HP finally did it.  They came out to replace a system board in my laptop and half of my files on my drive are corrupted.  Restoring the 70GB of corrupt files from the local USB3 backup will take some time and I am not 100% confident in the reliability of this system.   With 48 hours of downtime I decided it would be best to push forward with my Vagrant and Grunt setup for the WordPress Development Kit I’ve been working on.

Employing Vagrant

I am using VirutalBox and Vagrant to build a series of base boxes on which to layer my development environment.  Unlike most base boxes that are plain vanilla OS installs that then use provisioners to install all the software layers on top of the OS, my custom base boxes are going to be installed with all the base tools I need to develop WordPress plugins using my WordPress Development Kit tools.


Because it is far faster to download a compressed virtual machine image with most of my stuff installed  than to download a very similar image with no tools then have Vagrant go and download  a few dozen install kits.   Sure, the standard method is more flexible and ensures everything is up-to-date, but that is not what I am trying to accomplish here.    I am building a “fast start” box that has most of what you need pre-installed in a known environment.

I also want to have a method to deploy new virtual boxes with everything in place on my OS/X system, a different laptop, or even a cloud-based server the next time my HP laptop is smoked.  Which will probably be tomorrow.      As I’ve found, restoring a large image even from a local USB3 drive is not a quick process and it is not foolproof.   Especially when going from a Windows 8.1 based backup and restoring on an OS/X system that has not been patched or updated in 8 months.


Since I already have Vagrant installed and have a published base box I am able to get started quickly.   Once Vagrant is installed I only need to set my Vagrantfile, a script that tells Vagrant what to do, to pull down the base box from the URL I have published on Vagrant Cloud:

  • Create a folder on my host system named “C65 WP Devkit  Box Setup”.
  • Create the Vagrantfile, in that directory with the pointing to charlestonsw/centos6.5-wordpress-dev-kit-base-box.
  • Open the command line for Windows and go to that C65 WP Devkit Box Setup directory.
  • Run the vagrant up command.
My new Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don’t touch unless you know what you’re doing!
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| = "charlestonsw/centos6.5-wordpress-dev-kit-base-box"
config.vm.provider "virtualbox" do |vb|
vb.gui = true


When you boot the WordPress Dev Kit Base Box with Vagrant you will find that the full CentOS GUI is active. You can login to the GUI using the standard vagrant username with a password of vagrant.

WordPress 3.9

You will find a Firefox icon on the menu bar. Opening Firefox will open the http://localhost/ URL which brings up the local copy of WordPress 3.9 that has been installed.

MySQL for WordPress

The MySQL database has been configured for WordPress.

Database name: wordpress
MySQL User: vagrant
MySQL Password: vagrant

NetBeans 8.0

NetBeans 8.0 has been installed with the PHP and HTML 5 support packages.   NetBeans is a great no-cost IDE that I have found to be very useful for editing structured WordPress PHP code.   Write your code using an object oriented design and add a good amount of phpDoc commenting and NetBeans becomes a coding power tool for WordPress plugin coding.


Firefox is installed along with several add-on packs that I use for every day code management and development.  It includes Firebug to look at JavaScript, CSS, and HTML construction.   Selenium IDE is included which allows me to download and execute my web-interface based test scripts for Store Locator Plus.   LastPass is installed to provide unique long-string passwords to all of my web services.

WordPress Development Kit

My command line WordPress Development Kit is installed on the system under the vagrant user home directory in ~/wp-dev-kit. This comes with the basic Grunt build tasks I use to manage my plugins. While you can edit the ~/wp-dev-kit/grunt/plugins.json file and configure this for your site it is recommended that you create a fork of my WordPress Development Kit on the Bitbucket site and work from your forked repository. I would remove the wp-dev-kit directory with rm -rf and clone your forked copy into the same location.

The easiest method for cloning a public repository is to use git clone with the https repository path. If you have a private repository you may want to create a SSH key pair by going to ~/.ssh and running ssh-keygen. The key will need to be added as an authorized SSH key in your Bitbucket account access management list.  Since I will be pushing and pulling content from my various Bitbucket git repositories I will use this method when setting up my clone of the WP Dev Kit Basic Box.

Bitbucket HTTPS Path
Bitbucket HTTPS Path

Similar methods can be employed with Github repositories.

Preparing For Development

These are elements that will eventually go into a provisioner setup for the Vagrant box, assuming that at least one of the Vagrant provisioning services can hand user prompts and communication with third party services.

Create Your SSH Key

This will make it easier to push & pull content from your repositories.

cd ~/.ssh
xclip -sel clip < ~/.ssh/
Setting A Vagrant SSH Key
Setting A Vagrant SSH Key

Login to your Bitbucket account, go to my account / access management, add the copied SSH key.

Bitbucket Add Vagrant Key
Bitbucket Add Vagrant Key

 Configure Your Git ID

git config –global “Lance Cleveland”
git config –global

Add SmartGit

I like the GUI interface that SmartGit provides over the git command line and gitk branch rendering.  I find SmartGit to be twice as efficient for my method of work flow over the built-in IDE and command line, so I always install this next and clone my base projects like the WP Dev Kit and my Selenium IDE scripts.   Today I am using the SmartGit 6 beta release as I find the project grouping and new interface design to be a big help in managing my projects.

SmartGit UI
SmartGit UI

I immediately setup SmartGit and clone my Selenium IDE repository so I can complete the next step with a script.

SmartGit Bitbucket Setup
SmartGit Bitbucket Setup

Complete The WordPress Install

Open Firefox and go to http://localhost/

Enter the WordPress local site information for your test site.  I use my Selenium IDE new site install script to handle this for me.

Selenium IDE setting up a  new WordPress install.
Selenium IDE setting up a new WordPress install.

Ready To Go

Now my system is ready to go.   I can start cloning my plugin code repositories into the ./wp-content/plugins directory, edit code with NetBeans, commit changes with SmartGit, and publish to my server or the WordPress plugin directory using my Grunt scripts.

With the current configuration it takes me 15 minutes to pull down a new clone and get the box booted then 5 minutes to install and configure SmartGit, clone my repository, run the WordPress install script, and fetch my first plugin repo.   20 minutes from “nothingness” to writing code.    With a local .box file on my system that time is cut down to about 8 minutes by avoiding the 1.5GB download of the box.

Not bad.

Now on to the code…

Posted on

Creating A CentOS GUI Vagrant Base Box

While playing with PuPHPet and Vagrant I realized my needs are specific enough to warrant building my own Vagrant Base Box.    My process is outlined below.

Setup VirtualBox Hardware

Start VirtualBox and build a new guest “hardware” profile:

  • Base Memory: 2048MB
  • Processors: 2
  • Boot Order: CD/DVD , Hard Disk
  • Acceleration: VT-x/AMD-V , Nested Paging , PAE/NX
  • Display: 32MB Video Memory , 3D Acceleration
  • Network: Intel PRO/1000 MT Desktop (NAT)
  • Drive: SATA with 20GB pre-allocated fixed disk
  • CD/DVD : IDE Secondary Master Empty
  • No USB, Audio, or Shared Folders
VirtualBox CentOS 6.5 GUI Base Box
VirtualBox CentOS 6.5 GUI Base Box

Base Box “Unbest” Practice

These base settings do not fall within the Vagrant Base Box best practices, however I need something a bit different than the typical Vagrant box configuration which is why I am building my own.   I build my boxes with a full GUI which enables me to spin up the virtual environment, login to the GUI, and have my entire development environment in a self-contained portable setting.    There are “lightweight” ways to accomplish this but I do have my reasons for building out my WordPress development environment this way which has been outlined in previous posts.

Adding the Operating System

Now that I have the base box setup it is time to layer on the CentOS 6.5 operating system.   I setup my box for the English language with a time zone of New York (United States EST, UTC+5), no kernel dump abilities, full drive allocated to the operating system.     It is built as a “Desktop” server which gives me the full GUI login which makes it easier to setup my GUI dev environment further on down the road.  It does add some GUI apps I don’t need very often but it is nice to have things like a simple GUI text editor and GUI system management tools for the rare cases when I want them and am too lazy to jump out to my host box to do the work.

Per Vagrant standards the box profile is setup with the root password of “vagrant” and with a base user for daily use with an username and password also set to “vagrant”.

After a couple of reboots the system is ready for a GUI login, but not quite ready for full production.

CentOS 6.5 Login Screen
CentOS 6.5 Login Screen

Adding VirtualBox Guest Additions

One of the first things to do with a VirtualBox install running a GUI is to get VirtualBox Guest Additions installed.  It helps the guest communicate with the host in a more efficient manner which greatly improves the display and the mouse tracking.  Without it the mouse lag in the guest is horrid and is likely responsible for at least 300 of the 3,000 missing hair follicles on my big bald head.

While this SHOULD be a simple operation, the CentOS desktop installation makes it a multi-step process.   Selecting “insert Guest Additions CD” from the VirtualBox server menu after starting up the new box will mount the disk.   It will prompt to autorun the disk and then ask for the root user credentials.    The shell script starts running through the Guest Additions setup but it always falls while building the main Guest Additions module.     The reason is that kernel build kits are needed and they are not installed by default.    I will outline the typical user process here as a point of reference, though most often the first commands I run to fix the issue are those listed at the end of this section.  I’ve done this enough times to know what happens and don’t usually execute the autorun until AFTER I setup the kernel build kit.  You may want to do the same.

Here is what the output looks like after a default CentOS desktop install followed by an autorun of the Guest Additions CD:

Guest Additions Fail on CentOS
This is what happens when you don’t have Kernel build tools setup and try to run Guest Additions on VirtualBox.

[box type=”info” style=”rounded”]Mouse tracking driving you crazy? Toggle to a command line screen on any Linux box with CTRL-ALT-F2. Toggle back to the GUI with CTRL-ALT-F1.[/box]

With the mouse tracking driving me nuts I toggle over to the text console with ctrl-alt-F1 and login as root on there.   You can learn what broke the Guest Addition install by going to the log files:

more vboxxadd-install.log

The typical CentOS desktop build fails the Guest Additions install with this log:

/tmp/vobx.0/Makefile.include.header:97: *** Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR= and run Make again. Stop.<br />Creating user for the Guest Additions.<br />Creating udev rule for the Guest Additions kernel module.<br />

With Guest Additions disabled and the VirtualBox not fully configured it is time to do some basic maintenance and get the kernel build environment available for Guest Additions.  Since I am logged in as root via the console I can start by getting yum updated, however the network connection does not always start up before Guest Additions is available.    The steps for getting the kernel dev in place:

Turn on the network interface eth0 (zero not oh) running:

ifup eth0

Make sure all of the installed software is updated to the latest revision:

yum update

Install the Linux kernel development files which are needed for the Guest Additions installation:

yum install kernel-devel

Install the development tool kit including compilers and other items needed to Guest Additions to hook into the kernel:

yum groupinstall "Development Tools"

Once you have the updates installed reboot the system with a shutdown -r now command while logged in as root.

The Guest Additions CD can now be mounted and autorun without error.

After running Guest Additions, reboot the server.

Turn On The Network At Boot

Now that the GUI is running and the mouse is tracking I can log in as the vagrant user and turn on the network connections.   Login, go  to System / Preferences / Network Connections on the main menu.    Check off “Connect Automatically” on the System eth0 connection.

Now the network will be enabled on boot.   That’s useful.

CentOS 6.5 Turn On Network At Boot
CentOS 6.5 turning on the network at boot.

Provide SSH Insecure Keypair To Vagrant

Best practices for Vagrant base boxes is to add an insecure keypair to the vagrant user.   While logged in as vagrant go to Applications/Systems Tools/Terminal to get to the command line.   Go the .ssh subdirectory and create the authorized_keys file by copying the public key from the Vagrant keypair repository into the authorized_keys file.

I use vim and copy the keypair content and paste it into the file.  You can use cat or other tools as well to get the content into the file.  Make sure not to introduce new whitespace in the middle of the key or it will not work.

Change the permissions of the authorized_keys file by using chmod, permission settings are very important for the file:

chmod 0600 authorized_keys 

Give Unrestricted Super Powers To Vagrant

Most users expect the vagrant login to have unrestricted access to all system commands. This is handled via the sudo application. CentOS restricts access by default and requires some updates to get it working per Vagrant best practices. Log back in to the command line console as root and edit the sudo file.


This brings up the vim editor with the sudo config file. Find the requiretty line and comment it out by adding a # before it. Then add the following line to the bottom of the file:


Logout of the vagrant and root sessions and log back in as vagrant from the GUI. You should be able to open a terminal and run any sudo commands without a password prompt. You should also be able to run sudo commands “remotely” via the ssh connection to the system.

Make SSH Faster When DNS Is Not Available

If the host and/or virtual box cannot connect to the Internet the SSH access into the Vagrant virtual box will be slow.   Editing the sshd_config file and turning off DNS lookups will fix that.   Now that you have “vagrant super powers” you can do this by logging in as the vagrant user and opening the terminal:

sudo vim /etc/ssh/sshd_config

Add this line to the bottom of the file:

UseDNS no

Host To Guest SSH Access

Connecting from the host system to the guest system WITHOUT using the graphical login or console takes a couple of extra steps. To test the SSH connection I go back to my favorite SSH tool, PuTTY.     Before testing the connection the port forwarding needs to be setup on VirtualBox Manager.

  • Go to the new system listed on the VirtualBox Manager.
  • Right-click and select Settings.
  • Select Network.
  • Click the Port Forwarding button.
  • Add the following rule:
    • Name: SSH Local To Guest
    • Protocol: TCP
    • Host IP:
    • Host Port: 4567
    • Guest IP: leave this blank
    • Guest Port: 22

Save the settings.   Open PuTTY and connect to hostname and change the port to be 4567.   You should get a login prompt.   Login with user vagrant.

VirtualBox SSH Port Forwarding
VirtualBox SSH port forwarding for Vagrant.

The issue with logging in with the vagrant private key file is that PuTTY only supports the proprietary PuTTY Private Key format.    You can download puttygen to convert the Vagrant private key file to the PuTTY Private Key file format (click to download the converted OpenSSH key in PPK format).

To use SSH keys in PuTTY, start a new session, enter 127.0.01 as the host and 4567 as the port, then set the PuTTY Private Key:

  • Click on “connection / SSH” in the left side menu to expand that selection.
  • Click on “Auth”.
  • Under Authentication parameters browse to your saved PPK file in the “Private key file for authentication” box.
Setting PuTTY Vagrant PPK
Setting PuTTY Vagrant PPK files.

Now you can connect with PuTTY and login by simply supplying a username.   This tells us that the remote vagrant command line should be able to execute all of the scripted setup commands without any issues.

Building A Box

Now that the basic system is in place it is time to “build the box”.   Vagrant has a command for doing this and if you’ve read my previous articles on setting up Vagrant you will know that I have a Windows command line shortcut that runs in my WP Development Kit folder.   With Vagrant already installed building a box is a one-line command.   I only need my machine name, which I’ve shorted to “CentOS6.5 GUI Base Box”.  Start up the Windows command line and run this:

vagrant package --base "CentOS6.5 GUI Base Box"

It will run for a while and eventually create a packaged Vagrant box ready for distribution.    By default the file will be named    I’ve renamed mine to for distribution purposes.   You can find it on my Vagrant Cloud account.

You can learn more about the box-building process via the Vagrant Creating A Base Box page.

Launching The Box

To launch the new box hosted on Vagrant Cloud I go to my local folder and execute these commands:

Download the image (stored on my Google Drive account) using Vagrant Cloud as a proxy:

vagrant box add charlestonsw/centos6.5-gui-base-box 

Create the vagrantfile that assists in the box startup command sequence:

vagrant init charlestonsw/centos6.5-gui-base-box

Start the box on VirtualBox:

vagrant up

By default, Vagrant starts boxes in headless mode, meaning no active console.   I want the GUI login so I shut down the box and find the vagrantfile to add the GUI startup line.    The command is already in the file and only needs a few lines to be uncommented to allow a GUI startup with a console.    Edit the vagrantfile and look for these lines:

config.vm.provider "virtualbox" do |v|
v.gui = true

There are few other comments in the default vagrantfile, you can leave the limits tweaks commented.  You will end up with a vagrantfile section that looks like this:

# Provider-specific configuration so you can fine-tune various
 # backing providers for Vagrant. These expose provider-specific options.
 # Example for VirtualBox:
 config.vm.provider "virtualbox" do |vb|
 # Don't boot with headless mode
 vb.gui = true

 # # Use VBoxManage to customize the VM. For example to change memory:
 # vb.customize ["modifyvm", :id, "--memory", "1024"]

Save the file and restart the box with the vagrant up box.

That’s it… a new Vagrant box.   Now on to the system tweaks to get my WP Dev Kit setup.

Posted on

WordPress Workflow : Automated Virtual Box Creation

I am into my first full day back after WordCamp Atlanta (#wcatl) and have caught up on most of my inbox, Twitter, and Facebook communications.   As I head into a new week of WordPress plugin production I decided now is as good a time as any to update my work flow.

I learned a lot of new things at WordCamp and if there is one thing I’ve learned from past experience it is DO NOT WAIT.   I find the longer I take to start implementing an idea the less chance I have of executing.

My first WordCamp Atlanta 2014 work flow improvement starts right at the base level.   Setting up a clean local development box.   I had started this process last week by manually configuring a baseline CentOS box and was about to setup MySQL, PHP, and all the other goodies by hand.  That was before I learned more about exactly what Vagrant can do.   I had heard of Vagrant but did not fully internalize how it can help me.  Not until this past weekend, that is.

My Work Environment

Before I outline my experience with the process I will share my plugin development work environment.

  • Host System: Windows 8.1 64-bit on an HP Zbook laptop with 16GB of RAM with a 600GB SATA drive
  • Guest System: CentOS 6.5 (latest build) with 8GB RAM on an Oracle VirtualBox virtual machine
    • Linux Kernel 2.6.32-431
    • PHP v5.4.23
    • MySQL v 14.14 dist 5.5.35
  • Dev Took Kit: NetBeans, SmartGit, Apigen and phpDoc, MySQL command line, vim
HP Zbook Windows 411
My Development System laptop config.

While that is my TYPICAL development environment, every-so-often I swap something out such as the MySQL version or PHP version and it is a HUGE PAIN.    This is where Vagrant should help.  I can spin up different virtual boxes such as a single-monitor versus three-monitor configuration when I am on the road or a box with a different version of PHP.     At least that is the theory anyway.   For now I want to focus on getting a “clean” CentOS 6.5 build with my core applications running so I can get back to releasing the Store Locator Plus Enhanced Results add-on pack this week.

Getting Started With Vagrant

The Rockin’ Local Development With Vagrant talk that Russel Fair gave on Saturday had me a bit worried as he was clearly on the OS/X host and the examples looked great from a command line standpoint.  Being a Linux geek I love command line, but I am not about to run virtual development boxes in in a VirtualBox guest.   Seems like a Pandora’s box to me… or at least a Russian doll that will surely slow down performance.   Instead I want to make sure I have Vagrant running on my Windows 8.1 bare metal host.    That is very much against my “full dev environment in a self-contained and portable virtual environment” standard, but one “helper tool” with configurations backed up to my remote Bitbucket repository shouldn’t be too bad, as long as I don’t make it a habit to put dev workflow tools on my host box. Yes, Vagrant does have a Windows installer and I’m fairly certain I won’t need to be running command-line windows to make stuff work.   If I’m running Windows I expect native apps to be fully configurable via the GUI.  Worst case I may need to open a text editor to tweak some files, but no command line please.

Here is the process for a Windows 8.1 install.

  • Download Vagrant.
  • Install needs to be run as admin and requires a system reboot.
  • Ok… it did something… but what?   No icons on the desktop or task bar or … well… anywhere that I can find!

Well… sadly it turns out that Vagrant appears to be a command line only port of the Linux/OSX variants.    No desktop icons, no GUI interface.   I get it.  Doing that is the fast and easy process, but to engage people on the Microsoft desktop you really do need a GUI.    Yes, I’m geek enough to do this and figure it out.   I can also run git command line with no problem but I am FAR more efficient with things like the SmartGit GUI interface.

Maybe I’m not a real geek, but I don’t think using command line and keyboard interaction as the ONLY method for interacting with a computer makes you a real techie.    There is a reason I use a graphical IDE instead of vim these days.    I can do a majority of my work with vim, but it is FAR more efficient to use the GUI elements of my code editor.

Note to Vagrant: if you are doing a windows port at least drop a shortcut icon on the desktop and/or task bar and setup a Windows installer.   Phase 2: consider building a GUI interface on top of the command line system.

It looks like Vagrant is a lower-level command line tool.   It will definitely still have its place, but much like git, this is a too on which other “helpers” need to be added to make my workflow truly efficient.  Time to see what other tools are out there.

Kinda GUI Vagrant : PuPHPet

Luckily some other code geeks seem to like the idea of  GUI configuration system and guess what?   Someone created a tool called PuPHPet (which I also saw referenced at WordCamp so it must be cool)  and even wrote an article about Vagrant and Puppet.   Puppet is a “add on”, called a provisioner,  to setup the guest software environment.

PuPHPet is an online form-based system that builds the text-file configuration scripts that are needed by Vagrant to build and configure your Virtualbox (or VMWare) servers.   It is fairly solid for building a WordPress development environment, but it does mean reverting back to CentOS 6.4 as CentOS 6.5 build scripts are not online.     Though I am sure I can tweak that line of the config files and fix that, but that takes me one-step away from the “point and click” operation I am looking for.

Either way, PuPHPet, is very cool and definitely worth playing with if you are going to be doing any WordPress-centric Vagrant work.

PuPHPet Intro Page
The PuPHPet online configuration tool for creating Vagrant + Puppet config files.


Puppet Makes Vagrant and PuPHPet Smarter

Now that I have Vagrant installed and I discovered PuPHPet I feel like I am getting closer to a “spin me up a new virtual dev box, destroy-as-desired, repeat” configuration.  The first part of my workflow improvement process.   BUT…. I need one more thing to take care of it seems… get Puppet installed.   I managed to wade through the documentation (and a few videos) to find the Windows installers.

Based on what is coming up in the install window it looks like the installer will roll out some Apache libs, ruby, and the windows kits that help ruby run on a windows box.

Puppet Install Licenses
The Puppet installer on Windows.

Again, much like Vagrant, Puppet completes the installation with little hint of what it has done.    Puppet is another command line utility that runs at a lower-level to configure the server environments.   It will need some of the “special sauce” to facilitate its use.     A little bit of digging has shown that the Puppet files are all installed under the C:\Program Files (x86)\Puppet Labs folder.    On Windows 8.1 the “Start Menu” is MIA, so the documentation about finding shortcuts there won’t help you.    Apparently those shortcuts are links to HTML doc pages and some basic Windows shell scripts (aka Batch Files) so nothing critical appears to have gone missing.

The two files that are referenced most often are the puppet and facter scripts, so we’ll want to keep track of those.   I’ll create a new folder under My Documents called “WP Development Kit” where I can start dumping things that will help me managed my Windows hosted virtual development environment for WordPress. While I’m at it I will put some links in there for Vagrant and get my PuPHPet files all into a single reference point.

WP Dev Kit Directory
The start of my WP Dev Kit directory. Makes finding my PuPHPet, Vagrant, and Puppet files easier.

Now to get all these command line programs to do my bidding.

Getting It Up

After a few hours or reading, downloading, installing, reading some more, and chasing my son around the house as the “brain eating dad-zombie”, I am ready to try to make it all do something for me.    Apparently I need to use something called a “command line”.  On Windows 8.1.

I’m giving in with the hopes that this small foray into the 1980’s world of command line system administration will yield great benefits that will soon make me forget that DOS still exists under all these fancy icons and windows.   Off to the “black screen of despair”, on of the lesser-known Windows brethren of the “blue screen of death”.     Though Windows 8 tries very hard to hide the underpinnings of the operating system, a recent Windows 8 patch and part of Windows 8.1 since “birth” is the ever-useful Windows-x keyboard shortcut.   If you don’t know this one, you should.   Hold down the Windows key and press x.   You will get a Windows pop-up menu that will allow you to select, among many other things, the Command Prompt application.

If you right-click on the “do you really want to go down this rabbit hole” confirmation box that comes up with the Command Prompt (admin) program you will see that it is running C:\Windows\system32\cmd.exe.     This will be useful for creating a shortcut link that will allow me to not only be in command mode but also to be in the “source” directory of my PuPHPet file set.    I’m going to create a shortcut to that application in my new WP Development Kit directory along with some new parameters:

  • Search for cmd.exe and find the one in the Windows\system32 directory.
  • Right-click and drag the file over to my WP Development Kit folder, selecting “create shortcuts here” when I drop it.
  • My shortcut to cmd.exe is put in place, but needs tweaking…
  • Right-click the shortcut and set the “Start in” to my full WP Development Kit folder.

Now I can double-click the command prompt shortcut in my WP Development Kit folder and not need to change directory to a full path or “up and down the directory tree” to get to my configuration environment.

Running Vagrant andn Puppet via PuPHPet Scripts
Running Vagrant andn Puppet via PuPHPet Scripts

A few key presses later and I’ve managed to change to my downloaded PuPHPet directory and execute the “vagrant up” command.   Gears starting whirring, download counters started ticking, and it appears the PuPHPet/Vagrant/Puppet trio are working together to make something happen.  At the very least it is downloading a bunch of stuff from far away lands and filling up my hard drive.   Hopefully with useful Virtualbox disk images and applications required to get things fired up for my new WordPress dev box.

We’ll see…

Link Summary