I have 55 local copies of live projects running in my XAMPP based localhost.Each has thier own www.foobar.xamp local domain name in the hosts file. There are other projects I have not set up a local domain for.

Some of them are older, current, and in-progress versions of the same project and I need to be able to visit them simultaneously at their local domain instead of swapping them in and out of a single port number like http://localhost:8080

Over a dozen of them use the same core php files and when testing for bugs in one I need to be able to quickly open at least 6 other projects to test the same bug or bugfix in all of those as well.

My php version is 5.5.19 because it is the closest version I could find to the versions in use on the live servers where most of the projects live. Those live servers use: 5.3.15, 5.3.26, 5.4.44. It is very likely that those servers will never be upgraded.

Three projects are on a server using 5.6.31. It is possible that 3 more will be moved to that server next year. It is also possible that at least 1 project next year will be migrated to a php7 server and another one built from scratch on a php7 server. But at the moment 90% of my income is from maintaining old projects on these old servers.

I want to start using modern tools like composer and npm and homebrew cask. But the very old version of XAMPP I have installed at the moment has added something to my terminal environment named HEAD that is definitely not the HEAD script that many other terminal things like homebrew expect.

So to avoid these kinds of problem entirely I'd like to completely remove XAMPP from my OSX terminal environment, but I do not know the best way to replace it with something that would allow me to just as easily run all projects simultaneously with their own local domain name. I also think it would be best if I could somehow stick to an older version of php or preferably the exact same php version used by the live servers most of these projects live on.

I have not updated to the latest version of OSX yet because I heard there was a problem with it an Laravel Homestead and I was considering trying to move all of the projects into a Homestead VM.

The thing I don't like about my experience with Homestead so far is that I've accidentally destroyed the VM on multiple occassions without first remembering to export all of my databases. I think I would have to set up a 2nd VM that I never destroy in which to store all my databases and then modify the local env config of every project to connect to that VM's mysql service when running locally. The thought of doing that depresses me.

This sounds like the perfect solution for something like Vagrant. Imagine having to maintain two legacy projects relying on two different versions of the same PEAR package, for example. Vagrant makes that trivial. Vagrant will allow you to spin of multiple virtual machines with different versions of PHP (or any software, really) without polluting your local machine. You will still need to maintain a local /etc/hosts file to resolve all the domain names but that's pretty minor.

Laravel Homestead, to the best of my knowledge, uses Vagrant under the hood, and can be an option if you don't want to have to install and configure web servers, DB servers, and the like, but the reality is you'd likely need to do that in a production environment anyway and getting to choose your own base box and set of packages gives you better flexibility.

For the database conundrum, well, I'm not sure I have any concrete solutions. I am generally pretty slow to call vagrant destroy, so it isn't a problem I have really encountered. Unless you have removed the vagrant files, though, that should all be recoverable. Having a dedicated VM that holds all your databases makes it less likely that you will accidentally delete it, but it will make it more catastrophic if you do, in addition to just generally slowing down your sites (calling out to DB over HTTP vs. Unix socket)

How would that work if you need to run several projects at the same time (like thinsoldier needs), network setup wise? Would projectA.xamp and projectB.xamp point to different IPs, where different vagrant boxes would be running? Are vagrant box IPs persistent?

Would projectA.xamp and projectB.xamp point to different IPs, where different vagrant boxes would be running?

They could. Depends on the needs of the project. You can run multiple projects on the same box if they have the same requirements for PHP/Apache/etc versions, and you can run multiple boxes with multiple different configurations. Each box gets its IP configured in its Vagrantfile and then written to your /etc/hosts file.

# All Vagrant configuration is done below. The "2" in Vagrant.configure# configures the configuration version (we support older styles for# backwards compatibility). Please don't change it unless you know what# you're doing.
Vagrant.configure(2)do|config|# The most common configuration options are documented and commented below.# For a complete reference, please see the online documentation at# https://docs.vagrantup.com.

# Configuration for both Project Apples and Project Pears below. Both code bases can# easily be run off the same virtual machine. Comment/uncomment sections as# required. Note that Vagrant will complain if you try to start the VM with a# synced folder specified but not present
config.vm.synced_folder"./apples/", "/var/www/apples.com/"

Thanks. I've got an Ubuntu LTS vagrant box now. I got someone to make provisioning scripts that give it the legacy php/mysql/apache versions I need.

But they said something about needing to snapshot the box because someday I'll do `vagrant up` and vitrualbox or ubuntu may decide to update a bunch of stuff within the box and I'll be stuck with versions of php/mysql/apache that no longer match my desired versions.

Do you have any idea what they are talking about? Is there any way to prevent that from happening?

Ubuntu updating itself is not something I've encountered. Updating VirtualBox can cause issues when your Vagrant box is pinned to a specific version of Virtual Box. That said, I don't remember it being difficult to resolve. Configuring your VM and exporting a base box might not be a bad idea. As for the snapshot, could this person have been referring to the functionality within Virtual Box itself? This is not something I have had to worry about in the years I've been using Vagrant.

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum