Domains: Domain Connection flow can accept unregistered domains

[supernovia]

Quick summary

I've seen a few cases where people used unregistered domains with Domain Connection and Redirection tools:

Steps to reproduce

1. Start with a site that has an upgrade so you can connect a domain
2. Go to Upgrades > Domains and use the toggle up top to "Use a domain I own"
3. Type in domain name that has not been registered (I couldn't duplicate with a .com domain but I did see the problem with an .se domain)
4. Notice you'll be offered next steps for connecting the domain, even if it is not registered

What you expected to happen

The system should say the domain is not registered

What actually happened

It allows the user to "connect" a non-existant domain

Impact

Some (< 50%)

Available workarounds?

Yes, difficult to implement

If the above answer is "Yes...", outline the workaround.

The workaround is to register the domain or fix the typo, but users don't always pick up on that. Also they may not be able to register the domain if it's already "mapped".

Platform (Simple and/or Atomic)

No response

Logs or notes

No response

[supernovia]

9012388-zd-a8c

[github-actions[bot]]

Support References

This comment is automatically generated. Please do not edit it.

• [ ] 9012388-zen
• [ ] 8954298-zen

[supernovia]

I just realized that in the other case, we allowed a redirect (not a connection) for a non-existent .com domain, but I'll watch for other cases: 8954298-zd-a8c

Debating whether to make this a separate issue but for now, I've confirmed it:

[Aurorum]

Type in domain name that has not been registered (I couldn't duplicate with a .com domain but I did see the problem with an .se domain)

I think the problem here is for domain TLDs which aren't supported on WordPress.com. The API returns this:

{
    "domain_name": "testing2433242323.se",
    "tld": "se",
    "status": "tld_not_supported",
    "mappable": "mappable",
    "supports_privacy": false,
    "root_domain_provider": "unknown",
    "ownership_verification_type": "no_verification_required"
}

Whereas for TLDs that are supported, the status is available (ie. not registered). I think the endpoint might need another option added to highlight when a TLD isn't supported and also still available. Calypso also seems to expect something along those lines:

https://github.com/Automattic/wp-calypso/blob/61065ded6eb63b67584ddf2c77d12e34debe6145/client/lib/domains/constants.js#L63

But that status isn't provided - it's just tld_not_supported and not tld_not_supported_and_domain_not_available.

[gavande1]

I am on groundskeeping rotation this week. I could replicate the issue since it's already on the Nomado team's board, I will mark this issue as triaged.

[StevenPartridge]

Here's the two diffs that introduced the issue:

• https://github.com/Automattic/wp-calypso/pull/46411
• D50792-code

It looks like removing that status had the side-effect outlined here. I believe the best path forward is to re-introduce the status and test each flow that it might interact with.

[StevenPartridge]

D166359-code open, still in progress. Tests seem like they are not working as expected, printing out the results of $is_available and $allowed_to_register for example are both null, when they should be mocked.

[StevenPartridge]

Left a question in #domains-dev p1731984342107809-slack-C0BNMNMNG

Going to start another ticket while I figure this out :)