Staging sites: Add Delete staging site button to the Staging Site tab (when managing staging site)

[ivan-ottinger]

Resolves https://github.com/Automattic/dotcom-forge/issues/9974.

Proposed Changes

In this PR I am proposing a solution that adds Delete staging site button to the Staging site tab when we are managing that specific staging site:

The proposed solution works as follows:

1. Renders the Delete staging site button with confirmation modal.
2. When user confirms the action, a deleteStagingSite value is stored in the session storage and the user is navigated to the Staging Site tab on the Production site page.
3. The deleteStagingSite value from the session storage is checked and deleted (as it is no longer necessary) and the staging site deletion is triggered.
4. The staging site revert / deletion process continues and completes.

Why are these changes being made?

• https://github.com/Automattic/dotcom-forge/issues/9974

Testing Instructions

1. Apply the PR branch and build the app.
2. On an existing Atomic site create a new staging site.
3. Navigate to the Staging Site tab of the staging site and try to delete the staging site.
4. The staging site should get deleted correctly.
5. Try to create another staging site and this time delete it from the Staging Site tab of the production site.
6. The staging site should get deleted correctly.

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-130306

Jetpack Cloud live (direct link)

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

Automattic for Agencies live (direct link)

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

[matticbot]

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

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

• notifications
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug add/delete-staging-site-button-to-staging-site-tab on your sandbox.

[matticbot]

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

Sections (~265 bytes added 📈 [gzipped])

name          parsed_size           gzip_size
staging-site       +691 B  (+0.0%)     +142 B  (+0.0%)
site-tools         +691 B  (+0.0%)     +123 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.

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.

[sejas]

@ivan-ottinger, I know this is still in progress but so far it's looking great.

Did you try navigating to /sites or /overview/productionSite?.url ? maybe that will fix the current bug and improve the UX.

[sejas]

What if we navigate to /sites to list all the sites?
Or at least to /overview/productionSite?.url ?

I think navigating to any of those will improve the UX as switching to production site and staying in the same tab can be confusing.
This could also "auto" fix the issue of displaying the just removed staging site.

[ivan-ottinger]

That's actually an interesting approach that I haven't explored before.

The idea I had in mind was to navigate the user back to the Staging tab of the Production site where the deletion progress can be observed and the user can spin up a new staging site right away if they wish.

But as you say, navigating the user to the Overview of the production might be actually better UX. I will explore the option. Thanks!

[wojtekn]

It makes sense to review the alternative approach, but using the production site's staging site tab to show the progress indicator and immediately allowing the users to add a new staging site is quite a good UX.

[ivan-ottinger]

After further troubleshooting and investigation I have found out that the issue was caused by the existing periodic query invalidation in useDeleteStagingSite being interrupted during the navigation from the Staging to the Production page.

This also made me think about the issue from a slightly different angle. I have now implemented a simpler solution where we will let the Production page handle the whole deletion process itself. In that proposed change we won't be initiating the deletion from the Staging page at all.

[ivan-ottinger]

@ivan-ottinger, I know this is still in progress but so far it's looking great.

Thank you for the review and suggestions, Antonio! Yes, I marked it as In progress as it is still a draft PR, but could have marked it as Needs review indeed.