Wp-calypso: Too easy to accidentally create a duplicate site

[gwwar]

Update 4/1 (@gwwar):

Implementing a siteless checkout (making sure we move site creation after checkout ) is a large project but also has a lot of other benefits like eliminating wait times). Our payments team may pick that up in the future, but not in the near term.

With that in mind, we can still explore reducing duplicate sites, but likely this may involve a few approaches with highlighting an existing site during site creation maybe during the domain step. Note that we've ruled out changing back behavior as an option.

The Issue

To reproduce:

1. Visit WordPress.com/start and follow the site creation flow and pick a plan.
2. Click on the back button on the checkout page
3. Continue with the site building flow

| Checkout | Back Takes us To Vertical Segment | subdomain taken so autogenerate | We create a site |
| ------------- | ------------- |------------- |------------- |
| | | | |

Expected:
We create one site

Actual
We create two sites

After trying smaller fixes, we're exploring a siteless checkout flow in:
#39704 and D39598-code

Originally reported by @tijosh and @davipontesblog paObgF-JO-p2

[gwwar]

I think one option would be to simply override back on the checkout page and instead link to https://wordpress.com/plans/<siteslug> as the intent is likely to pick a different plan.

@shaunandrews and @davemart-in suggest the following, though there would be some thinking to when this is displayed. (eg only for single site owner, or newly created site?)

paObgF-JO-p2

[amamujee]

I think one option would be to simply override back on the checkout page and instead link to https://wordpress.com/plans/ as the intent is likely to pick a different plan.

I like the simplicity and speed of this solution and would go with this unless there are good reasons I cant think of to go with the options that Dave and Shaun present.

[gwwar]

Thanks @amamujee. @Automattic/manage this one is up for grabs!

[gwwar]

The history api had some browser differences so we'll need to try the alternative.

[millerf]

@amamujee @gwwar Maybe we should also add a "back" button on the checkout for this particular case, that would link to https://wordpress.com/plans/<siteslug>, therefore preventing the users to use the browser's back button?

Or do you think it would distract the user from the payment workflow?

[klimeryk]

Alternative solution would be to use the siteless checkout that's already implemented and in use for the wordpress.com/domains flow:

• Go to wordpress.com/domains while logged in
• Select any random domain name
• Pick “Just buy a domain”
• Notice the URL: https://wordpress.com/checkout/no-site?signup=1

Now, remove the item from checkout or navigate away - notice that no site has been created. I'm sure it won't be as easy as just switching to this version of checkout for onboarding, but it seems like it'd be the fix for the root issue here: a site is created before the user finalizes checkout.

The https://github.com/Automattic/wp-calypso/issues/39424#issuecomment-585503572 mentioned above would also improve the situation - but I imagine some users will still get confused what they want to do ("manage my existing site? no, I did not finish setting it up, I want a new one") and end up with duplicated sites anyway.

[Aurorum]

@shaunandrews and @davemart-in suggest the following, though there would be some thinking to when this is displayed. (eg only for single site owner, or newly created site?)

I think this would be ideal because it would also take care of all the other ways in which a site is accidentally created, such as #27932, where there's an ongoing struggle to find a solution to.

[mmtr]

Alternative solution would be to use the siteless checkout

I think there is one big difference though. Siteless products don't require a site to be purchased, but plans as they're built in WP.com right now do need a site before they are purchased.

In order to be able to create a site after the checkout, it'd be necessary to refactor a huge amount of code so plans can be purchased before sites are created.

[mmtr]

The history api had some browser differences so we'll need to try the alternative.

I tried the simple back approach again in https://github.com/Automattic/wp-calypso/pull/39487 using @millerf's idea of doing an actual redirect rather than overriding the history.

[klimeryk]

I think there is one big difference though. Siteless products don't require a site to be purchased, but plans as they're built in WP.com right now do need a site before they are purchased.

I have not looked into how this code achieves this, but I can assure you that domains are not siteless - they require being tied to a blog like any other purchase. I'd guess the site is created as part of checkout steps (once the user submits payment information), before the upgrades are provisioned.

Edit: I've looked into it and I don't see anything especially domains-specific about it. It's been written to create a "domain-only" blog, but that's a blog with one extra option, nothing special about it. And as I thought, the site is created before the upgrades are provisioned. Left a comment on the parent P2 post with more internal details.

