What’s New in VVV 2.0

Varying Vagrant Vagrants ( VVV ) has undergone a small transformation for the better. This post will cover what’s changed and how to make sure your local developer environment isn’t left behind

The New Provisioner

The fabulous Lorelei Aurora has rewritten the provisioning system for VVV, enabling a slew of new features and improved speed/reliability, including:

  • The ability to provision individual sites
  • A master config file named vvv-custom.yml listing every site with aliases
  • A significant number of bug fixes

The New Config File

When checking out VVV, you’ll notice a new vvv-config.yml config file in the root. Create a copy of this and name it vvv-custom.yml so your changes aren’t destroyed on update. With this file, you can add, create, and configure the sites in your VVV install.

Here is a standard vvv-config.yml:

---
sites:
 wordpress-default:
  repo: https://github.com/Varying-Vagrant-Vagrants/vvv-wordpress-default.git
  hosts:
  - local.wordpress.dev

 wordpress-develop:
  repo: https://github.com/Varying-Vagrant-Vagrants/vvv-wordpress-develop.git
  hosts:
  - src.wordpress-develop.dev
  - build.wordpress-develop.dev

utilities:
 core:
 - memcached-admin
 - opcache-status
 - phpmyadmin
 - webgrind

In your vvv-custom.yml you can remove the default installs or add your own.

Adding a New Site

Adding a new site is as simple as adding it under the sites section of vvv-custom.yml.

To add a site:

example:

To add a site with a repository:

example: https://github.com/example/example.git

To add a site with a repository and a domain/host:

example:
  repo: https://github.com/example/example.git
  hosts:
  - example.local

Site Provisioning

When the provisioner reads the configuration file, it will clone your repository (if its defined) into the appropriate location. In the examples above that will be /srv/www/example/ but this can be changed with the vm_dir key.

Once this has happened, it will look for 2 files, provision/vvv-init.sh, and provision/vvv-nginx.conf.  VVV will also check for these in the sites root folder for backwards compatibility. These files are optional if you wish to install WordPress manually, but necessary if you want to install WordPress automatically.

The provisioner will attempt to load these files and run them during provisioning, configuring Nginx accordingly. It will also pre-parse the Nginx config file, replacing variables such as {vvv_path_to_site} with their actual values

For example, here is a provision/vvv-nginx.conf for the example site:

server {
 listen 80;
 listen 443 ssl;
 server_name {vvv_site_name}.local;
 root {vvv_path_to_site};

 error_log {vvv_path_to_site}/log/error.log;
 access_log {vvv_path_to_site}/log/access.log;

 set $upstream {upstream};

 include /etc/nginx/nginx-wp-common.conf;
}

And here’s a provision/vvv-init.sh script:

#!/usr/bin/env bash

# Make a database, if we don't already have one
echo -e "\nCreating database '${VVV_SITE_NAME}' (if it's not already there)"
mysql -u root --password=root -e "CREATE DATABASE IF NOT EXISTS ${VVV_SITE_NAME}"
mysql -u root --password=root -e "GRANT ALL PRIVILEGES ON ${VVV_SITE_NAME}.* TO wp@localhost IDENTIFIED BY 'wp';"
echo -e "\n DB operations done.\n\n"

# Nginx Logs
mkdir -p ${VVV_PATH_TO_SITE}/log
touch ${VVV_PATH_TO_SITE}/log/error.log
touch ${VVV_PATH_TO_SITE}/log/access.log

# Install and configure the latest stable version of WordPress
cd ${VVV_PATH_TO_SITE}
if ! $(wp core is-installed --allow-root); then
 wp core download --path="${VVV_PATH_TO_SITE}" --allow-root
 wp core config --dbname="${VVV_SITE_NAME}" --dbuser=wp --dbpass=wp --quiet --allow-root
 wp core multisite-install --url="${VVV_SITE_NAME}.local" --quiet --title="${VVV_SITE_NAME}" --admin_name=admin --admin_email="admin@${VVV_SITE_NAME}.local" --admin_password="password"
else
 wp core update
fi

Migrating 1.x Sites

These should still work, the vvv-nginx.conf will still be picked up, as will the vvv-init.sh file, but you might have noticed that if you provision nothing happens? The new provisioner doesn’t search the www subfolder, and only reads the vvv-custom.yml file to discover sites. This makes the provisioner much faster, but causes a backward compatibility break.

You can fix this though, by adding your site to the vvv-custom.yml file in the root, e.g.

  oldsite:

Provisioning a Single Site

Instead or provisioning all sites, you can tell VVV to provision a specific site on its own. This is super handy if you’re changing your vvv-init.sh or vvv-nginx.conf, and need to iterate fast. Simply run the provision command like this:

vagrant provision --provision-with=site-example

This will provision the site named example, and only that site

Changing PHP Versions

You can set the PHP version in vvv-custom.yml when defining a site. Here’s an example of PHP 7.1:

sites:
 example:
 nginx_upstream: php71

utilities:
 core:
 - php71

Here’s some more examples for other versions of PHP. Take note that this will not work if set $upstream {upstream}; is removed from the nginx config

All Prepped for VVV 2.X!

I know I am! Hopefully this proves useful and a big thanks to the VVV developers!

9 thoughts on “What’s New in VVV 2.0

  1. Need some clarification… 🙂

    1. Can I use the vm_dir key per site in the yml? I currently have projects separated in two different custom folders inside www and would like them to keep working if I migrate.

    2. So the vvv-init.sh etc. files can still be per site but now they must be inside a /provision folder inside the sites folder?

  2. Pingback: vvv-custom.yml Files – Show Me Your’s, I’ll Show You Mine – Jonathan Desrosiers

Leave a Reply

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