Update environment types and related badge handling #1645

ivan-ottinger · 2025-08-06T11:25:29Z

Related issues

Resolves STU-652

Proposed Changes

Pressable is no longer setting sandbox environment type for their sandbox sites. Instead, these sites are now using the development environment type. Because of that, we are adjusting the related environment badges in Studio to use Development badge for sites with development environment type set.

Related discussion: p1753471348570109-slack-C08AHBHGDEZ.

Together with this change we are also removing support for the local environment type (and related badge and Push / Pull modal copy). Only the following three environment types will be represented in badges: Production, Staging and Development. All other environments, including local will use Production as their badge.

We are also adjusting the logic of getSiteEnvironment to rely on site.isStaging for WordPress.com sites - instead of environment type. More context can be found here.

Testing Instructions

Check out the PR branch and build the app with npm start.

Testing with Pressable site

Connect one of your Pressable sites to one of your Studio sites.
Through the Network Admin's Settings tab, change the jetpack_callable_wp_get_environment_type of your connected Pressable sits to any value (e.g. local, staging, production, development).
When reviewing the site badge in Studio:

if the development environment type is used, the Development badge should be rendered and use the blue color that was previously used for Sandbox badges
if the local environment type is used, the site should have the Production badge; if you click the Push / Pull button, the copy for the production site should be displayed in the modal (not for local)
staging and production environment types should be respected and related badges displayed in Studio UI

Testing with WordPress.com site

Connect one of your WordPress.com sites (that has staging site linked) to one of your Studio sites.
The Production and Staging badges should render correctly in Studio.

General

Badges displayed in the Sync modal should be consistent with badges in the list of already-connected sites on the Sync tab.

Pre-merge Checklist

Have you checked for TypeScript, React or other console errors?

src/modules/sync/lib/environment-utils.ts

src/modules/sync/components/environment-badge.tsx

sejas

Great work, Ivan! The code looks clean and simple. I tested it, and it works well except for an edge case. If a WPcom user set a custom environment type, Studio displays different labels in the sites modal and in the connected sites screens.

I think we should be consistent and display always the environment type set by the user.

Happy Path works great

Inconsistent results for WPcom sites with custom labels

It seems we should update the code in

studio/src/modules/sync/components/sync-sites-modal-selector.tsx

Lines 287 to 297 in 669d146

    
           { ! isPressable && ( 
        
           	<> 
        
           		<EnvironmentBadge type="production" selected={ isSelected } /> 
        
           		{ site.stagingSiteIds.length > 0 && ( 
        
           			<EnvironmentBadge type="staging" selected={ isSelected } /> 
        
           		) } 
        
           	</> 
        
           ) } 
        
           { isPressable && ( 
        
           	<EnvironmentBadge type={ getSiteEnvironment( site ) } selected={ isSelected } /> 
        
           ) }

src/modules/sync/lib/environment-utils.ts

ivan-ottinger · 2025-08-06T15:09:16Z

Thank you for the review, Antonio!

I tested it, and it works well except for an edge case. If a WPcom user set a custom environment type, Studio displays different labels in the sites modal and in the connected sites screens.

I think we should be consistent and display always the environment type set by the user.

Indeed! That's a great catch! Thank you for noticing that. I will address it tomorrow morning. 🙂

wojtekn · 2025-08-06T15:54:00Z

What happens if the user sets this variable to an unsupported environment type?

sejas · 2025-08-06T16:09:35Z

src/modules/sync/lib/environment-utils.ts

-		return connectedSite.environmentType ?? 'production';
-	}
-	return connectedSite.isStaging ? 'staging' : 'production';
+	return connectedSite.environmentType ?? 'production';


I modified this logic to support only the four environment types. See:

https://github.com/Automattic/studio/pull/1648/files#diff-d7212615886d109b1f34adab097f47d9877e00f7e088fbef173bc190cb37ab8a

sejas · 2025-08-06T16:13:23Z

What happens if the user sets this variable to an unsupported environment type?

If the environment type is not supported, I suggest that Studio will display the badge as Production.
I added the check in my PR https://github.com/Automattic/studio/pull/1648/files#diff-d7212615886d109b1f34adab097f47d9877e00f7e088fbef173bc190cb37ab8a

