Wp-calypso: Calypso: Deep links redirecting

[xpurichan]

Steps to reproduce

1. Find a site-specific address within Calypso. For example, I found https://wordpress.com/domains/manage/lillylearns.com by going to: My Sites > Domains on my lillylearns.com site
2. Copy this address and paste it in to a new browser tab
3. In one case we found that this deep link would instead redirect us to the site's stats page: https://wordpress.com/stats/day/131376930
4. In other cases when we visit these types of addresses we're directed to another page that requires us to confirm which website we're editing:
   

What I expected

To be taken to the page that this address specifically links to.

What happened instead

Instead I am redirected to my stats page or directed to choose which website I'm working on first (which should not be asked when the domain is specified in the deep link address).

Context / Source

This was initially a #user-report. I was able to replicate the behavior through their account (where we were redirected to the stats page) and also on my own account (where I was redirected to choose my website, per the screenshot).

7072782-hc

[arunsathiya]

I just tested this at my end and I can confirm this behaviour as well. I am not very sure if this was the case in the past as well. 🤔

This seems to happen only for the domain management page, other deep links work as expected.

From what I see, visiting https://wordpress.com/domains/manage works fine and shows the list of WordPress.com sites on the WordPress.com account, just fine. This has always been the case. ✅

[xpurichan]

I am not very sure if this was the case in the past as well.

To confirm I've historically always given these links to users in chat and in tickets. I've never experienced other reports of this happening until today. I could be mistaken, but if I am then I've never received a report about it.

[KokkieH]

I'm not able to replicate this. I get taken straight to the domain management panel for the specific site whenever I enter a direct link like that. Tested on Firefox and Chrome on Mac OS, and tested with mapped, registered and free addresses, Atomic and simple sites, and also with non-superadmin accounts.

The only case where I'm able to replicate this is where I use the non-primary domain on a site as the slug, and that is likely intentional as all Calypso site URLs always use the primary domain on a site as the slug.

Do you have any further information, like does it happen in only a specific browser? Have you ruled out browser-add-ons by logging in in an incognito browser session/disabling all extensions? Were the domains you tested with perhaps set as non-primary at the time?

Aside, please remember to also add the [Type] Bug label to bug reports. It just makes it easier for the people who triage these.

[xpurichan]

Hey @KokkieH ! I just tested this link myself using:
https://wordpress.com/domains/manage/lillylearns.com
It works well and directs to my domain page as expected. I don't see any more redirects to the Stats page or to the Domain Picker. It seems like this may have been resolved!

Thank you for letting me know about the [Type] Bug label, I'll be sure to add it in the future.

[KokkieH]

It seems like this may have been resolved!

Let's close this, then, but feel free to reopen if the issue pops up again.

[arunsathiya]

I can confirm I don't see the same behaviour either now. All good. ✅

[jsnajdr]

This is a real bug and it's probably been around for some time. Not a recent regression.

Easy to reproduce if you clear your local Indexed DB storage and then go to a site-specific domain URL: /domains/manage/site.blog. Instead of displaying domains for site.blog, you will be redirected to:

• /domains/manage (with site selection list) for multi-site users
• /stats for single-site users

It's caused by the redirectIfNoSite handler that interacts in a buggy way with the siteSelection handler.

When no Redux state is cached in local storage, Calypso doesn't have data for the site site.blog on initial load. It doesn't even know the site ID. It knows only the site.blog slug from the URL.

That's why the siteSelection handler initially sets the state.ui.selectedSiteId to null and starts to fetch the site data. Then, after the site data are fetched, sets the selected site ID to the correct value and the UI is rerendered with the new prop.

But redirectIfNoSite will redirect too soon -- at a time when the selected site ID is still null.

The redirectIfNoSite handler shouldn't be there at all -- it just duplicates work that siteSelection already does: redirect to /domains/manage if the site doesn't exist, handle edge cases for single-site users...

If we remove it though, the Domains handlers that render UI will need to cope with selectedSiteId being null. I'm not sure if they can do that.

See also: #23969 by @spen from April 2018 -- that might be the moment when the bug was introduced.

[KokkieH]

Ah, thanks for the info and follow-up, @jsnajdr!

[mattsherman]

This does not seem like a [Pri] High issue.

@xpurichan @KokkieH @arunsathiya What is your perspective on the priority of this? Is this likely to cause frequent/severe problems for customers? Is it something that Happiness encounters often?

[xpurichan]

@mattsherman I agree with you, would a medium priority level be more appropriate, or should it be low?

We rely on links like this as HEs during our troubleshooting and in the cases where links like the redirects to the Stats page it can be very confusing and frustrating for the user.

If these deeplinks don't redirect to the Stats page (for users will multiple sites on their account) and they instead go to a site selection list (then redirects to the proper page upon selection) then it's less confusing and is instead just a little inconvenient.

Outside of HEs providing users these direct links, I am not sure if any of our support document or email to users contain links like this. I would assume that support docs don't contain deeplinks, but some of our emails may.

I've changed the priority level to normal for now.

[KokkieH]

Outside of HEs providing users these direct links, I am not sure if any of our support document or email to users contain links like this.

Correct. If users try to visit this direct link it was almost certainly provided to them by an HE during a support interaction. While it would definitely be convenient to have this fixed, the affect can be offset if HEs follow the practice of providing a click-path in addition to the direct link, thereby also educating users on how to get to the particular page on their own.

@xpurichan, think it might be worth a P2 post to make people aware of this?

[xpurichan]

Posted to P2:
pbg9X-dhr-p2

[mattsherman]

Thanks for the explanation into why this is important, @xpurichan -- the HE direct link situation was not one that I considered! I appreciate you taking the time to explain this to me.

[stale[bot]]

This issue has been marked as stale and will be closed in seven days. This happened because:

• It has been inactive in the past 9 months.
• It isn't a project or a milestone, and hasn’t been labeled `[Pri] Blocker`, `[Pri] High`, `[Status] Keep Open`, or `OSS Citizen`.

You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation.