Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change TLD for test sites #583

Closed
pento opened this issue Mar 1, 2015 · 54 comments
Closed

Change TLD for test sites #583

pento opened this issue Mar 1, 2015 · 54 comments

Comments

@pento
Copy link

@pento pento commented Mar 1, 2015

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
Copy link
Contributor

@westonruter westonruter commented Mar 1, 2015

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

@zamoose
Copy link
Contributor

@zamoose zamoose commented Mar 1, 2015

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
Copy link
Contributor

@michaelbeil michaelbeil commented Apr 6, 2015

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

@jeremyfelt jeremyfelt added this to the 1.x.x (Future Release) milestone Apr 12, 2015
@jeremyfelt
Copy link
Member

@jeremyfelt jeremyfelt commented Apr 12, 2015

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
Copy link
Member

@cfoellmann cfoellmann commented Apr 20, 2015

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 jeremyfelt modified the milestones: Next Release, Future Release Feb 21, 2016
@jeremyfelt
Copy link
Member

@jeremyfelt jeremyfelt commented Feb 21, 2016

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
Copy link

@raulillana raulillana commented Feb 21, 2016

Short is best. I would go for dot test.

@richardtape
Copy link

@richardtape richardtape commented Feb 21, 2016

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
Copy link
Member

@jeremyfelt jeremyfelt commented Feb 21, 2016

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

@johnbillion
Copy link

@johnbillion johnbillion commented Feb 21, 2016

.local

@morganestes
Copy link

@morganestes morganestes commented Feb 21, 2016

.test

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

@diddledan
Copy link
Contributor

@diddledan diddledan commented Feb 21, 2016

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
Copy link

@rmccue rmccue commented Feb 21, 2016

.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
Copy link
Member

@jeremyfelt jeremyfelt commented Feb 21, 2016

@rmccue
Copy link

@rmccue rmccue commented Feb 21, 2016

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
Copy link
Member

@cfoellmann cfoellmann commented Feb 21, 2016

.local providing zeroconf sounds excellent

@GaryJones
Copy link
Contributor

@GaryJones GaryJones commented Feb 22, 2016

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

@frozzare
Copy link

@frozzare frozzare commented Feb 22, 2016

.local

@ntwb
Copy link
Contributor

@ntwb ntwb commented Feb 22, 2016

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
Copy link

@iandunn iandunn commented Feb 22, 2016

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
Copy link

@mikesprague mikesprague commented Feb 22, 2016

.local

@benlk
Copy link

@benlk benlk commented Sep 21, 2017

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
Copy link
Member

@tomjn tomjn commented Sep 22, 2017

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:

screen shot 2017-09-22 at 17 35 07

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
Copy link

@rmurillo21 rmurillo21 commented Sep 22, 2017

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

@tomjn
Copy link
Member

@tomjn tomjn commented Sep 23, 2017

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

@grappler
Copy link

@grappler grappler commented Sep 23, 2017

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
Copy link

@fumikito fumikito commented Sep 23, 2017

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
Copy link

@rmurillo21 rmurillo21 commented Sep 23, 2017

@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
Copy link
Member

@tomjn tomjn commented Sep 24, 2017

.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
Copy link
Member

@tomjn tomjn commented Sep 24, 2017

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
Copy link
Member

@tomjn tomjn commented Sep 25, 2017

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
Copy link

@shakefu shakefu commented Oct 5, 2017

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
Copy link
Member

@tomjn tomjn commented Oct 5, 2017

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

@JJJ
Copy link
Contributor

@JJJ JJJ commented Nov 1, 2017

.wapuu

@tomjn
Copy link
Member

@tomjn tomjn commented Nov 3, 2017

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
Copy link

@lock lock bot commented Feb 22, 2020

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.

@lock lock bot locked and limited conversation to collaborators Feb 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet