Change TLD for test sites

[pento]

As Google has applied for control of the .dev TLD, there's the potential for all sorts of weirdness to occur if their application is accepted.

Per RFC 2608, Section 2, .test, .example, .invalid and .localhost are the only TLDs guaranteed to never be allocated.

[westonruter]

.localhost seems particularly appropriate among these options. But what about .local?

[zamoose]

That has too many overloaded meanings in a Bonjour environment. Unless specifically going for such a la VIP QuickStart, it may be more trouble than it's worth.

Doug Stewart

On Feb 28, 2015, at 9:00 PM, Weston Ruter notifications@github.com wrote:

.localhost seems particularly appropriate among these options. But what about .local?

—
Reply to this email directly or view it on GitHub.

[michaelbeil]

.test would seem to be the better of the options.

[jeremyfelt]

I'm up for .test as well. We can probably introduce the new TLD in the configs while continuing to support old .dev installations.

[cfoellmann]

I would vote for .localhost since it would make the most sense to me.
.local can not be used because it would clash with directory and other services.

We need to reach some kind of consensus here and can add the tld to the configs of the sites while keeping the current domain endings for the time being.

[jeremyfelt]

Ok, feedback time.

Options:

• .localhost
• .test
• .local

I excluded .example and .invalid because they don't seem right. Decisions. :)

Please leave a comment, this is super serious stuff.

[raulillana]

Short is best. I would go for dot test.

[richardtape]

Edit (after finding out that local is avail.): Could it not be a choice on provision? If not, I'd prefer .local over the other options

[jeremyfelt]

Per @rmccue, .local is a valid option too. IMO, better than .localhost. https://twitter.com/rmccue/status/701526969008062465

[johnbillion]

.local

[morganestes]

.test

I'd like to avoid potential problems with Apple and .local.

[lucyllewy]

if we opt for .local, can I suggest that some work be put towards setting-up avahi/zeroconf/mdns/bonjour support so that we don't need to utilise the hostsupdater plugin (which doesn't seem to be working for me atm)

[rmccue]

