My Sites: My Sites section breaks if an inactive Jetpack site is the primary site on account

[rachelmcr]

The My Sites section breaks in one of two ways if an inactive Jetpack site is the primary site on the account:

1. If the Jetpack site was the only site on the account, the My Sites section doesn't open at all.
2. If there are other sites on the account, only the All Sites view opens. The active site(s) are not accessible under My Sites.

More context about inactive Jetpack sites (and how they are identified as inactive) in p7rcWF-My-p2 (internal ref). For testing this issue, you can add the is_disconnected sticker to the site by toggling that setting on in the site report card. This will mark the site as inactive.

Steps to reproduce

Scenario 1:

1. Set up a temporary self-hosted site with Jetpack and connect it to a new WordPress.com account with no other sites.
2. Delete the site or take it offline.
3. In the site's report card, enable the is_disconnected toggle.
4. Visit https://wordpress.com/ and open the My Site section.

Scenario 2:

1. Set up a temporary self-hosted site with Jetpack and connect it to a new WordPress.com account with no other sites.
2. Create a new WordPress.com site on the same account.
3. Delete the Jetpack site or take it offline.
4. In the site's report card, enable the is_disconnected toggle.
5. Visit https://wordpress.com/ and open the My Sites section.

What I expected

In Scenario 1 I expected to open the My Site section and see a message that I had no sites.

In Scenario 2 I expected to see my WordPress.com site.

What happened instead

In Scenario 1 I was stuck on the Reader — the My Site section didn't open:

In Scenario 2 the My Sites page opened to the All Sites view and the site switcher didn't appear:

Note: In both scenarios the Primary Site setting in my account settings at https://wordpress.com/me/account was also broken:

Scenario 1:

Scenario 2:

Browser / OS version

macOS/Chrome

Context / Source

user-report p2EDhh-o3-p2 cc @kamikazeballoon

[joendotcom]

Found something similar ref 1185471-zen, Blog ID 144083544.

Of note, this user did not previously have a WP.com site and the site is public. Does not have is_disconnected sticker.

Upon further checking, there was no Primary Site set, thus showing All My Sites:

[tmmbecker]

In 1212616-zen, the user has 2 Jetpack sites and a hidden WordPress.com site. One of the Jetpack sites is not properly connected but they contacted us about the site that IS connected. There was no way to view the site that they were asking about and created lots of confusion for us. In fact, when accessing the account, only the HIDDEN WordPress.com site is showing. Neither Jetpack site is accessible.

[bikedorkjon]

1216989-zen the primary site was no longer connected to JP and My Sites would not load. Changing the primary to another site resolved the issue.

I expected: If a primary site on JP is no longer active the primary should change to an active JP site.

[tmmbecker]

1223532-zen

[davipontesblog]

Also posted here: p2EDhh-uC-p2

[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.

[htdat]

2535991-zen blog_id = 146988038

[htdat]

2580671-zen blog_id = 80901474

From what I notice in Blog RC, jetpack-site-purged is added in two sites in my reports. It seems when purging unconnected JP sites, we need to disconnect these sites from the user too.

@westi you worked on the purging un-used Jetpack sites project so you may have a look at this?

[darnelldibbles-zz]

https://en.forums.wordpress.com/topic/please-check-your-primary-sites-jetpack-connection-cant-login/#post-3437496

[htdat]

2822102-zen blog_id 138625632

Similar to my report above https://github.com/Automattic/wp-calypso/issues/24539#issuecomment-568960118, this site has this sticker jetpack-site-purged in blog RC

[htdat]

3281323-zen

[tmmbecker]

The customer in 3458880-zen had three sites in their primary account (chineusedegrenier) with broken connections because the sites are no longer online. Because of this, they weren't able to access the active site with a Jetpack plan in their WordPress.com dashboard.

So they bought a new plan in a new account. Which royally messed up all of their backups and got things terrifically confused for all of us.

This might seem like a low priority minor bug but for Jetpack users it is significant, particularly given that we don't proactively remove "connections" to sites that are no longer loading or online.

All three sites in this case had the is_disconnected sticker but none had communciated with our servers in a year or more.

@kraftbj I'm wondering how many other users are experiencing this same issue. Can we find out how many Jetpack users have primary sites with the is_disconnected sticker?

There is literally nothing that users can do here and no way for them to know why they can't see their connected site. When we add the disconnected sticker, is there any way to remove the ability for it to be a primary site?

[dkmyta]

@kraftbj any insight you can offer on the matter?

[kraftbj]

I'm not sure there's a good way to determine the scope of this since we'd need to scan through all of the users, pull out the primary site, then check to see if it is disconnected or not.

While updating the primary site if "is_disconnected" is one approach, that flag is automatically removed if the site begins communicating again (e.g. let's just say their server is offline or something).

The other approach is figuring out what is breaking in Calypso and hardening to provide a better experience, which is probably the route to go.

Would figuring out the latter make sense to y'all?

[pranali333]

The other approach is figuring out what is breaking in Calypso and hardening to provide a better experience, which is probably the route to go.

This should do!

@tmmbecker Any thoughts?

[tmmbecker]

Would figuring out the latter make sense to y'all?

Thanks Kraft! If figuring out the latter results in a fluid customer experience when their primary site has a borked connection, then that makes sense. I don't think the solution matters here so much as the end result - users need to be able to see all sites even when the primary site is not actively and successfully connected.

Right now, they are just stuck with no way to self-help.

[htdat]

3594465-zen

[tmmbecker]

3525328-zen

[htdat]

3625326-zen

[tmmbecker]

3820357-zen

Customer was unable to connect and purchase a Jetpack plan because the WordPress.com dashboard is inaccessible. We really should get this fixed!

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. 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 and apply one of relevant issue close labels.

[cuemarie]

Notes from trying to replicate this with @youbrokesomething

Scenario 1 - I added my JP connected self-hosted site as my primary site, then disconnected it via Jetpack Debugger. Returning to WordPress.com, my account showed a different site set as my primary site. No issues accessing Calypso.

Scenario 2.1 - I created a new JP connected self-hosted site, still with it's primary connection set to my super admin account. I then added a second user (a new WordPress.com account) to the site, and the new user set the JP site as their primary site in /me/account. Then I created a second site on WordPress.com, and finally, I disconnected the self-hosted site from JP via the JP Debugger. Once again, the primary site automatically switched to the second site.

Scenario 2.2 - Reconnected my self-hosted site, this time to my new WPcom account. Reset the test, and this time, instead of disconnecting from Jetpack, I just deleted the site from my Pressable dashboard. This did not trigger my WordPress.com account's Primary Site to change, and the (now deleted) self-hosted site still is my primary site. For now, I'm still able to move around the dashboard without issue, but when I log in to WordPress.com, I'm first directed to /read.

• Archiving the site resulted in the site being removed from Calypso on the account, and no errors.

Dashboard behavior after deleting self-hosted site via the host:

https://github.com/Automattic/wp-calypso/assets/27249804/96cd9459-9b51-4e38-9bf1-33f9356d01d4

[github-actions[bot]]

Support References

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

• [ ] 1185471-zen
• [ ] 1212616-zen
• [ ] 1216989-zen
• [ ] 1223532-zen
• [ ] 2535991-zen
• [ ] 2580671-zen
• [ ] 2822102-zen
• [ ] 3281323-zen
• [ ] 3458880-zen
• [ ] 3594465-zen
• [ ] 3525328-zen
• [ ] 3625326-zen
• [ ] 3820357-zen

[youbrokesomething]

👋 Hey folks! Since this issue has been inactive for quite some time, KitKat has made the decision to close it.

Internal reference, for more on this decision: pdqkMK-14B-p2 If you think this issue warrants another look, here are some next steps!

Report anew: A new report with more current details and steps to replicate may be the best way to renew attention on this issue. Feel free to refer back to this closed issue in your report! Reopen: If you feel the issue still matches the context/history here, you can also reopen the issue and add fresh logs, screenshots and steps to reproduce. Thanks for your involvement!