[mmtr]

Thanks @klimeryk, that looks promising. I'll take a further look to that approach and see if we can come up with a solution built on top of the siteless checkouts.

[klimeryk]

@mmtr As mentioned on the P2 post, I'm more than happy to help - pair programming, code reviews, brainstorming, you name it :)

[rralian]

Ideally we wouldn't create the site until _after_ checkout. So I think it would be useful to think through _why_ we create a site so early in the process. I believe it's because we need the site created in order to provision any possible upgrades. And in the case of domains we want to reserve the domain for the site so it's not taken by someone else between the time it's selected and the time it's purchased. But there has to be a better way to reserve the domain.

It may not be a quick fix, but I think the right solution is to work towards a re-ordering of the necessary back-end events through the signup flow. Neutron will be working on a project to better manage events in the checkout flow that may be able to help with this issue.

[davipontesblog]

And in the case of domains we want to reserve the domain for the site so it's not taken by someone else between the time it's selected and the time it's purchased. But there has to be a better way to reserve the domain.

True! As @klimeryk mentioned we already have this functionality in domain-only, siteless accounts - so it is possible. We might be able to pull code from that and implement here.

[mmtr]

We might be able to pull code from that and implement here.

Yup, that's what we're exploring in https://github.com/Automattic/wp-calypso/pull/39704 and D39598-code

[gwwar]

Updated the summary to reflect that we're currently exploring siteless checkout 👍

[DavidRothstein]

Siteless checkout seems like a pretty big change... And are we even sure that it fully fixes the duplicate site problem? When I was looking through some of the internal P2 discussions, I thought I saw some examples of other ways that users with a free site could accidentally create a duplicate site (by visiting https://wordpress.com/pricing and trying to purchase through there; by clicking "Add new site" when they were actually trying to add a domain; etc.). I don't know how common those are, but they wouldn't be fixed by siteless checkout at all.

Would it make more sense to go with a simpler, targeted fix, at least to start? For example, if a user is on the domain selection screen and types example or example.com (or similar), and if that user is already the owner of example.wördpress.com, examplecom.wördpress.com or similar, couldn't we nudge them (or even force them) to upgrade their existing site at that point, rather than creating a new one? I thought I saw some suggestions similar to that idea in one of the internal P2 discussions also, but not sure what happened to the idea after that.

[gwwar]

And are we even sure that it fully fixes the duplicate site problem?

@DavidRothstein It won't fully fix the problem (as there are other ways for folks to get lost), but this also doesn't fit any mental models for how this should work and my first reflex on hitting that checkout page might be back to look at other plans. If it's possible to delay site creation until after checkout we should look into it, even though there's a good deal of technical work here.

[rralian]

@amamujee @gwwar Maybe we should also add a "back" button on the checkout for this particular case, that would link to https://wordpress.com/plans/, therefore preventing the users to use the browser's back button?

@millerf @gwwar I don't think we should ever try to circumvent the browser's back/forward buttons. Supporting it directly should always be our expectation. I think users are going back/forth within our signup flow much more often than we expect, and we should work towards making that a well-supported experience.

[millerf]

@rralian Although I do agree, the "site creation flow" is already full of "back" buttons 🤷🏻‍♂️

[gwwar]

@automattic/manage is pausing on this for now due to size, so we can help close out some smaller issues before circling back. If folks are interested in helping move this forward, feel free to assign yourself. We'd still be happy to help with reviews.

[rralian]

@rralian Although I do agree, the "site creation flow" is already full of "back" buttons 🤷🏻‍♂️

Yep, I know. We have this "back" button issue in lots of places. It's a somewhat recent realization for me through our checkout redesign that we're not accounting for how often people will navigate back-and-forth within our flows. So I'm suggesting we develop/design with this in mind going forward. This github issue was just a good place to start that advocacy. :-)

If folks are interested in helping move this forward, feel free to assign yourself. We'd still be happy to help with reviews.

Thanks @gwwar I've chatted with @kanishkdudeja and we want to kick the tires a bit before committing, but we may pick this up. Will confirm tomorrow.

[GeoJunkie]

Caused confusion in 19637778-hc

[davemart-in]

@johnHackworth is there another issue for this that you are aware of? I thought this was being addressed in Gutenboarding.