VVV: New Install Not Working on Multiple Machines - PHP 7.2 Issue

That PR got merged into develop, I think all is good, but can you test?

For existing users, a note before testing

Any database you have inside the VM will be destroyed when you update, so run vagrant up but don’t provision, and run the DB backup script. This runs on vagrant halt so all you would need to do is run that command and it’ll say backing up databases. Otherwise PHPMyAdmin and the MySQL server are accessible via the usual means.

Of course if you’re not bothered about the data inside the DB, you can ##proceed

Testing

1. First, you’ll need the latest develop branch, so do a git pull, or clone the repo if you’re starting from scratch
2. halt the VM if it’s running with vagrant halt
3. vagrant destroy
4. vagrant up --provision

At this point it should download the new box, then proceed to provision. Wait until the end, then visit http://vvv.test and see if the dashboard, sites, and the tools work as expected. The goal is that the end result should look and work exactly the same, but, on a new VM. I’m not so concerned about performance differences, mainly that all is working and functional.

Thanks for being patient while we worked through this 😃

@DrewAPicture @christopherjanzen @rogeliozarate @EricRihlmann @benedicksahagun @Mte90 @benlumia007

Ensuring it doesn’t happen again

Rather than using the official Ubuntu 18 box, the lovely @LoreleiAurora built a custom Ubuntu 18 box, and she removed everything that was unnecessary. The success of having our own box means we now have far greater control, but it also means VVV 4 will come bundled with everything the core provisioner sets up out of the box.

In future, for most users only site provisioners will be run, and updating VVV will be as simple as:

vagrant box update
vagrant destroy
vagrant up --provision

This means that spinning up a new site will also be significantly faster, as the bulk of the provisioning will no longer happen.

In the event that provisioning new boxes is broken, things would be fine, we’d just use the last working box that was built

Additionally, VVV 3 uses a mounted folder for the database directory, so it survives a vagrant destroy. Tearing down and spinning up a new instance shouldn’t cause data loss as a result. Figuring out how to migrate people to that without data loss has been a long standing blocker to moving to Ubuntu 18, but the 14 EOL necessitated it

It seems some of the packages may not have been mirrored, working on it

Thank you for fixing this over the weekend. All working again now!

@tomjn Thanks, I can confirm that a new installation is working once again.

@tomjn Thanks for the detailed reply, I did not know about the --local flag.

And thanks for fixing VVV quickly. 😃

This fix the problem with tideways https://github.com/Varying-Vagrant-Vagrants/vvv-utilities/pull/26

@tomjn I’m up and running after this update!

Thanks @tomjn I can confirm that issue is still present even after recreating the machine.