Posted on

Fixing VVV svn cleanup Invalid cross-device link messages

Ran into a unique situation while updating my VVV box after  a weekend of WordPress Core and plugin development at WordCamp US this past weekend.   Today, after the formal release of WordPress 4.4 I needed to update the code in my WordPress trunk directory on the VVV box.  Since I have other things in progress I didn’t want to take the time to reprovision the entire box.  Though, as it turn out, that would have been faster.

The issue was when I tried to do the svn up command to update the /srv/www/wordpress-trunk directory and make sure I was on the latest code.   The command failed, insisting that a previous operation was incomplete.  Not surprising since the connectivity at the conference was less-than-consistent.    svn kindly suggest I run svn cleanup.  Which I did.  And was promptly met with an “invalid device cross-link” error when it tried to restore hello.php to the plugin directory.

The problem is that I develop plugins for a living.   As such I have followed the typical VVV setup and have linked my local plugin source code directory to the vvv plugin directory for each of the different source directories on that box.    I created the suggested Customfile on my host system and mapped the different directory paths.     On the guest box, however, the system sees this mapping as a separate drive.  Which it is.  And, quite honestly I’m glad they have some security in place to protect this.  Otherwise a rogue app brought in via the Vagrant guest could start writing stuff to your host drive.   I can think of more than one way to do really bad things if that was left wide-open as a two-way read-write channel.

VVV Customfile Cross Device Maker
VVV Customfile Cross Device Maker

The solution?

Comment out the mapping in Customfile on the host server.  Go to your vvv directory and find that Customfile.  Throw a hashtag (or pound sign for us old guys) in front of the directory paths you are trying to update with svn.  In my case wordpress-trunk.

Run the vagrant reload command so you don’t pull down and provision a whole new box, but DO break the linkage to the host directory and guest directory.

Go run your svn cleanup and update on the host to fetch the latest WP code.

Go back to the host, kill the hashtag, and reload.

 

Hope that saves you an extra 20 minutes surfing Google, or your favorite search service, for the answer.

 

Posted on

VVV For WordPress Development

Banner Vagrant Cloud WP Dev Kit Box

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" ]

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

Paths:

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