Leave blog: Allow users to leave their blog

[arthur791004]

Related to #98772

Proposed Changes

• Allow users to leave their blog on both /sites and site settings

Modal

Default	Owner	User with active subscriptions

Sites

Action menu	Modal

Note: The warning has been removed.

Overview > Settings (isUntangled: true)

Card	Modal

Note: The warning has been removed.

Settings > General (isUntangled: false)

Site Tools	Modal

Note: The warning has been removed.

Why are these changes being made?

• Untangle Global Dashboard

Testing Instructions

Sites

• Apply User: Allow user to delete themselves through the endpoint jetpack#43065 changes to your site
• Go to /sites
• Select ... on any site
• Click Leave site action
• Ensure the Leave site modal is shown
• Check the checkbox and click the Leave site button
• Ensure you can leave the site successfully

Hosting Dashboard

• Apply User: Allow user to delete themselves through the endpoint jetpack#43065 changes to your site
• Go to /sites
• Select any site
• Switch to Settings
• Scroll down to click the ”Leave blog” button
• Ensure the Leave site modal is shown
• Check the checkbox and click the Leave site button
• Ensure you can leave the site successfully

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-140926

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-140926&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-140926&env=a8c-for-agencies

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~386 bytes added 📈 [gzipped])

name                   parsed_size           gzip_size
entry-subscriptions        +1771 B  (+0.1%)     +434 B  (+0.1%)
entry-stepper              +1771 B  (+0.1%)     +435 B  (+0.1%)
entry-main                 +1625 B  (+0.1%)     +385 B  (+0.1%)
entry-login                +1625 B  (+0.1%)     +385 B  (+0.1%)
entry-domains-landing       +621 B  (+0.1%)     +187 B  (+0.1%)
entry-browsehappy           +621 B  (+0.3%)     +187 B  (+0.3%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~606 bytes added 📈 [gzipped])

name                        parsed_size           gzip_size
site-settings                   +1516 B  (+0.1%)     +486 B  (+0.1%)
hosting                         +1516 B  (+0.1%)     +463 B  (+0.1%)
staging-site                     +613 B  (+0.0%)     +149 B  (+0.0%)
sites-dashboard                  +613 B  (+0.1%)     +149 B  (+0.0%)
site-performance                 +613 B  (+0.0%)     +149 B  (+0.0%)
site-monitoring                  +613 B  (+0.1%)     +149 B  (+0.0%)
site-logs                        +613 B  (+0.1%)     +149 B  (+0.0%)
plans                            +613 B  (+0.0%)     +149 B  (+0.0%)
overview                         +613 B  (+0.0%)     +149 B  (+0.0%)
github-deployments               +613 B  (+0.0%)     +149 B  (+0.0%)
domains                          +613 B  (+0.0%)     +149 B  (+0.0%)
site-setup-flow                  -158 B  (-0.1%)      -33 B  (-0.1%)
site-migration-flow              -158 B  (-0.4%)      -50 B  (-0.4%)
hosted-site-migration-flow       -158 B  (-0.4%)      -50 B  (-0.4%)
plugin-bundle-flow               -146 B  (-2.0%)      -43 B  (-1.5%)
async-step-unified-domains       -146 B  (-0.0%)      -36 B  (-0.0%)
settings                          +54 B  (+0.0%)      +32 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~3309 bytes added 📈 [gzipped])

name                                                                              parsed_size           gzip_size
async-load-calypso-sites-settings-administration-tools-leave-site-leave-site-...      +4699 B    (new)    +1808 B    (new)
async-load-calypso-sites-settings-administration-tools-leave-site-leave-site-...      +4486 B    (new)    +1847 B    (new)
async-load-signup-steps-store-features                                                 -146 B  (-0.2%)      -47 B  (-0.2%)
async-load-signup-steps-site-picker                                                    -146 B  (-0.1%)      -44 B  (-0.1%)
async-load-signup-steps-intent                                                         -146 B  (-0.2%)      -49 B  (-0.2%)
async-load-signup-steps-domains                                                        -146 B  (-0.0%)      -37 B  (-0.0%)
async-load-signup-steps-difm-site-picker                                               -146 B  (-0.1%)      -42 B  (-0.1%)
async-load-calypso-blocks-jitm-templates-sidebar-banner                                -146 B  (-0.3%)      -43 B  (-0.2%)
async-load-calypso-blocks-jitm-templates-notice                                        -146 B  (-0.3%)      -42 B  (-0.2%)
async-load-calypso-blocks-jitm-templates-default                                       -146 B  (-0.3%)      -42 B  (-0.2%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• blaze-dashboard
• command-palette-wp-admin
• help-center
• notifications
• odyssey-stats

To test WordPress.com changes, run install-plugin.sh $pluginSlug feat/leave-blog on your sandbox.

[fushar]

Is this correct? This means that I can never leave a non-Free site, even though I'm not the owner 🤔

[arthur791004]

wpcom only checks whether the user has the domain subscriptions or not. However, the endpoint also checks the active subscriptions so I assume it should be consistent with it 🤔

https://github.com/Automattic/jetpack/blob/7b6b26351324e6acce078a452456b5e06225bd33/projects/plugins/jetpack/json-endpoints/class.wpcom-json-api-update-user-endpoint.php#L128-L134

The name may not be correct as it should be hasActiveCancelableSubscriptions. I'll rename it.

[fushar]

Can you try this case:

1. Create a Premium site.
2. Invite a user as non-admin
3. Try leaving the site from that user.

In my testing I can't do that; it warns me that I need to cancel the subscription even though I'm not the owner. So basically noone can leave a Premium site

[arthur791004]

Hmmm… I actually considered this case, but I couldn’t find a reliable way to determine whether the purchases belonged to the current user. I assumed they could only access their own purchases through the endpoint, but that doesn’t seem to be the case. Let me think through how to resolve this.

[arthur791004]

It should be resolved now. The issue was caused by switching to useUserQuery to get the current user ID — but non-admin users don’t have permission to access that endpoint. As a result, the “Leave site” button stayed disabled because the user ID wasn’t available.

I’ve updated it to use the core WordPress endpoint /wp/v2/users/me instead, which works for all logged-in users and fixes the permission issue.

Also, regarding the purchases endpoint — it’s only accessible by site admins, so non-admin users wouldn’t have hit this problem. For admin users, I realized the purchases data actually includes a userId field which I totally missed yesterday... 🙈. With that, I’m now able to get cancelable purchases based on user ID to avoid this case.

[jameskoster]

Thanks for the ping.

Default looks good ✅

For the other variations, I don't think it quite works to combine the Leave modal with the notice, most of the information is irrelevant until the user meets the relevant conditions.

In other words, if the user is unable to leave the site; display a confirmDialog explaining why with cta. When there are two conditions we can show the subscription management one first.

What do you think?

[arthur791004]

In other words, if the user is unable to leave the site; display a confirmDialog explaining why with cta. When there are two conditions we can show the subscription management one first.

Sounds good to me! What about the owner who has the subscriptions? Should we just handle those cases one by one? Also, I noticed other places use the term “Manage Purchases” for this kind of situation. Would it be better to align with that wording for consistency? Thanks!

[jameskoster]

Yes I think one-by-one is okay.

Would it be better to align with that wording for consistency?

Absolutely, apologies for that!

[arthur791004]

@jameskoster I kept the dialog header visible for users who are either the site owner or have active subscriptions. The reason is that we can’t determine this beforehand — only after the user clicks “Leave site” in the site list.

If we still prefer not to show the header, I think it makes sense to hide it in all cases, even for users who can leave the site. Since it looks like we can always use the dialog, what do you think?

[jameskoster]

Not a strong opinion but I'd omit the header, or use a different one. I appreciate 'Leave site' echoes the trigger, but I see this dialog more like an interruptive middle-state for explaining why the user cannot leave the site currently.

If you think including a header is important I'd probably change it to something like "Unable to leave site".

[arthur791004]

Okay, let's remove the header 🙂

[fushar]

In the /sites list, leaving a site does not automatically remove it from the table, which could be confusing 🤔

iXhkJT.mp4

[arthur791004]

In the /sites list, leaving a site does not automatically remove it from the table, which could be confusing 🤔

Weirdly, it should be addressed by 7011ca2 as well and I can see the site has been removed from the table after leaving 🤔

Screen.Recording.2025-04-18.at.2.16.02.PM.mov

[taipeicoder]

Tested and works great.

Screen.Capture.on.2025-04-18.at.16-13-46.mp4

Some non-blocking notes:

1. Implementing event tracking would be great.
2. Leaving staging sites doesn't make much sense to me, but maybe there's a use case for it.
3. Leaving P2s results in a bug. I prefer if we hide the functionality for P2s. See p1744964320470829-slack-CRWCHQGUB.

[StevenDufresne]

Is leaving a site considered a core action? I would consider not adding this to the actions list.

[arthur791004]

The "Leave site" action was added to the action list because non-admin users do not have access to the Settings page, which is currently the only place where the action to leave a site exists. Adding it to the action list provides a entry point for non-admin users to leave a site.

[StevenDufresne]

As a percentage of our current user base, how many are non-admin users and will need this entry point?

Edit:
I assume isActionEligible( 'leave-site', capabilities ) will display it for almost all users. Is that correct?

[taipeicoder]

Having it in the action list just so it's also available for non-admin users makes sense to me. I'm not too presently concerned whether it's considered a core actions or not, also we would benefit from doing an audit further down the line so that we don't clutter the menu.

[arthur791004]

As a percentage of our current user base, how many are non-admin users and will need this entry point?

I checked on Superset by querying the count of admin vs. non-admin users. It looks like around 13% of users are non-admins. I'm not sure how many of them actively use this entry point, but it’s currently accessible via /me > Manage Blogs > Leave Blog.

I don’t think we should remove this feature as part of the global dashboard deprecation. Instead, we could track the usage funnels around this flow and revisit whether it’s still needed in the future based on actual engagement.

I assume isActionEligible( 'leave-site', capabilities ) will display it for almost all users. Is that correct?

YES.

[StevenDufresne]

Having it in the action list just so it's also available for non-admin users makes sense to me.

I understand this sentiment, but it's a slippery slope. We'll need guidelines in place to determine what should be added here or not.

To me, it already feels like a somewhat random collection of links that changes depending on context, with conditional items being injected in unpredictable places.

If a user can't explain why "Leave site" is in the dropdown and not "Reset site" then we probably need to reconsider our UX.

I'm not offering this as a blocker to this PR. I can open a new issue if that's more appropriate. 👍

[taipeicoder]

I'm in agreement which is why I think an audit would be great. I don't think, for instance, "Copy site" is often used enough to be in the actions list.

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/17414106

Some locales (Hebrew) have been temporarily machine-translated due to translator availability. All other translations are usually ready within a few days. Untranslated and machine-translated strings will be sent for translation next Monday and are expected to be completed by the following Friday.

Thank you @arthur791004 for including a screenshot in the description! This is really helpful for our translators.