I discovered Varying Vagrant Vagrants (VVV) a couple of months ago and since then I have used it for my WordPress plugin development and testing. It is extremely easy to set up and let’s me test my plugins in various versions of WordPress very easily.
In my never-ending quest to optimize my development environment and work flow, I tried various configurations and finally settled on the following setup where I am mapping my plugins folder using VVV’s shared folders. This allows me to easily test my plugins in various versions of WordPress, without copying them around.
I thought of sharing my setup and my Customfile so that it would be useful for others or to future-me 🙂
About VVV
If you are a WordPress developer or contributor and haven’t heard about VVV, then stop reading right away and go to VVV’s homepage, read about it and then install it. You can thank me later 🙂
Varying Vagrant Vagrants or VVV for short is an open source Vagrant configuration focused on WordPress development. It provides a reproducible development environment that is ideal for both WordPress plugin and theme development as well as for contributing to WordPress core.
The development environments that are setup by VVV are nothing but server instance created as a VM. VVV automatically shares the source, config and log folders between the VM and host OS, so that you can use normal tools like your editors etc in your host OS and the changes will be automatically seen by the VM and vice versa. All these are automatically setup for you and you don’t have to do any complex setups or mapping drives.
It setups up three WordPress installs (stable, trunk and develop) that allows you to easily test your WordPress plugin or theme in different WordPress versions without the need for creating separate server instances.
You can follow the installation instructions available at VVV github page to easily set it up.
Mapping plugin folder
For most people the default mapping provided by VVV should be good enough. But I wanted to tweak it a bit.
By default VVV creates the following folder structure inside www folder which is shared with the VM.
The three WordPress installations live inside the following folders
- wordpress-default
- wordpress-develop
- wordpress-trunk
Each instance has its own plugin and theme folders. Since I wanted to test my plugins in all the three instances I didn’t wanted to copy my plugin folder around. Instead I had set up shared folders so that the plugin folder (in the host OS) is automatically mapped to all three WordPress instance’s plugin folder.
I achieved this by using Vagrant’s shared folder. In my Customfile I created the following mappings.
Any changes to my plugin folder will be now automatically reflected in all three WordPress instances.
Bonus – Increase VM RAM
While you are at it you may also want to increase the RAM that is allocated to your VM. You can do it by adding the following line in your Customfile.
What are your favourite tricks for using VVV effectively?
When I tried this, I got an error saying that the directories already existed because I had already created the symlink on the host. When I removed the symlink and only used the Customfile mappings, this worked on VM. But the reverse didn’t work. In other words, on my host it created the directory, but didn’t sym link it.
This isn’t ideal because now as I code I have to bounce around the host filesystem to pull up the appropriate file instead of working out of the one directory.
Any thoughts? Thanks!
Hello Jason,
This is really strange since everything is working properly for me.
Can you briefly explain your setup and directory structure?
This is a very new plugin for wordpress. all wordpress developers should know about it.thanks for sharing this informative blog.
Hey! I’m Tom lead developer on the VVV project!
Overlapping and nested folder shares can cause problems, sometimes they work, sometimes they don’t, sometimes they half work with phantom files and random issues.
If you want to do this, choose a location inside the VM that doesn’t overlap/nest, then configure WordPress to use those locations via `wp-config.php` constants. This provides maximum compatibility.
Also, using
:mount_options => [ "dmode=775", "fmode=774" ]works for VirtualBox but will break on other providers such as Hyper-V or Parallels. Fix this by wrapping this in a VirtualBox condition, for example:config.vm.provider :virtualbox do |_v, override|
override.vm.synced_folder “/Users/sudar/Dropbox/plugins/”, “/srv/www/wordpress-default/wp-content/plugins”, :owner => “www-data”, :mount_options => [ “dmode=775”, “fmode=774” ]
end
Finally, you don’t need a customfile to bump the memory in the VM, you can change it in
config/config.ymlthen reprovision.