Wp-calypso: Signup: reserved WordPress.com site addresses can't be registered by the user that signed up with it originally

[scruffian]

When a user creates an account and doesn't immediately create a site with the matching site address (the same *.wordpress.com subdomain as their username), the matching site address is reserved so only that user can create a site at that address in the future. With the current signup process at wordpress.com/start, users can't create that site at the matching site address.

I tested by creating a new username-only account with the username rachelmcroberts20151007.

When I returned to wordpress.com/start to create a new site, I got to the "Let's find a domain" step, entered rachelmcroberts20151007, and wasn't given rachelmcroberts20151007.wordpress.com as an option:

Entering rachelmcroberts20151007.wordpress.com on that step gives the error, "Sorry but rachelmcroberts20151007.wordpress.com does not appear to be a valid domain name."

This step should check to see if the site address is reserved for the user trying to create it, and allow it in that case. I couldn't find any workaround to create the desired site.

[rachelmcr]

Just want to note this workaround for the issue here, for visibility:

The user can be given a link to the old signup page, which will work to create the new site: https://signup.wordpress.com/signup/?new=WPCOM_SUBDOMAIN

[lancewillett]

I looked at this today from both user flow and experience as well as the technical side.

Flow: a user comes to register the same WP.com site as their username — the suggestions in the site name step should show that choice first if it's not already a valid WP.com site. That's before you even type it in! Just show it as the first choice.

Technical side: I see two possible changes to help with this right away.

1) Suggest this site first in the WordPress.com suggestions returned by the API. Add the matching site for the current user's username first in the list if it's not yet set up as a WordPress.com site. Before the variations like 1234blog and 1234site.

See get_wordpress_domains_from_string() and wpmu_validate_blog_signup() — I'm fairly certain a call to is-available in the REST API for a site, when logged in as the user with the same username as the reserved WP.com subdomain, would be successful. It can't be completed in the current flow because we don't show it in the suggestions, and when a user types it directly we treat it like a domain name (see point 2).

The API has methods to check if a site slug is a valid WordPress.com address (see is_valid( 'site' )) in the is-available functions.php file.

2) Don't treat someone typing in a WordPress.com URL into the form like a normal domain name. We currently validate them in the same way as normal domains via the WP.com Domains API; instead the WP.com addresses should be checked differently from a normal domain name validation.

[lancewillett]

Probably the simplest approach is just inject the given WordPress.com address into the suggestions list.

[lancewillett]

Here's one way of thinking of the logic for injecting the suggestion into the list.

1. As the user arrives at this step in the signup flow... the view should call an API endpoint to check Is there a matching WordPress.com site for this username?
2. Yes, it exists already, ignore.
3. No! It's not registered yet on WordPress.com. OK, next check. Can the current user create this WordPress.com site? Do they have that capability? No, they can't. Exit.
4. Yes, in fact, it matches their username exactly. Let's show it in the suggestions list at the top so they can choose it.

I’m pretty sure once the given WordPress.com site address is in the list, the actual site creation behind the scenes should work as expected as long as the username and site name match.

[bisko]

This requires an API change, tracked on D1854-code.

[lancewillett]

After applying API change from @bisko this works really nicely!

I do have one further comment, though — simply a UX improvement.

First scenario, just entering the username to get a match — works great. In this test I registered lancebisertest1 as a user-only account, then tried to create the matching WordPress.com site for it.

Perfect.

Now, second case which we can improve if time allows — typing in the exact URL like lancebisertest1.wordpress.com causes two messages, one success and one failure.

If we could avoid the red warning here it'd be a nice UX change to avoid confusing WordPress.com users when it is actually OK to proceed here.

[lancewillett]

Moved the last UX piece to a new issue so we can fix just this main problem now and polish the UX messaging separately: #5461.

[bisko]

Fixed in r136098-wpcom.