Tag: Vagrant

Running PHPUnit on VVV from PHPStorm 9

Posted on by Jeremy Felt

I spent so much time trying to get this working last November and kept running into brick walls. Today, I finally revisited a comment on that same issue by Rouven Hurling that pointed out two excellent notes from Andrea Ercolino.

  1. How to run WordPress tests in VVV using PHPStorm 8
  2. How to run WordPress tests in VVV using WP-CLI and PHPStorm 8

These are both great examples of showing your work. Andrea walks through the issue and shows things that didn’t work in addition to things that did. I was able to use the first to quickly solve an issue that I’ve been so close to figuring out, but have missed every time.

And! I haven’t gone through the second article yet, but the hidden gem there is that he has remote debugging with Xdebug working while running tests with PHPUnit. I’ve wanted this so much before.

All that aside (go read those articles!), I stumbled a bit following the instructions and wanted to log some of the settings I had to configure in order for PHPUnit to work properly with PHPStorm 9 and my local configuration.

For this all to work, I had to configure 4 things. The first three are accessed via PHPStorm -> Preferences in OSX. The fourth is accessed via the Run -> Edit Configurations menu in OSX.

A remote PHP interpreter

Choosing “Vagrant” in the Interpreters configuration didn’t work for me. I got an error that VBoxManage wasn’t found in my path when I selected my Vagrant instance and it tried to auto-detect things. I’m not sure if this is a bug or a misconfiguration. I almost wonder if it’s related to my recent upgrade today to Vagrant 1.7.4 and VirtualBox 5.0.

Instead I tried going forward with “SSH Credentials” to see what would happen. I put in the IP of the VVV box, 192.168.50.4, and the vagrant/vagrant username and password combination for SSH. I left the interpreter path alone and when I clicked OK, everything was verified. I was hesitant, because in the first step I had already deviated from the plan.

PHPUnit configuration

This one was easier and didn’t require any altered steps. I added a remote PHPUnit configuration, chose the already configured remote interpreter and was good to close out.

SFTP deployment configuration

Because I was not able to get Vagrant configured properly in the first step, I am dealing with an entirely different path. PHPStorm wants to have a deployment configured over SFTP so that it can be aware of the path structure inside the virtual machine that leads to the tests.

Luckily nothing special needs to happen in the VM to support SFTP, so I was able to add 192.168.50.4 as the server and vagrant/vagrant as the username and password combination.

I originally tried putting the full path to WordPress here as the root directory, but that caused PHPStorm to prepend that on any automatic path building it did. I tried Autodetect as well, but that detected /home/vagrant, which did not work with the WordPress files. Through the power of deduction, I set the actual root / as the root. 😜

I also used the Mappings tab on this screen to match up my local wordpress-develop directory with the one I’m interacting with remotely.

Run/debug configurations

This one ends up being very straight forward now that everything else is configured. All I needed to do is select the phpunit.xml.dist file via its local path on my machine.

And then I was good! I can now run the single site unit tests  for WordPress core just by using the Run command via green arrows everywhere in PHPStorm.

The tests took 3.14 minutes to run through the interface versus 2.45 minutes through the command line, but I was given a bunch of information on skipped tests throughout. I’ll likely stick to the command line interface for normal testing, though I’m looking forward to getting Xdebug configured along side this as it will make troubleshooting individual tests for issues a lot easier.

Big thanks again to Andrea Ercolina for the great material that brought me to a working config!

An old answer to the Vagrant vs MAMP question on Reddit

Posted on by Jeremy Felt

I’m about to delete my Reddit account because it’s weird to have these passwords around for accounts that I really have no intent of using. I did find one answer I left to a question about my “Evolving WordPress Development with Vagrant” post that I feel like saving for posterity.

Is there an advantage for a single designer/developer who uses MAMP to set up and develop WordPress sites? I read their docs but I couldn’t discern a real advantage if it’s just a single user configuration? – grafxbill

