Launch site: send the Back button to the page the launch started from

[paulopmt1]

Fixes DOTOBRD-606

Proposed Changes

• /start/launch-site now takes an optional redirect_to query dependency that sets the post-launch destination, leaving back_to to mean only "the page the user came from".
• useSiteLaunch() forwards its existing postLaunchUrl option as redirect_to, so the option now covers the signup-flow path as well as the immediate-launch path.
• Site visibility settings passes postLaunchUrl (the site home) rather than overriding back_to with it. SiteLaunchButton's backTo prop had no other consumer, so it becomes postLaunchUrl.

The omnibar/masterbar launch buttons are unchanged: they pass an explicit backTo (the site overview), which is what that option is for.

Why are these changes being made?

The launch flow uses back_to for two different things: the Back button on the first step (domains-launch) and the destination after the site is live. The dashboard's site visibility settings set back_to to the site home so that launching would land the user there, which also repointed the Back button — so clicking Back from /start/launch-site/domains-launch dropped the user on the site home instead of the site visibility page they came from.

Splitting the two meanings fixes Back without changing where anyone lands after a successful launch.

Testing Instructions

1. Pick an unlaunched site.
2. Go to its site visibility settings in the dashboard: /sites/<site-slug>/settings/site-visibility.
3. Click "Launch your site". You land on /start/launch-site/domains-launch.
4. Click "Back" — you should return to the site visibility page, not the site home.
5. Go through the flow and launch the site — you should still land on the site home with the launch celebration.
6. Repeat 3–5 from the "Launch site" button in the omnibar/masterbar to confirm it is unaffected: Back and a successful launch both go to the site overview, as before.

Automated coverage: yarn test-client client/signup/test/flows.js client/dashboard/sites/site-launch-button

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?
• For UI changes, have you tested the affected components in dark mode?
• Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2).
• 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)?

🤖 Generated with Claude Code

https://claude.ai/code/session_01CfPtNr1ULYu5k2NjnKQqm4

[github-actions]

WordPress.com

• Dashboard Live (direct link)

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

• Calypso Live (/home) (direct link)

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

---

Automattic for Agencies

• Dashboard Live (direct link)

  https://calypso.live?image=registry.a8c.com/calypso/app:build-195328&env=dashboard-a4a

• Automattic for Agencies Live (direct link)

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

---

Jetpack Cloud Live (direct link)

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

[github-actions]

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

Sections (~42 bytes added 📈 [gzipped])

Details

Name	Parsed		Gzip
signup	+181 B	+0.1%	+42 B	+0.1%
async-step-unified-plans	+99 B	+0.0%	+22 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 (~24 bytes added 📈 [gzipped])

Details

Name	Parsed		Gzip
async-load-calypso-layout-masterbar-omnibar	+54 B	+0.0%	+24 B	+0.0%

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.

[bogiii]

Reviewed; it works as described. 👍

Worth mentioning that we should test and cover the same thing for the simple sites and atomic sites.

Example (Simple site):

In this scenario, the heading "Back to sites" seems wrong, since I came there from the simple site wp-admin.

Also, one comment from the agent reviewer:

Consistency: redirect_to gets a store reset, back_to doesn't (low)

client/signup/controller.js:309 resets stale redirect_to on flow entry because the signup dependency store persists between visits. back_to has the same persistence property but no reset. Not currently exploitable — the launch-site entry points always set back_to (settings form defaults to redirectToDashboardLink; omnibar sets siteOverviewUrl), so it's never absent — but the asymmetry is a latent trap if a future caller omits back_to. Worth a one-line comment noting why only redirect_to needs the reset.

[paulopmt1]

Good catch @bogiii, I'll follow-up with that