const EnvironmentSchema = z.enum( [ 'production', 'staging', 'development', 'local' ] );
export type EnvironmentType = z.infer< typeof EnvironmentSchema >;

export const getSiteEnvironment = ( site: SyncSite ): EnvironmentType => {
	const parsed = EnvironmentSchema.safeParse( site.environmentType );
	return parsed.success ? parsed.data : 'production';
};

sejas · 2025-08-07T10:32:59Z

@ivan-ottinger , I've merged #1648

ivan-ottinger · 2025-08-07T12:21:36Z

@ivan-ottinger , I've merged #1648

Thank you, Antonio. This PR is now ready for another review round. I have also updated the PR title, description and testing instructions.

sejas

@ivan-ottinger , I tested the PR and works great. I see the real Environment type in the modal and when the site is connected.
I left a suggestion about removing renderStagingSiteBadge. It's not a strong opinion, so let me know what you think.

src/modules/sync/components/sync-sites-modal-selector.tsx

wojtekn · 2025-08-08T09:56:13Z

@ivan-ottinger @sejas the part with supporting "local" as a type of remote environment seems a bit weird.

Should we diverge from core here and support only labels that make sense as labels used by WordPress.com or Pressable (production, staging, development), and ignore the rest? Or take a step back and only support labels that we show in the WordPress.com sites dashboard, so we would go back to using production and staging?

ivan-ottinger · 2025-08-08T10:53:51Z

[...] the part with supporting "local" as a type of remote environment seems a bit weird.

I see what you mean.

Should we diverge from core here and support only labels that make sense as labels used by WordPress.com or Pressable (production, staging, development), and ignore the rest?

If I am understand your point of view correctly, in the case of local environment type (or some other non-core value) we would not display any badge, right?

In that case we would need to rethink the copy displayed on the sync modal as well though. Instead of Push to Development it could say Push to {site-title / site-url}

Curious to hear what Antonio thinks as well.

wojtekn · 2025-08-08T10:57:42Z

@ivan-ottinger maybe we should follow what @sejas proposed above?

production -> Production
staging -> Staging
development -> Development
anything else -> Production

ivan-ottinger · 2025-08-08T11:31:46Z

@ivan-ottinger maybe we should follow what @sejas proposed above?

production -> Production

staging -> Staging

development -> Development

anything else -> Production

Yes, that should work. 👍🏼

There's one issue I have observed with relying on the environment_type for WordPress.com sites:

With the current staging site sync logic (on the WordPress.com side), the environment_type is synced as well. As a result we end up with both sites having the Production badge (as an example):

We could adjust the getSiteEnvironment change introduced in https://github.com/Automattic/studio/pull/1648/files#diff-d7212615886d109b1f34adab097f47d9877e00f7e088fbef173bc190cb37ab8aR8-R10. to still rely on connectedSite.isStaging for WordPress.com sites.

wojtekn · 2025-08-08T11:38:06Z

Good catch @ivan-ottinger . It makes sense to have such a series of fallbacks indeed.

… sites

sejas · 2025-08-08T12:06:00Z

I see both solutions can be a bit confusing for some users, but keeping the old logic that limited WPcom to only use production and staging seems the most reasonable.
Just leaving here why the other approach also made sense. It seems that the environment type is displayed in Calypso overview for Agency sites. See the screenshots p1752755426181769/1752734657.162979-slack-C06DRMD6VPZ

ivan-ottinger · 2025-08-08T12:24:30Z

I see both solutions can be a bit confusing for some users, but keeping the old logic that limited WPcom to only use production and staging seems the most reasonable.

Yes, I agree that neither of the two solutions is 100% ideal.

I have updated the PR (including the title, description and testing instructions). Feel free to take another look if you like.

sejas

@ivan-ottinger , great work! 🚢
WPcom sites will display only Production and Staging based on isStaging.
Pressable sites will display any valid Studio environment type (Production, Staging, Development).

src/modules/sync/components/sync-sites-modal-selector.tsx

ivan-ottinger self-assigned this Aug 6, 2025

ivan-ottinger changed the title ~~Simplify Environment badge logic and replace the sandbox environment type with development~~ Replace the sandbox environment type with development and simplify Environment badge logic Aug 6, 2025

ivan-ottinger commented Aug 6, 2025

View reviewed changes

