A lot of us coming to Varying Vagrant Vagrants are arriving in Nginx land from the kingdom of Apache, and at least for me the chief "gotcha" I've run into is that pretty permalinks don't "just work." Specifically, there's a index.php that appears in permalink settings:

I searched around to see if I could change something in nginx-wp-common.conf that would fix this issue. The only good lead I found was a location / {} rule in my nginx config that turned out to already be in place, so I'm pretty certain that isn't the correct solution. Additionally, there was at least some indication in the WP forums that even if the rule here worked it wouldn't apply to local dev sites running in subdirectories, which would make replicating a production environment challenging.

Installing the Nginx helper plugin fixes this issue, but I'm guessing that there's a configuration-based solution to this particular problem that wouldn't require installing a plugin on every local dev site you spin up; if so, it would be a huge help to see that added to the config.

Alternately, I'm happy to take a stab at investigating a fix, but I'd need to be pointed at a good Nginx resource—I'm a little out of my league at the moment!

Thanks a lot for VVV, it's a wonderful tool.

I've reported the issue here on the Capsule Server project.

crowdfavorite/wp-capsule-server#6

Basically capsule and capsule server sync fine under MAMP but don't sync data (they setup fine) under Vagrant.

Hard to point to the commits right now as GitHub is being silent, but a bunch of Xdebug changes just landed.

After digging around and becoming more familiar with the configurations of PHP and its available mods after the upgrade to PHP 5.4, it seemed that our xdebug config process—beyond not currently working—was a little convoluted.

I've consolidated things to a custom xdebug.ini file that is now always mapped to /etc/php5/fpm/conf.d/xdebug.ini and is loaded after /etc/php5/fpm/conf.d/20-xdebug.ini, which loads the xdebug.so extension from the proper location and can be turned off/on with php5enmod xdebug and php5dismod xdebug.

So... Need help verifying that I didn't break things while fixing them. I'm not a code stepper yet, so @tddewey and @ericmann, please chime in if you have time. I would also like to become a code stepper, so if somebody feels like documenting a quick setup for PHPStorm, we can include that with the wiki as well.

I've been running tag-0.4 fine for a few weeks, but tried both bleeding edge and tag-0.5 today, and both shutdown right after being started. It appears this has something to do with a failed SSH command during provisioning, see attachment for specifics running Vagrant 1.2.1 and VVV master 4/22:

We should handle WP-Cli installation same way as Composer (851ac8c), so it can be updated on provision.

Currently we're cloning master branch so simply we can add git pull origin, if wp-cli directory already exists.

Now that we're smarter at network detection and package detection, we should be aware enough to skip the DB import scripts when mysql isn't available.

The 4.2.12 release is now available here: https://www.virtualbox.org/wiki/Download_Old_Builds_4_2