While there probably isn’t an immediate advantage, I would argue that if you can see yourself ever working with more than one site or a host that does not use a LAMP stack, then the long term benefits are worth it. Though one of my next goals is to setup a basic LAMP stack via Vagrant and at that point I’ll come back and tell you to ditch MAMP completely. 🙂

Caching alone is probably the most important reason for having a matching environment. These issues are so hard to troubleshoot locally if you don’t have the same setup. APC via MAMP can be helpful at first, but really duplicating the environment takes away a lot of assumption.

My other favorite thing is the quality of the sandbox. I can play around with server settings, screw everything up, and then ‘vagrant destroy’ to be back at square one without my personal computer feeling any of the side effects.

v1.1 of Varying Vagrant Vagrants has been pushed

Posted on by Jeremy Felt

This is a smaller release in the grand scheme of things, though the first (!) as a new organization. The milestone has been ready for several weeks now. Thanks goes to Aaron Jorbin for prodding it along. 🙂

Quite a bit has been stable since v1.0, so we’re in a good spot to make a couple big changes in the next release including PHP 5.5.

From the changelog:

  • Transition to Varying Vagrant Vagrants organization.
  • Add a CONTRIBUTING document.
  • Add --allow-root to all wp-cli calls in VVV core.
  • Use a new global composer configuration.
  • Add zip as a package during provisioning.
  • Introduce a helpful caveats section.
  • Remove tcp_nodelay config in Nginx. Reasoning in 0cce79501.

As always, feel free to stop by and open an issue if there’s something you’d like to see!

A Varying Vagrant Vagrants Organization

Posted on by Jeremy Felt

This is a very transformative moment for the Varying Vagrant Vagrants project.

About a week ago, I reached out to Jake with a proposal to move VVV from under the wing of 10up to an organization of its own. We’ve been cruising along for just over a year, have around 125 unique visitors on the repository a day, and have a nice regular community of contributors. We have received pull requests from just around 40 contributors (!!!) and the issues are constantly a lively place of discussion.

Jake immediately agreed and we were able to talk through the process and the future very quickly. 10up has been a gracious and excellent host for VVV this entire time—the farewell post is great—and I’m looking forward to future steps we can take as a community now that we’re on our own.

I’d like to think that the goal to bring Vagrant to the forefront of WordPress developers’ minds has been accomplished. Through VVV and other related projects, the use of a development environment that closely matches production has come a long way.

I do think that VVV is the best tool out there for contributing to WordPress core. We provide stable, trunk, and develop versions of WordPress and everything needed to run the Grunt build tools and PHPUnit unit tests.

With that in mind, I think we should be able to line up a few goals.

  1. Continue being the place for a WordPress core development environment. This primarily means that we stay on top of the tools that core introduces into the development flow. Providing an approachable way to use these tools and documentation will go a long way.
  2. Directly related to goal one, some of the advancements we make should be around testing multiple versions of everything. If we can make it easy to fire up a PHP 5.x environment and test Nginx or Apache with WordPress 3.x or 4.x, that would be amazing.
  3. VVV has an excellent method for auto site setups. Over time we’ve had some nice demand for a few that could help quite a bit. It would be great to see a couple that provide basic setups for WordPress multisite and WordPress under Apache rather than our default of Nginx.
  4. Bring other tools to the forefront of WordPress developers’ minds. It may be great to see versions of VVV that harness Salt, Puppet, or Chef rather than the bash scripting that we’ve forced upon the project so far. VVV has an opportunity to be a learning tool for all of us in exploring methods of testing, provisioning, and deployment.

Right.

So please chime in with any suggestions that you may have. I’d love to toss the keys to a few new repositories over to anybody that’s interested in building out new tools. Feel free to use the main VVV repository under the Varying Vagrant Vagrants organization to open an issue and discuss your thoughts. We can split things off as needed.

Over time we’ll get more organized and setup a more official forum for discussions as well as some contributing guidelines. I’m going to reach out to a few regular contributors and get them added as committers. We also need to spend some time with licensing to see if we can get away with GPL for everything or if another would be more applicable to the work that we’re doing.

That’s that. Thank you all for being so great. Here’s to the next year of VVV. 🙂