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: https://github.com/Varying-Vagrant-Vagrants/VVV.
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" ]
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.
With VVV installed these URLs should work in your browser.
- http://local.wordpress.dev/ for WordPress stable
- http://local.wordpress-trunk.dev/ for WordPress trunk
- http://src.wordpress-develop.dev/ for trunk WordPress development files
- http://build.wordpress-develop.dev/ for the version of those development files built with Grunt
- http://vvv.dev/ for a default dashboard containing several useful tools
- The VVV docs/website: https://github.com/Varying-Vagrant-Vagrants/VVV
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