Studio: Update signup URL for creating free account

[katinthehatsite]

Related issues

• Fixes STU-748

Proposed Changes

When the user clicks on Create free account link, for example, from Previews tab, they are currently brought to the login screen for Studio and not to the Sign up screen. This PR ensures that they are brought to the sign up screen:

Testing Instructions

• Pull the changes from this branch
• Make sure that you are logged out on WP.com and logged out from your account in Studio
• Navigate to Previews tab
• Click on Create free account
• Confirm that you are brought to the sign up page you see on the screenshot

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[epeicher]

Thanks Kat for improving this! I have tested it, and I am redirected to the Sign up page when I am logged-out of WordPress.com as expected ✅, but I am redirected to the Log in page when I am logged in to WordPress.com, is that expected?

[katinthehatsite]

Thanks Kat for improving this! I have tested it, and I am redirected to the Sign up page when I am logged-out of WordPress.com as expected ✅, but I am redirected to the Log in page when I am logged in to WordPress.com, is that expected?

Let me check, I technically did not make any changes there so it should be the same as trunk for that behaviour 👀

[katinthehatsite]

Okay I think I see what you mean: when you are logged in and click that link, it still gives you log in link and when you are logged out, it gives you the Sign up link. But it would give you Sign up link in both cases 🤔

[katinthehatsite]

@epeicher I spent some time investigating it and I believe that it is a server-side behaviour from WPCCOM. The Create a free account link still works as expected and redirects you to sign up but WPCCOM seems to detect that you have an account where you are logged in and does the redirect to login. This is also present on trunk so it is not coming from this branch directly.

I checked if we can make this work by detecting where the user is logged-in before determining if the user should be served Login or Signup link when they click on the link to Create a new account but it was a rabbit hole. If you have any ideas, let me know and I would be happy to explore them further 🙇

I also think that this is somewhat of an edge case as usually the users who don't have an account would click that link and not the ones who have an account so I don't expect many users to be affected by that.

[epeicher]

I checked if we can make this work by detecting where the user is logged-in before determining if the user should be served Login or Signup link when they click on the link to Create a new account but it was a rabbit hole. If you have any ideas, let me know and I would be happy to explore them further 🙇

Ok, I have been having a look how Calypso does it when clicking on Create an account and I have found that it first logs out the user and then the URL you have used works as expected. If required, we could try to do that from Studio but I don't think that is a good approach as it might be annoying to users.

@Marinatsu , @crisbusquets , are you happy with the implemented behaviour? Let me summarise it:

1. User is logged out of WordPress.com -> User clicks Create a free account in Studio -> User is redirected to Sign up page
2. User is logged in on WordPress.com -> User clicks Create a free account in Studio -> User is redirected to Sign up page -> WordPress.com redirects the user to Log in page

We could force users navigate to Sign up by logging them out, but I don't think that is a good approach, and at least with this change, the user navigates to Sign up when they are not logged in on WordPress.com.

[katinthehatsite]

Ok, I have been having a look how Calypso does it when clicking on Create an account and I have found that it first logs out the user and then the URL you have used works as expected. If required, we could try to do that from Studio but I don't think that is a good approach as it might be annoying to users.

I had a similar experience when reviewing the code and I think this would be a regression in the user experience.

Just to emphasize, I think it is also a bit of an edge case as most of the users who have an account, will use the Log in button 99% of the time.

[sejas]

I don't see any change in user experience between this PR and trunk.

I think this is an edge case. The signup button should target users who are logged out in the browser. If a user is logged in and clicks the signup link, WordPress.com currently displays the login form, which is acceptable in my opinion. However, it would be even better if a logged-in user who clicks the signup link is redirected directly to the OAuth page.

Here is the current implementation summary:

[katinthehatsite]

I don't see any change in user experience between this PR and trunk.

With this PR, we are sending the users to Sign up if they are logged out everywhere and click the link to create an account and to Log in, if they are logged out and click on log in link. On trunk, we are seding them to Log in link when they are logged out and click on the link to create an account instead of sending them to Sign up.

I agree that it is an edge case because the user would probably be clicking the correct button but if they don't, we are at least bringing them to the right place.

[sejas]

On trunk, we are seding them to Log in link when they are logged out and click on the link to create an account instead of sending them to Sign up.

Ok, I see. Thanks for pointing that out. It seems I didn't compare trunk correctly. In that case, this change makes sense to merge. I see that the new signup flow is much simpler compared to the "email me" login, because the user doesn't need to receive and confirm any email to create the account.

Here are the before and after signup links, so it's easier to comapre the behaviours without running Studio.

• Before: https://wordpress.com/log-in/link?redirect_to=https%3A%2F%2Fpublic-api.wordpress.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dtoken%26client_id%3D95109%26redirect_uri%3Dwpcom-local-dev%253A%252F%252Fauth%26scope%3Dglobal%26locale%3Den&client_id=95109&locale=en
• After: https://wordpress.com/start/wpcc/oauth2-user?oauth2_client_id=95109&oauth2_redirect=https%3A%2F%2Fpublic-api.wordpress.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dtoken%26client_id%3D95109%26redirect_uri%3Dwpcom-local-dev%253A%252F%252Fauth%26scope%3Dglobal%26locale%3Den&locale=en

Before (trunk)
After (this branch)			N/A

[sejas]

@katinthehatsite, For some reason, I'm getting this error after approving the OAuth that triggers the deeplink. I'm not sure if it's happening only to me.

[katinthehatsite]

@katinthehatsite, For some reason, I'm getting this error after approving the OAuth that triggers the deeplink. I'm not sure if it's happening only to me.

Taking a look now 👀

I see it too but I did not see this before, I am going to start with rebasing trunk to see if there were other changes merged related to authentication.

[katinthehatsite]

@sejas It should be solved now, it just needed to be updated to the most recent trunk given that the PR is 2 weeks old. Would you be able to test again?

[sejas]

Thanks for finding the issue. Now I'm able to authenticate correctly.
This PR improves the current experience by simplifying the registration flow for unauthenticated users, so I suggest merging it.
Regarding the edge case where a logged-in user clicks the "Create a free account" link and sees the login screen, we could create an issue to discuss the best solution and estimate the level of effort required to implement it.

[github-actions]

📊 Performance Test Results

Comparing 289ccb4 vs trunk

site-editor

Metric	trunk	289ccb4	Diff	Change
load	8857.00 ms	11248.00 ms	+2391.00 ms	🔴 27.0%

site-startup

Metric	trunk	289ccb4	Diff	Change
siteCreation	21138.00 ms	13007.00 ms	-8131.00 ms	🟢 -38.5%
siteStartup	5954.00 ms	4019.00 ms	-1935.00 ms	🟢 -32.5%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change