src/modules/sync/lib/environment-utils.ts Outdated Show resolved Hide resolved

ivan-ottinger commented Aug 6, 2025

View reviewed changes

src/modules/sync/components/environment-badge.tsx Show resolved Hide resolved

ivan-ottinger requested a review from a team August 6, 2025 13:24

sejas reviewed Aug 6, 2025

View reviewed changes

src/modules/sync/lib/environment-utils.ts Outdated Show resolved Hide resolved

sejas reviewed Aug 6, 2025

View reviewed changes

sejas mentioned this pull request Aug 6, 2025

Add full sentence translations to the pull push dialog to support languages with declinations #1648

Merged

1 task

ivan-ottinger changed the title ~~Replace the sandbox environment type with development and simplify Environment badge logic~~ Replace the Sandbox environment badge with Development and ensure all envrionment_type values are respected Aug 7, 2025

ivan-ottinger added 6 commits August 7, 2025 12:40

Rename sandbox environment style classess to development

5d14089

Fix test

984c7ce

Update environment type labels

b1ed0bf

Fix test

ca4e3a4

Ensure environment badge respects environment_type

0ebfaf8

Add type safety to environment handling with Zod schema validation

cc9f76f

ivan-ottinger force-pushed the update/environment-badge-logic branch from 9e3036b to cc9f76f Compare August 7, 2025 10:41

ivan-ottinger added 4 commits August 7, 2025 12:58

Update tests and types

ebb9b55

Add styling for local environment type

38b5fb9

Revert accidental environmentType order change

89c1718

Unify badge / environment_type order

09034d1

sejas approved these changes Aug 7, 2025

View reviewed changes

src/modules/sync/components/sync-sites-modal-selector.tsx Outdated Show resolved Hide resolved

ivan-ottinger added 5 commits August 8, 2025 13:40

Simplify staging site badge rendering logic

30a3fab

Use site.isStaging for evaluating site environment of WordPress.com…

2168e4f

… sites

Remove local environment type and related badge and copy

42b91c0

Remove redundant local environment style class mapping

e35fc56

Remove redundant Local badge test case

06a4a2f

ivan-ottinger changed the title ~~Replace the Sandbox environment badge with Development and ensure all envrionment_type values are respected~~ Update environment types and related badge handling Aug 8, 2025

sejas approved these changes Aug 8, 2025

View reviewed changes

src/modules/sync/components/sync-sites-modal-selector.tsx Outdated Show resolved Hide resolved

Simplify rendering of Staging site environment badge

dd7577d

ivan-ottinger merged commit 109fddc into trunk Aug 8, 2025
12 checks passed

ivan-ottinger deleted the update/environment-badge-logic branch August 8, 2025 15:23

	{ ! isPressable && (
	<>
	<EnvironmentBadge type="production" selected={ isSelected } />
	{ site.stagingSiteIds.length > 0 && (
	<EnvironmentBadge type="staging" selected={ isSelected } />
	) }
	</>
	) }
	{ isPressable && (
	<EnvironmentBadge type={ getSiteEnvironment( site ) } selected={ isSelected } />
	) }

Update environment types and related badge handling #1645

Update environment types and related badge handling #1645

Uh oh!

Conversation

ivan-ottinger commented Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related issues

Proposed Changes

Testing Instructions

Pre-merge Checklist

Uh oh!

Uh oh!

Uh oh!

sejas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ivan-ottinger commented Aug 6, 2025

Uh oh!

wojtekn commented Aug 6, 2025

Uh oh!

sejas Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

sejas commented Aug 6, 2025

Uh oh!

sejas commented Aug 7, 2025

Uh oh!

ivan-ottinger commented Aug 7, 2025

Uh oh!

sejas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wojtekn commented Aug 8, 2025

Uh oh!

ivan-ottinger commented Aug 8, 2025

Uh oh!

wojtekn commented Aug 8, 2025

Uh oh!

ivan-ottinger commented Aug 8, 2025

Uh oh!

wojtekn commented Aug 8, 2025

Uh oh!

sejas commented Aug 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ivan-ottinger commented Aug 8, 2025

Uh oh!

sejas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ivan-ottinger commented Aug 6, 2025 •

edited

Loading

sejas commented Aug 8, 2025 •

edited

Loading