.local is super neat, since it's very easy to use with Avahi. Just install avahi-daemon via apt-get, and you're basically done. No messing about with hosts files, no installing vagrant-hostsmanager/etc, just done. Works automatically on all OSX systems, most Linux desktops automatically (or install avahi-dnsconfd on Ubuntu), and Windows systems with Bonjour installed (i.e. iTunes, Bonjour Print Services, Adobe CS3+ installed, or install manually. (Check the Chassis instructions.)

That is: intentionally use Zeroconf/Avahi. You can also use the dbus interface to avahi to automatically add subdomains if you want, although it's tricky.

[jeremyfelt]

Other .local reading material (I haven't parsed it yet): http://www.justincarmony.com/blog/2011/07/27/mac-os-x-lion-etc-hosts-bugs-and-dns-resolution/

[rmccue]

Other .local reading material (I haven't parsed it yet):

This stuff only applies if you're using the hosts file, by the way. Zeroconf itself is pretty flawless (although Avahi not so much).

[cfoellmann]

.local providing zeroconf sounds excellent

[GaryJones]

Not .test. Local sites are not necessarily test sites.

[frozzare]

.local

[ntwb]

Today I learned statistics for the L root name DNS server operated by ICANN

"As of August 14, 2015, that server has received approximately 1331 .local queries per second, third in frequency after .com (4355 queries per second), and .net (2481 queries per second)"

[iandunn]

The anal-retentive perfectionist in my head strongly prefers .localhost over .local, since it's more descriptive, but if .local makes configuration easier and removes a point of failure -- especially given agiledivider/vagrant-hostsupdater#92 (cc @diddledan) -- then that's more important.

I agree with Gary that .test doesn't really describe what VVV sites are typically used for.

[mikesprague]

.local

[benlk]

Copying in @leewillis77's comment from Laravel's valet, which has the same problem: laravel/valet#436 (comment)

Just for reference .localhost is defined to have some non-standard behaviour. Of relevance, it's defined to always resolve to the local loopback address, so using it precludes you from mapping anything under the TLD to an address other than 127.0.0.1. The TLD also specifies (same RFC) that any DNS request other than an address query should fail which again may cause issues somewhere (think querying for TXT, or MX records etc.)

.test would seem more flexible as it's defined to act "normally".

[tomjn]

I've created PR's for the dashboard and the default stable WP install. I've also added warnings on the new dashboard for sites that have .dev TLD's so that people are aware:

New installs will get the .test domains, and existing installs will accept them but WP internally will have .dev in its DB, I'm evaluating options as to wether a search replace will work, or if it's as simple as just changing the site URL. I don't want to break everybodies local environments doing the change

[rmurillo21]

We use a WP site URL migration script. Would that be useful here to migrate an install to a new TLD?

[tomjn]

@rmurillo21 a WP CLI search replace should be enough, it's more the risk involved that's concerning

[grappler]

Could we add some documentation what is required to migrate to .test? Even just adding a comment that one needs to do a search and replace on the DB would help.

[fumikito]

As @cgrymala mentioned, I also don't recommend .local domain for default. In some networks like a big enterprise's intranet, you may be redirect to unknown IIS server. It requires hard googling.

[rmurillo21]

@grappler I think the process is still being tested, to determine best route.

I did a quick search for local.wordpress.dev in project folders, and a global search/replace to local.wordpress.test looks pretty straight forward, with no unintended replacements.

For the DB, others have suggested a DB level search/replace:
wp search-replace 'local.wordpress.dev' 'local.wordpress.test'

Follow that by a vagrant reload --provision

This should work but I have not yet tested. YMMV - Just wanted to outline a possible process.

For my custom sites, I have moved to the .test TLD. All good.

NOTE: The codex also suggests these two options for changing site url:

wp option update home 'http://example.com'
wp option update siteurl 'http://example.com'

[tomjn]

.test is the way forward, and the PR's so far stick to that, dashboard works well on .test here, and .local and .localhost were also added for good measure, but all references to the dashboard use .test as the preferred TLD

@grappler I'd have implemented automated migration but I was hoping other people would advise on the best approach to migrating, be it:

• an automated full search replace based migration in the provisioner ( would do the trick, some potential risk of data damage or accidental changes )
• a prompt in the dashboard with the CLI command ( safest option, but potentially user hostile )
• switching the site URL via wp option ( results in a mixture of URLs, has the least risk )

This also doesn't solve the issue of people who used the custom site template and chose a .dev domain.

For now, I see the PR's as mergeable without the automated migration, as those can be implemented via follow up PR's

As for documentation, I'm happy for a PR with a stub to be created, I'd prefer to have Varying-Vagrant-Vagrants/varyingvagrantvagrants.org#23 merged first though to avoid conflicts and make sure no editorial work is needed so it makes sense in the new format

[tomjn]

PR's exist for all the relevant repos to set the new default to .test, once those are approved I'll work on automatic migration PR's for the 2 bundled site provisioners

[tomjn]

All the relevant PR's have been merged save for Varying-Vagrant-Vagrants/custom-site-template#6 so brand new installs of VVV should be impervious to this issue

I'm going to vote against adding automated migration to the custom site template repo as it's a lot more generic and the risk is substantially higher, but the 2 defaults could use it. I'll work on follow up PR's later this week

[shakefu]

FWIW I just installed on OS X using VirtualBox 5.1.28, Vagrant 2.0.0, and the VVV master (commit SHA 70e9bc4), and the install is broken - the Vagrant /etc/hosts entry is for "local.wordpress.dev" but all the asset requests go to "local.wordpress.test" which cannot be found. Manually adding the entry for the ".test" domain fixed this.

Let me know if you'd like me to open a separate issue for this (and if this is the correct repository for doing so.)

[tomjn]

You should switch to the develop branch, it has a significant number of fixes, as well as the .test changes

[JJJ]

.wapuu

[tomjn]

I'm going to close this out. Automatically moving everyones existing sites from .dev to .test is a non-starter as there's too many things that can go wrong, so we're going to leave them intact and make sure new things run off of the .test TLD

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.