MSD: read origin_site_id param and set as current omnibar site by fushar · Pull Request #109856 · Automattic/wp-calypso

fushar · 2026-04-07T10:24:05Z

Proposed Changes

The W logo from wp-admin's admin bar points to wordpress.com/sites?origin_site_id=<blog_id>. This is used to set the current site in the admin bar.

This PR applies the same logic to the interim omnibar.

Testing Instructions

Check out this PR.
Visit the Site List while dashboard/omnibar flag is true.
Click any site.
Visit another site's wp-admin.
Right-click on the wp-admin W logo and select Copy Link.
Paste the URL to the Site List, but replace https://wordpress.com with my.localhost:3000.
Verify that site is still the current site displayed in the interim omnibar.

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 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)?

github-actions · 2026-04-07T10:24:15Z

Calypso Live (direct link)

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

Jetpack Cloud Live (direct link)

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

Automattic for Agencies Live (direct link)

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

Dashboard Live (dotcom) (direct link)

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

Dashboard Live (CIAB) (direct link)

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

matticbot · 2026-04-07T10:27:16Z

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

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

help-center
notifications
wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug omnibar-origin-site on your sandbox.

p-jackson · 2026-04-08T00:02:43Z

client/dashboard/app/interim-omnibar/index.tsx

 	async function renderWithSiteId( siteId: number | undefined ) {
-		const site = siteId ? await queryClient.ensureQueryData( siteByIdQuery( siteId ) ) : null;
+		const site = siteId
+			? await queryClient.ensureQueryData( siteByIdQuery( siteId ) ).catch( () => null )


Whoops! Good catch 😄

p-jackson · 2026-04-08T00:09:54Z

client/dashboard/app/interim-omnibar/index.tsx

+	const originSiteId = Number(
+		new URLSearchParams( window.location.search ).get( 'origin_site_id' )
+	);
+	if ( originSiteId ) {


Nit: If someone tricked the user include clicking a link with ?origin_site_id=-1 then it would pollute their recentSite preference.

Suggested change

if ( originSiteId ) {

if ( originSiteId > 0 ) {

p-jackson · 2026-04-08T00:14:40Z

client/dashboard/app/interim-omnibar/index.tsx

+		new URLSearchParams( window.location.search ).get( 'origin_site_id' )
+	);
+	if ( originSiteId ) {
+		setCurrentOmnibarSite( originSiteId );


Interesting 🤔 This updates the recentSites, which initially didn't seem right—passing a query param doesn't seem like an authoritative reason to update the recentSites pref. But I can see why we need it. Is this something the v1 HD does?

The other thing that strikes me is that this isn't really interim work, we will want this logic even when the interim solution goes away. So I propose we move this to the MSD router. In the same site router remembers the selected site ID, the root router should be in charge of remembering the ?origin_site_id.

Interesting 🤔 This updates the recentSites, which initially didn't seem right—passing a query param doesn't seem like an authoritative reason to update the recentSites pref. But I can see why we need it. Is this something the v1 HD does?

Yeah, I just realized, v1 HD only sets the "selected site" redux slice, but does not actually update the recentSites preferences. But we don't have such store in dashboard. Let me think a better way...

But it seems to make sense either way. If a user visits an MSD link with an origin_site_id param, it means they just came from that site's wp-admin. By that logic, that site must be their "most recent" site. So I don't see any drawbacks 😬 what do you think?

Maybe you're right. I can't think of any, just naturally cautious about expanding the meaning of this preference.

I had thought maybe, with the OmniBar coming, that MSD would just need to implement it's own concept of "selected site". But perhaps "recent sites" is the most natural thing to use. "Selected" sounds like something transitive, like a keyboard focus, not something that needs persisting. But "recent sites", now that sounds like something that you would naturally persist.

Perhaps recent sites is best.

I still prefer the idea of updating it in the root router since this isn't interim behaviour.

The other thing that strikes me is that this isn't really interim work, we will want this logic even when the interim solution goes away. So I propose we move this to the MSD router.

I tried this but it seems we will run into a problem. Similar reason to the one discussed above, it means we need to wait until the recentSite update call finishes. This is because we immediately clear the origin_site_id param from the URL. So, the omnibar component will never see it, and there can be a race condition where it still renders the old most recent site.

Maybe I'm wrong. The query is updated optimistically! Let me test 😅

block the page

It's not quite blocking the page either, it's more that the server rendered components aren't hydrated until the recent site preference is up to date. So it shouldn't really feel like a slow down for the user.

We're already depending on the route optimistically updating the recentSites preference when you navigate directly to /sites/$siteSlug and it seems to work 🤞 so I was hoping it would "just work" in this instance too. But I mean I can understand if it turns out there does happen to be some complicated race condition in this particular case. I felt quite lucky that it just happened to work for the site route :)

OK, so there's still ugly flash because we are doing await queryClient.ensureQueryData( rawUserPreferencesQuery() ) first before optimistically update the recentSites. There's no way around it. 😅 I think I'm just going with the current approach for now.

We're already depending on the route optimistically updating the recentSites preference when you navigate directly to /sites/$siteSlug and it seems to work

Yes, but in this case, the old recent site is already visible in the omnibar before we navigate to another site. So it's not "flashing" in that sense.

We're already depending on the route optimistically updating the recentSites preference when you navigate directly to /sites/$siteSlug and it seems to work

Yes, but in this case, the old recent site is already visible in the omnibar before we navigate to another site. So it's not "flashing" in that sense.

I was wrong. It's still flashing if we directly visit a site overview URL of another site in another tab for example.

I've spent hours to try to prevent this. But I just realized that it's almost impossible to do because the TanStack router and the omnibar live in different React roots, so there will be race condition 😅 Maybe one way is for the omnibar component itself to parse the URL and extracts siteSlug and converts to siteId. But I don't think it's worth it. Let's just live with what we have now.

fushar · 2026-04-09T05:59:44Z

Declaring bankruptcy; it's easier to just rewrite this from scratch rather than trying to rebase the commits. 😅 will open a new PR.

fushar self-assigned this Apr 7, 2026

fushar marked this pull request as ready for review April 7, 2026 10:34

fushar requested a review from a team as a code owner April 7, 2026 10:34

matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Apr 7, 2026

MSD: read origin_site_id param and set as current omnibar site

bf20200

fushar force-pushed the omnibar-origin-site branch from ae4756e to bf20200 Compare April 7, 2026 11:16

p-jackson reviewed Apr 8, 2026

View reviewed changes

p-jackson approved these changes Apr 8, 2026

View reviewed changes

fushar added 2 commits April 8, 2026 10:29

if origin_site_id > 0

d80b469

Refactor current site logic

78c7425

fushar closed this Apr 9, 2026

github-actions bot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Apr 9, 2026

Conversation

fushar commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed Changes

Testing Instructions

Pre-merge Checklist

Uh oh!

github-actions bot commented Apr 7, 2026 • edited by matticbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matticbot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fushar commented Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fushar commented Apr 7, 2026 •

edited

Loading

github-actions bot commented Apr 7, 2026 •

edited by matticbot

Loading

matticbot commented Apr 7, 2026 •

edited

Loading