.dev URLs and URL editing

[socki03]

Apparently, in an upcoming Chrome update, they'll start forcing .dev URLs to HTTPS, which will end up causing a few headaches for people.

I've been trying to figure out how to use vv to change the URL created on initial vv create, but haven't come across a way to do it yet. I know that I'll have to go search-replace the database separately, but I can't get Vagrant to accept my changes to the two nginx conf files I've found with my .dev URLs.

So, two questions arise from this:

1. Is there an ability to change the URL through VV, or through another route?
2. Are we going to get an update where the default wordpress installs and future default installs are not setup at .dev? (This one doesn't need to be answered, just more something to think about).

Thanks!

[tomjn]

Doesn't look like it, but you shouldn't need vv to change this, and you shouldn't be using vv with VVV 2+ it doesn't fully support it.

Instead, add the new .test host to your site in vvv-custom.yml, reprovision, then do a WP CLI search replace to change the .dev to .test in the database

[cywtf]

Thanks so much @tomjn for this info. I didn't know about VVV 2 and looking at it now, it looks fantastic. There's no need to use vv anymore for me.

[gleatherman]

Is there a step-by-step anywhere on how to migrate VV created sites from VVV 1.0 to VVV 2.0? I am having a devil of a time getting it to work, particularly since I also need to change my .dev urls to .test . I've gone through VVV 2.0 migration and .dev docs but cannot get it to work. I guess I'll have to create a new VVV site and just re-add the files and re-import the database?

[tomjn]

@gleatherman there's https://varyingvagrantvagrants.org/docs/en-US/troubleshooting/vv/ but it's not exactly a step by step guide. vv doesn't create sites the way it's supposed to, even on VVV 1.

E.g. in VVV 1 you had an nginx file that VVV would copy into the correct place, but vv appears to go into the VM and manually place the file directly.

Remember, at any point in VVV 1 and 2, you should be able to take a database backup, throw away the virtual machine completely, then reprovision. You might have to restore the DB but your code should remain, and VVV should have configured everything just as it was before based on your site. vv breaks this, and always has.

I expect the part you're having the most problems with is the nginx configs. Even if you create a site the VVV 2 way so it picks up the folder for your vv site, there'll be no nginx config for the provisioner to install. You can either make one then reprovision by copying from the custom site template and adjusting to your own needs, or take the one that vv created and move it to provision/vvv-nginx.conf in your site, but that will involve going inside the VM via vagrant ssh and copying the file. VVV maps the main VVV folder on to /vagrant though so you can do a file copy rather than copy and pasting text in a terminal

As an aside, to get vv working with VVV 2 properly ( or even to get it working with VVV 1 the right way ), would require a complete rewrite. It could be made to insert the necessary stuff into the sites section of the config, but that would never fix existing sites. It also means all the same pain again should the provisioner ever change. It also means you could be facing ngnx problems every other week when VVV 3 comes out

My current favoured option is to have a JS powered form in the dashboard underneath the sites list that asks you questions then modifies the config for you, and tells you to reprovision, so there's no config editing required. That should be easier than using vv to create sites. Anybody who needs to automate can just use sed to insert a snippet of YAML just after the sites: line then reprovision

[hobbsy]

if you want your .dev sites to work on https you can click anywhere onscreen and type the phrase 'badidea' to skip the Chrome warning. Probably not a good long-term solution but this easter egg will get you up and running.