The link in 'Getting Started' (https://www.virtualbox.org/wiki/Downloads) only shows the current release (4.2.14). It seems there are problems getting Vagrant 1.2.2 and VirtualBox 4.2.14 to work nicely together.

When you turn on xdebug and instantiate a debugging session, you have 60 seconds to complete it before getting a 504 Gateway Timeout in the browser.

I'm proposing increasing the value of default_socket_timeout in php.xdebug.ini:L919 -- but to what value? 5 minutes (300s), 10 mins (600s)? What side effects are there, in a debugging development environment, to setting it obscenely high?

apc.shm_size is left at the default, which is a measly 32 MB. Bigger WordPress installs that use an APC object cache backend can very quickly hit this limit. If you hit this limit on every page load, you cause a catastrophic failure which renders a site unusable.

I recommend that apc.shm_size be set to 256 MB.

I'm getting this is both default domains and the custom domain I have set for a client site. Everything works fine for a bit, then I get the nginx welcome screen, or simply an error page in Chrome saying it couldn't resolve the site.

I acknowledge my ignorance in Vagrant and nginx, so this could be something I'm just missing.

I'm running with Virtual Box 4.2.12 r84980 on Mountain Lion.

I moved the WordPress stable installation to use latest.tar.gz instead of SVN as there was no reason for us to stay connected to VCS when the plan is to keep that always stable.

Are there downsides to using http://github.com/WordPress/WordPress for our copy of WordPress trunk?

If no...

Is there a smarter/faster way than a straight git clone? Thanks to the awesome stuff added in 3.6, the footprint is a lot bigger so I'm not sure how much faster we can get.

I had to apply the following patch to get Xdebug to appear in the phpinfo dump, and to utilize the overloaded var_dump which pretty-prints output:

diff --git a/config/php5-fpm-config/php-custom.ini b/config/php5-fpm-config/php-custom.ini
index 8d69ebb..4d0d645 100644
--- a/config/php5-fpm-config/php-custom.ini
+++ b/config/php5-fpm-config/php-custom.ini
@@ -119,3 +119,6 @@ max_file_uploads = 20
 ; Default timeout for socket based streams (seconds)
 ; http://php.net/default-socket-timeout
 default_socket_timeout = 60
+
+; Load Xdebug extension
+zend_extension=/usr/lib/php5/20100525+lfs/xdebug.so

I would have thought Xdebug would have been enabled by default?

I miss using Sequel Pro every once and a while. We should forward the port for mysql

This isn't really a VVV problem, but we're in a decent place to figure it out and at least document it somewhere. I'm not entirely sure it's a problem yet either.

It seems that strange things can happen if you initiate a vagrant up from within a Dropbox directory. My working theory is that the .vagrant/ directory created during the process syncs with Dropbox and then somehow loses track of its uniqueness at some point, so when you do vagrant halt and vagrant up again, a second VM launches in Virtualbox and causes strangeness.

Totally unverified. And now that I'm writing this up without the book in front of me, I forget the setting that can be changed (I think) to move the .vagrant/ directory somewhere else.

All aside. I want to test VVV in Dropbox and see if we can clarify some behavior around it.

install imagick 2.2.0+ with Imagemagick 6.2.9+ for full WP_Image support.

Does anybody have issues with changing the host name that we use for VVV?

Right now it's precise32-dev, which is boring and not really effective. I'd like to change it to vvv, which is still boring but at least a bit more descriptive as well as shorter. Other suggestions welcome as well.

curl is currently installed on the server, but not available to php. Running:
apt-get install php5-curl fixes that, but we should do that automatically.

We should document a bunch of the custom and non custom files to make it easier for a new user to create additional sites whenever they want.

First off, I've found this to be an incredible resource! Thanks to everyone involved for your hard work in putting this together.

Secondly, I'm way over my head when it comes to server administration, so forgive me if this doesn't make complete sense. Best I can tell, mod_rewrite is not enabled with this setup which is resulting in some of my wordpress sites having issues with their URLs and properly loading page resources.

It's also preventing me from using the .htaccess tip found here to look for assets that aren't found on local by checking the coresponding path on production (last code snippet in the article): http://stevegrunwell.com/blog/keeping-wordpress-under-version-control-with-git

If someone more gifted in this area than myself could get mod_rewrite working I'd be very thankful.

There has been some discussion of this issue here and in issue #56.

During provisioning, when doing svn checkout I'm getting the following error:

svn: Can't move '/srv/www/wordpress-trunk/.svn/tmp/entries' to '/srv/www/wordpress-trunk/.svn/entries': Operation not permitted

This also happens for the unit tests checkout. The checkout fails, leaving an empty WordPress directory, which then causes subsequent provisioning commands to also fail.

This seems to be due to a bug with file permissions, either in VirtualBox, or Windows NTFS
https://www.virtualbox.org/ticket/5568

So there are a couple of workarounds for grabbing WP Trunk:

• Use svn export instead of checkout
• Use git clone https://github.com/WordPress/WordPress.git

However, this doesn't help for the unit tests, because the WP CLI command wp core init-tests has svn checkout built-in.

There's no need to copy (or having it at all) wp-config-sample.php from config directory, WP-Cli creates new config file from its .mustache template.

Hi again! I've really been enjoying the work you've put into writing this Vagrant and evangelizing it. There are some things it already does really well. Plus, it's inspiring me to improve it in various ways.

Which brings me to a question @tollmanz and I started discussing: What is the purpose of This Here Vagrant? An amazing WordPress development environment or something else?

I think it's a topic worth discussing and articulating in the readme, because it will strongly influence whether I try to contribute my "improvements" upstream, or maintain a fork (or something else).

For instance, in #53 I submitted a PR to display PHP errors by default. If this Vagrant is intended to be the totally awesome WP development vagrant, then I think that makes sense. If this Vagrant is intended to be used in production, then it doesn't make sense.

Does this make sense?

Related to this, it would also be worthwhile to identify the "best way" to extend this Vagrant in the same way WordPress has hooks and actions. Because I may want to launch my box in a slightly different way without having to maintain a fork.

Vagrant has been acting slow for the last week, and now it's breaking completely when trying to make remote requests from WordPress.

And this:

vagrant@precise32-dev:/srv/www/wordpress-trunk$ ping google.com
ping: unknown host google.com

Doing a vagrant halt and vagrant up seems to fix things. It may have be related to putting my MBA to sleep, and using Vagrant after its reawoken.

Anyone else run into this? Something we can account for?

I'm running my vm on an admittedly underpowered laptop. On one fairly php-heavy page, the page timed out after 60s having loaded maybe 20% of the generated content. (the same page loads ok on a 512mb server. ).

After poking around with fpm settings without result, I looked into switching to NFS shares, and found a startling benchmark - 5+ minutes vs 14s (http://docs-v1.vagrantup.com/v1/docs/nfs.html). Sure enough, when I got NFS working, my page loaded in around 10s (on first hit).

Only problem with that is, vagrant doesn't like the owner/permissions currently set when VVV shares /srv/www. I didn't fully understand the issue, so I just deleted the owner and permission arguments, and it works so I'm going with that...

Is there a reason not to use NFS shares?

How do you guys handle deployment? Would it be useful to include something like WP Stack in VVV?

It would make it easier for others to fork the project and submit pull requests against.

The wp can easily be aliased in bash_aliases

I was wondering why apt-get always gets a --force-yes argument.

From the apt-get man page:

Force yes. This is a dangerous option that will cause apt-get to continue without prompting
if it is doing something potentially harmful. It should not be used except in very special
situations. Using --force-yes can potentially destroy your system!

Since the minimum requirements for WordPress are 5.2.4, and since the vast majority of WordPress installs are still on PHP 5.2 followed by PHP 5.3, it is not very helpful that VVV comes with PHP 5.4.17RC1. In order to ensure broad compatibility in plugins and themes developed across the WordPress ecosystem, it's important that they be testable in the lowest version of PHP. It would be ideal if there could be some command to switch between PHP versions on the fly, or even better to assign different PHP versions to each site instance. I'm not sure what is feasible at the moment.

Running apt-get update every time the box is provisioned is fairly annoying. When the box is halted or suspended, there is no real reason to at all. Our previous attempts to stop it from running at all became annoying after a vagrant destroy as the source lists would be out of date when the packages were installed.

I think I would like to see the previous method - create a flag file that tells our provisioning to not run apt-get update - combined with something hooked into vagrant destroy or the power off state of the box that deletes the flag file so that apt-get update is run on the next provision.

Now that we have a method (see 0884815) for appending custom apt sources during provisioning, we should figure out what other packages we want to have later versions of in this.

The first change was the upping of SVN to 1.7.9 from 1.6.19. Another obvious change is probably nginx. Any others?

This used to avoid constant SQL imports, but we handle that differently now.

The Memcache daemon is set up to use 64 MB of RAM. We should consider bumping that to 128 MB so that sites with a lot of cache entries can be fully tested.

see #68

@jeremyfelt Did you want to experiment with those variable flags in the config file? We can work in a separate branch.

For context:

• Create a flags folder where files can be created with a specific file name to flag the skipping of a particular thing.
• Create a components folder for holding compartmentalized module scripts that act as "helper" scripts and install a specific thing. Ideally, this breaks the provision.sh script and breaks it down into modular files.

I think it would be worth just experimenting for now so we can see something that works and even try it if we'd like.

If running vagrant up after a vagrant halt, it would be cool to avoid all of the various apt-get statements entirely and just proceed with booting since the machine is already provisioned.

Unable to disable STRICT PHP Errors. Edited the php-custom.ini file and replaced the default error reporting with error_reporting = E_ALL & ~E_STRICT and restarted local server. Even vagrant destroyed and still not working. I already let Jeremy know and he will look into when he gets a chance. I will look into finding a temporary solution.

init-custom.sql.sample should specify IF NOT EXISTS on database creation.

I'm going to refactor a bunch of the README stuff before I merge vvvv-0.2 into master. Things are looking awesome from all angles right now, so I think we're ready to move on to v0.3.

Will have this completed by EOD

It's pretty annoying to have to take a file included by Ubuntu and reproduce it on our own just to make sure that the appends of our custom sources don't stack up on each other.

I'd like to find a way to use the defaults while also making sure that the sources in apt-source-append.list are used.

As more and more sites get added to a VVV instance, the PHP error log can quickly get overwhelmed with entries from all of the sites combined. So it would be ideal if each site got its own separate PHP log which could be tailed.

cf. 1fb1a47#commitcomment-3676483

We only have one flag left and it's for unit tests.

1. It seems pretty ridiculous to have a flags system for one thing.
2. It feels weird to include the mass of unit test stuff by default. The WP.com theme downloads can be unexpected and prohibitive on slow connections.

I'm starting to imagine a scenario where we include instructions that involve creating a directory www/wordpress-unit-tests and then running vagrant provision again to fill in what's needed if the WP unit tests are desired.

Thoughts?

Through the use of the /tmp/apt_update_run flag on the guest, we avoid running apt-get update on every up, reload or provision. It is only run on the initial up and after a destroy.

We should consider doing this for all packages, as this will lower the start up time even more and avoid sudden (albeit unlikely) changes to the dev environment during a normal work day.

It may even be worth wrapping almost the entire provisioning file in a check so only some local project stuff is modified.

Going to play with it throughout the week, may add it to the develop branch early so we can see how it feels.

There is still a bunch going on during the initial provisioning that can cause confusion. BIG RED ERRORS for things like packages not being installed.

There are some things we can do to silence output that should be done as much as possible. The final output should be mostly quiet and very instructive.

Don't know why this is happening just yet, but vagrant halt and vagrant up works, but if I do a vagrant reload, big output of errors. However, the vagrant still boots just fine. Here is the error, will reply if I figure out what this means at all.

[default] VM booted and ready for use!
[default] Setting hostname...
/Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/transport/packet_stream.rb:87:in next_packet': connection closed by remote host (Net::SSH::Disconnect) from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/transport/session.rb:172:inblock in poll_message'
from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/transport/session.rb:167:in loop' from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/transport/session.rb:167:inpoll_message'
from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/connection/session.rb:451:in dispatch_incoming_packets' from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/connection/session.rb:213:inpreprocess'
from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/connection/session.rb:197:in process' from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/connection/session.rb:161:inblock in loop'
from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/connection/session.rb:161:in loop' from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/connection/session.rb:161:inloop'
from /Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.6/lib/net/ssh/connection/channel.rb:269:in wait' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/communicators/ssh/communicator.rb:299:inshell_execute'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/communicators/ssh/communicator.rb:61:in block in execute' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/communicators/ssh/communicator.rb:139:inconnect'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/communicators/ssh/communicator.rb:60:in execute' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/communicators/ssh/communicator.rb:93:intest'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/guests/linux/guest.rb:23:in block in distro_dispatch' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/guests/linux/guest.rb:22:intap'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/guests/linux/guest.rb:22:in distro_dispatch' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/machine.rb:171:inguest'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/set_hostname.rb:21:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/forward_ports.rb:31:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/network.rb:105:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/clear_network_interfaces.rb:26:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/share_folders.rb:20:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/clear_shared_folders.rb:12:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/prepare_nfs_settings.rb:11:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/nfs.rb:28:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/prune_nfs_exports.rb:15:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:106:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/prepare_forwarded_port_collision_params.rb:30:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/env_set.rb:19:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/provision.rb:45:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:13:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/set_name.rb:35:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/clean_machine_folder.rb:17:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/check_accessible.rb:18:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:in block in run' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/util/busy.rb:19:inbusy'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:in run' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/call.rb:51:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:inblock in run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/util/busy.rb:19:in busy' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:inrun'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/call.rb:51:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:in block in run' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/util/busy.rb:19:inbusy'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:in run' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/call.rb:51:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/config_validate.rb:25:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/check_virtualbox.rb:17:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/call.rb:57:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/check_virtualbox.rb:17:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/config_validate.rb:25:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:inblock in run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/util/busy.rb:19:in busy' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:inrun'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builtin/call.rb:51:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/warden.rb:34:incall'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/builder.rb:109:in call' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:inblock in run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/util/busy.rb:19:in busy' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/action/runner.rb:61:inrun'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/machine.rb:129:in action' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/commands/reload/command.rb:29:inblock in execute'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/plugin/v2/command.rb:182:in block in with_target_vms' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/plugin/v2/command.rb:180:ineach'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/plugin/v2/command.rb:180:in with_target_vms' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/plugins/commands/reload/command.rb:28:inexecute'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/cli.rb:46:in execute' from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/lib/vagrant/environment.rb:408:incli'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.1.5/bin/vagrant:75:in <top (required)>' from /Applications/Vagrant/bin/../embedded/gems/bin/vagrant:23:inload'
from /Applications/Vagrant/bin/../embedded/gems/bin/vagrant:23:in `

I was chatting with @jeremyfelt about this yesterday, and may have convinced him, but opening up a Git issue for discussion for posterity sake.

I'd highly encourage you to collapse your 'develop' branch into master for the following advantages:

• Easier for forks of the repo to run and contribute to the current working version.
• Avoids pull requests against the wrong branch, and having to keep two branches in sync.
• Less redundant.

Tags are useful for the purpose of tagging stable releases, if your concern is offering a stable version for people to use in production.

Feature branches are useful for when you might be working on something beyond one commit. When done with a feature branch, you can then create a pull request against master for code review and final discussion.

The box name for VVV was set to std-precise32 back when we were first getting started with Vagrant. This is unfortunate as it seems to be pretty common for others to have left the box name alone when using the official precise32.box. Because of this, we may be causing those who have multiple Vagrant boxes to be downloading the same box twice under different names.

Before we hit a v1.0 point... does anyone take issue with moving the box name to precise32 so that we're better community members?

Referring to this line

At the end of the provisioning script, we output the visit http://192.168.50.4 line. This should change automatically depending on the IP that is setup. If VVV is forked off and the IP is changed, this line can become annoying, if not confusing.

Just started playing with VVV so apologies if this has been addressed - are you aware of this potential security issue with vagrant's default settings? - hashicorp/vagrant#1785

Getting PHP deprecated notices, when running commands like wp or phpunit on VM:

PHP Deprecated:  Comments starting with '#' are deprecated in /etc/php5/cli/conf.d/apc.ini on line 1 in Unknown on line 0

I think it was introduces with db989a2

The check for available Internet access is now done by pinging Google's secondary DNS server - 8.8.8.8. This just failed on me for the first time and I'm wondering if there's a better method we can use. I've switched to 8.8.4.4 locally and will probably push to the repo as it is the primary Google DNS server, but there's no promise that it will work.

Is there a global resource available that's made for this kind of thing?