If this has already been covered elsewhere I haven’t seen it. And while it’s probably fairly obvious this might be useful to have written up … for someone.
If you’re still using the .dev TLD for development you need to stop. And if your old sites still use it you need to update them. Especially in instances where you’re not using self-signed certificates for development.
vagrant up your development environment
vagrant ssh into the box
- Navigate to the current folder
- Use WP-CLI to take a backup
wp db export before-tld-change.sql
- And use it to do the search/replace of the DB
wp search-replace //example.dev //example.test (add
--dry-run if you want to test it first)
- Exit the SSH session
trellis/group_vars/development/wordpress_sites.yml to use your new
vagrant provision to re-build your development box. This will not effect your existing database or uploads.
vagrant up again to rewrite your
/etc/hosts/ with the new domain
Given that Trellis Vagrant VMs typically use the Vagrant Host Manager plugin, people may want to also run
vagrant hostmanager to update their
/etc/hosts. Then the local browser will serve the revised domain.
I thought the
vagrant provision would cover that step, or
I brought it up because I remembered being surprised one time that
vagrant reload didn’t refresh the hosts file (like it refreshes the sync dirs; discussion).
In my tests just now, hosts are not updated by
vagrant reload nor by
vagrant provision. However, hosts are refreshed by
vagrant up. I wouldn’t have thought to run
vagrant up for a VM that is already running.
So, I guess a
vagrant up or
vagrant hostmanager would do the job for updating hosts.
Again, thanks for laying out these useful steps.
You’re so right … just came back to follow my own guide here and I should’ve included to run
vagrant up again at the end. Have updated the OP
I needed to do this on one of my sites, and was too afraid to ask, too lazy to research. So thanks man!