Componentry: migrate Status to @wordpress/ui Text in plugin consumers by CGastrell · Pull Request #48711 · Automattic/jetpack

CGastrell · 2026-05-12T04:54:34Z

Part of #48160.

Proposed changes

Replace the internal Jetpack Status component (from @automattic/jetpack-components) with inline JSX using Text from @wordpress/ui plus a small colour-coded indicator span across all six in-repo consumer sites in plugins/protect and plugins/jetpack. Mark the Status source in js-packages/components as @deprecated (JSDoc-only, no API change) following the chip → badge precedent from #48162.

plugins/protect: AdminSectionHero storybook, firewall admin-section-hero, scan admin-section-hero, scan history admin-section-hero — single Status sites. Now share an AdminSectionHero.StatusIndicator helper backed by styles.module.scss so the four call sites stay terse.
plugins/jetpack: _inc/client/security/waf.jsx "Standalone mode" label. Styling lives under the existing .waf__standalone__mode class in _inc/client/security/style.scss (no inline style blocks).
plugins/jetpack: _inc/client/pro-status/index.jsx renders four different status states (active, error, action, initializing); co-locate a style.module.scss mirroring the wrapper's status colour map (is-active | is-inactive | is-error | is-action | is-initializing) so the four call sites stay terse. Also drops the dead text prop on the legacy rewind status site (the original Status wrapper only ever read label, never text, so the prop was already being ignored — same strings reach the DOM via the now-explicit DEFAULT_LABELS map).
js-packages/components: Status keeps the same implementation, styles, stories, and barrel export; only adds an @deprecated JSDoc block pointing at the inline replacement pattern so external npm consumers see the guidance without breaking on a patch upgrade.

Colour tokens — design-system migration

This PR no longer uses --jp-* colour vars. Indicators now reference WPDS design tokens with a hex fallback for surfaces that don't enqueue @wordpress/theme/design-tokens.css:

Status	Token	Fallback hex
`active`	`--wpds-color-fg-content-success-weak`	`#008030`
`error`	`--wpds-color-fg-content-error-weak`	`#cc1818`
`action`	`--wpds-color-fg-content-warning-weak`	`#926300`
`initializing`	`--wpds-color-fg-content-info-weak`	`#006bd7`
`inactive`	`--wpds-color-fg-content-neutral-weak`	`#707070`

The *-weak family is the recognizable shade (matches the old --jp-green-50 / --jp-red-50 / --jp-gray-50 palette); the base --wpds-color-fg-content-* tokens are near-black "ink" colours intended for text on tinted alert/badge backgrounds — wrong choice for a standalone dot + label, and they were what made the indicators look colourless on the previous push (commit 361bcad). The fallback hex covers the legacy Jetpack settings dashboard, which does not load @wordpress/theme/design-tokens.css. See follow-up comment for the verification on the live dev site.

Acceptance:

grep -rn "from '@automattic/jetpack-components'" projects/plugins/protect/ projects/plugins/jetpack/ | grep '\\bStatus\\b' returns zero matches.
pnpm jetpack build plugins/protect, pnpm jetpack build plugins/jetpack, pnpm jetpack build js-packages/components all green.
ESLint + Prettier + tsgo clean on all touched files; husky hooks ran on commit.
Visual parity verified at Protect → Scan and Protect → Firewall heroes (see screenshots below).
Indicator colour resolves to the recognizable shade on both the Protect React routes (rgb(0, 128, 48) from the token) and the legacy Jetpack settings dashboard (rgb(0, 128, 48) from the hex fallback).

Related product discussion/links

Tracking issue: Jetpack UI Modernization #48160
Precedent for @deprecated JSDoc on a jetpack-components export: Componentry: Migrate Chip to @wordpress/ui Badge #48162 (Chip → Badge)
Precedent for @wordpress/ui Text adoption: Publicize: migrate all Button consumers to @wordpress/ui #48150, Charts: Replace __experimentalText with @wordpress/ui Text #47894, My Jetpack: render interstitials with unified header (breadcrumbs-like back-link + license-key action) #48414, My Jetpack: migrate interstitial Buttons to @wordpress/ui #48489
Precedent for WPDS design-token adoption: Charts: Replace hardcoded typography with WPDS design tokens #47989 (Charts), My Jetpack: render interstitials with unified header (breadcrumbs-like back-link + license-key action) #48414 (My Jetpack header), Search: migrate dashboard notices to @wordpress/ui Notice (depends on #48537) #48550 (Search Notice)

Does this pull request change what data or activity we track or use?

No.

Testing instructions

Install Jetpack Protect on a sandboxed site and visit Jetpack → Protect.
- Scan tab: the green "● Active" indicator at the top of the hero should look identical to trunk — same green dot, same green label text, same spacing, same font weight.
- Firewall tab: the "● Active" indicator above "Firewall is on" should also be unchanged. Toggle the firewall off in the firewall settings to confirm the indicator switches to the grey "● Inactive" state without layout shift.
- Scan → History (if any history threats exist): the green "● Active" indicator should render identically.
With Jetpack (the plugin) active but Protect not active, visit Jetpack → Settings → Security → Firewall. If you have firewall standalone mode enabled (waf['standalone_mode'] in WAF settings), the "● Standalone mode" green indicator should render in the section header, identical to trunk.
(Internal) Browse Storybook for Plugins/Protect/AdminSectionHero — the green "● Active" indicator at the top of the hero should still look the same.

Screenshots

Visual parity check across the six Status consumer surfaces. Indicators paint identically — same recognizable green / red / amber / blue / grey, same dot size, same line-height. On modern Protect routes the colour resolves from the WPDS token; on the legacy Jetpack dashboard the #008030 hex fallback paints (the token is absent there).

Screen	Before (trunk)	After (this PR)
Protect → Scan hero
Protect → Firewall hero
Protect → Scan → History hero
Jetpack → Settings → Security (WAF "Standalone mode")
Jetpack → Dashboard (Pro Status panel)

Notes on the legacy-dashboard captures:

WAF "Standalone mode" — when Jetpack Protect is active on the same site the waf.jsx short-circuits to a redirect-banner branch and <QueryWafSettings /> never mounts; the REST short-circuit returns standalone_mode: true but isn't fetched. The "after" image is the rendered DOM with the indicator HTML re-injected at .waf__header so the PR's CSS path (.waf__standalone__mode / __indicator) is exercised exactly as the production render emits it.
Pro Status panel — the panel is gated by ! isOfflineMode; the dev site is in Offline Mode (URL classed as local-dev). The "after" image is a multi-state DOM-injected demo at the Security section of the dashboard so all four status colour mappings can be eyeballed in one shot.

Verification that the hex fallback resolves correctly on the legacy dashboard (all five status colours rendered via the same CSS path, WPDS token absent on :root — the var(--wpds-…, #hex) fallback paints):

Legacy dashboard hex fallback verification — all 5 status colours

github-actions · 2026-05-12T04:55:19Z

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the change/migrate-status-wp-ui branch.
To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack change/migrate-status-wp-ui

bin/jetpack-downloader test jetpack-mu-wpcom-plugin change/migrate-status-wp-ui

Interested in more tips and information?

In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
Read more about our development workflow here: PCYsg-eg0-p2
Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

github-actions · 2026-05-12T04:55:36Z

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

✅ Include a description of your PR changes.
✅ Add a "[Status]" label (In Progress, Needs Review, ...).
✅ Add testing instructions.
✅ Specify whether this PR includes any changes to data or privacy.
✅ Add changelog entries to affected projects

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

Follow this PR Review Process:

Ensure all required checks appearing at the bottom of this PR are passing.
Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
You can use GitHub's Reviewers functionality to request a review.
When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
WoA releases happen weekly.
Releases to self-hosted sites happen monthly:
- Scheduled release: June 2, 2026
- Code freeze: June 1, 2026

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

Protect plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

jp-launch-control · 2026-05-12T05:11:16Z

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/plugins/jetpack/_inc/client/pro-status/index.jsx	6/87 (6.90%)	2.13%	1 ❤️‍🩹

Full summary · PHP report · JS report

CGastrell · 2026-05-12T16:33:32Z

+	white-space: nowrap;
+
+	&.is-active {
+		color: var(--jp-green-50);


Colors should use design tokens, not the --jp-* variables

Done in 361bcad — swapped the --jp-* vars in pro-status/style.module.scss for WPDS design tokens (--wpds-color-fg-content-success / -error / -warning / -info / -neutral-weak).

CGastrell · 2026-05-12T16:35:11Z

-						label={ __( 'Standalone mode', 'jetpack' ) }
-					/>
+						style={ {
+							alignItems: 'center',


why are we using inlined styles if the component has a className? Style the class. Also, colors should use design token vars, not --jp-*

Done in 361bcad — dropped the inline style={} block and moved the indicator + label styling under the existing .waf__standalone__mode selector in _inc/client/security/style.scss, using --wpds-color-fg-content-success for the color.

CGastrell · 2026-05-12T16:35:32Z

+						} }
+					>
+						<span
+							style={ {


Same as above: inlined styles when we could have this on a css file

Same fix in 361bcad — the indicator span is now styled via a new .waf__standalone__mode__indicator class added under .waf__standalone__mode in the existing global SCSS file.

@deprecated

…styles) - Replace all --jp-* color vars with --wpds-color-fg-content-* design tokens (success/error/warning/info/neutral-weak) in pro-status and protect heroes. - waf.jsx: drop the inline style blocks; move styling under the existing .waf__standalone__mode class in _inc/client/security/style.scss. - Protect heroes: extract a small AdminSectionHero.StatusIndicator helper co-located with the existing admin-section-hero module so the four consumers (storybook, firewall, scan, scan history) share one CSS source instead of duplicating inline style blocks. - Update the @deprecated JSDoc on the Status component to point at the new WPDS tokens so future consumers do not reintroduce --jp-*. Addresses review comments r3228168471, r3228177952, r3228180635 on PR #48711.

CGastrell · 2026-05-12T21:12:41Z

Colour regression fixed in a59feea — Status indicators were rendering near-black (rgb(0, 41, 0) for "Active") because the previous commit used the base --wpds-color-fg-content-* tokens, which are dark "ink" colours intended for text on tinted alert/badge backgrounds, not for standalone dot + label indicators on a plain admin-page background.

Root cause (one line)

--wpds-color-fg-content-success is #002900 (near-black). The right token for a standalone status indicator is the *-weak shade: --wpds-color-fg-content-success-weak = #008030, which matches the original --jp-green-50 = #008710 within a perceptual round-trip.

What landed

Status	Token	Hex fallback
`active`	`--wpds-color-fg-content-success-weak`	`#008030` (≈ old `--jp-green-50` `#008710`)
`error`	`--wpds-color-fg-content-error-weak`	`#cc1818` (≈ old `--jp-red-50` `#d63638`)
`action`	`--wpds-color-fg-content-warning-weak`	`#926300` (warm amber)
`initializing`	`--wpds-color-fg-content-info-weak`	`#006bd7` (link blue)
`inactive`	`--wpds-color-fg-content-neutral-weak`	`#707070` (≈ old `--jp-gray-50` `#646970`)

Each var(--wpds-…, #rrggbb) carries a hex fallback because there's a second issue: the legacy Jetpack settings dashboard (the surface that hosts the WAF "Standalone mode" indicator and the Pro Status panel) does not load @wordpress/theme/design-tokens.css at all — --wpds-* resolves to empty/initial there. With the hex fallback in place, both the modern Protect React routes (where the token loads) and the legacy Jetpack dashboard (where it doesn't) paint the right colour.

Verification on the live dev site

DevTools readings from each affected surface (getComputedStyle of the indicator <span>):

Protect → Scan (/wp-admin/admin.php?page=jetpack-protect#/scan)

indicator dot bg = rgb(0, 128, 48)   ← #008030 (success-weak)
label color     = rgb(0, 128, 48)
--wpds-color-fg-content-success-weak on :root = #008030 (loaded via @wordpress/ui transitively)

Protect → Firewall (#/firewall)

indicator dot bg = rgb(0, 128, 48)
label color     = rgb(0, 128, 48)

Jetpack → Settings → Security (?page=jetpack#/security — legacy dashboard)

--wpds-color-fg-content-success-weak on :root = (empty)
synthetic element with color: var(--wpds-color-fg-content-success-weak, #008030) resolves to rgb(0, 128, 48)

i.e. on the legacy dashboard the token isn't defined, but the hex fallback paints correctly. I injected a DOM-level preview of all five status indicators onto the live /security page (in this dev env neither the WAF standalone-mode toggle nor the Pro Status panel renders without paid-plan / standalone-mode state seeded, so a direct in-app screenshot wasn't possible) — all five rendered in the right colour with the hex fallback alone, confirming the legacy surface is covered.

Files changed in `a59feea`

projects/js-packages/components/components/status/index.tsx — @deprecated JSDoc updated to reference the *-weak tokens and the hex-fallback requirement (no logic change).
projects/plugins/protect/src/js/components/admin-section-hero/styles.module.scss — is-active / is-inactive / .indicator now reference *-weak tokens with hex fallback.
projects/plugins/jetpack/_inc/client/pro-status/style.module.scss — same migration across all five status states.
projects/plugins/jetpack/_inc/client/security/style.scss — WAF "Standalone mode" indicator uses --wpds-color-fg-content-success-weak with #008030 fallback.

Builds re-checked

pnpm jetpack build plugins/protect ✓
pnpm jetpack build plugins/jetpack ✓
pnpm jetpack build js-packages/components ✓

@deprecated

…styles) - Replace all --jp-* color vars with --wpds-color-fg-content-* design tokens (success/error/warning/info/neutral-weak) in pro-status and protect heroes. - waf.jsx: drop the inline style blocks; move styling under the existing .waf__standalone__mode class in _inc/client/security/style.scss. - Protect heroes: extract a small AdminSectionHero.StatusIndicator helper co-located with the existing admin-section-hero module so the four consumers (storybook, firewall, scan, scan history) share one CSS source instead of duplicating inline style blocks. - Update the @deprecated JSDoc on the Status component to point at the new WPDS tokens so future consumers do not reintroduce --jp-*. Addresses review comments r3228168471, r3228177952, r3228180635 on PR #48711.

@deprecated

Part of #48160. Replace the internal Jetpack Status component (from @automattic/jetpack-components) with inline JSX using Text from @wordpress/ui plus a small colour-coded indicator span in the six consumer sites in plugins/protect and plugins/jetpack: - protect: AdminSectionHero storybook, firewall hero, scan hero, scan history hero -- single Status sites, inline style blocks keep the same var(--jp-green-50|gray-50) colour vars, 0.666em indicator, font-weight 600, and line-height 1.666 as the wrapper SCSS. - jetpack: security/waf "Standalone mode" label -- inline style, preserves the waf__standalone__mode className. - jetpack: pro-status renders four different status states; co-locate a style.module.scss mirroring the wrapper's status colour map (is-active|inactive|error|action|initializing) so the four call sites stay terse. Also drop the dead text prop on the legacy rewind status site (the original wrapper only ever read "label") and fall back to the now-explicit default label per status. Annotate the Status source in js-packages/components with an @deprecated JSDoc block (mirroring the Chip -> Badge pattern from #48162) so external consumers see the guidance without breaking on upgrade. Implementation, styles, stories, and barrel export are otherwise unchanged.

@deprecated

…styles) - Replace all --jp-* color vars with --wpds-color-fg-content-* design tokens (success/error/warning/info/neutral-weak) in pro-status and protect heroes. - waf.jsx: drop the inline style blocks; move styling under the existing .waf__standalone__mode class in _inc/client/security/style.scss. - Protect heroes: extract a small AdminSectionHero.StatusIndicator helper co-located with the existing admin-section-hero module so the four consumers (storybook, firewall, scan, scan history) share one CSS source instead of duplicating inline style blocks. - Update the @deprecated JSDoc on the Status component to point at the new WPDS tokens so future consumers do not reintroduce --jp-*. Addresses review comments r3228168471, r3228177952, r3228180635 on PR #48711.

@deprecated

…okens + hex fallback) The previous commit switched to --wpds-color-fg-content-success / -error / -warning / -info, but those are the "ink" tokens used as text on tinted backgrounds in alerts/badges — they resolve to near-black hexes (e.g. success = #2900) and are visually indistinguishable from `color: inherit` for a small dot + label. The Status indicator is a standalone color-coded element on a plain admin-page background, so it needs the recognizable shade family — the *-weak tokens: success-weak = #8030 ≈ --jp-green-50 (#8710) error-weak = #cc1818 ≈ --jp-red-50 (#d63638) warning-weak = #926300 ≈ --jp-yellow-* (warm amber) info-weak = #006bd7 ≈ --jp-blue-* (link blue) neutral-weak = #707070 ≈ --jp-gray-50 (#646970) In addition, the legacy Jetpack settings dashboard (which hosts the WAF standalone-mode indicator and the Pro Status panel) does NOT load `@wordpress/theme/design-tokens.css` at all — so any --wpds-* variable resolves to empty/initial there, and the indicator falls back to `color: inherit`. Add a hex fallback inside each var(--wpds-…, #rrggbb) so the legacy dashboard renders the right shade without depending on the design-tokens stylesheet being enqueued. Verified in DevTools on the live dev site: - /wp-admin/admin.php?page=jetpack-protect#/scan → indicator color now rgb(0, 128, 48) (was rgb(0, 41, 0) near-black). - /wp-admin/admin.php?page=jetpack-protect#/firewall → same. - /wp-admin/admin.php?page=jetpack (legacy dashboard) → WPDS token resolves empty but the #8030 fallback paints correctly. Also update the @deprecated JSDoc on the Status component to point at the *-weak tokens and to mention the hex-fallback requirement.

The legacy _inc/ Jetpack settings dashboard's postcss pipeline runs postcss-custom-properties with preserve: false, which inlines var(--foo) at build time and strips :root { --foo: value } declarations from the output. The pipeline only sees the calypso-color-schemes token source, so any var(--wpds-*) in dashboard SCSS would fall back to whatever hex the consumer hand-wrote in the var(...) second argument. Extend the @csstools/postcss-global-data files list to include @wordpress/theme/design-tokens.css. With both sources loaded, postcss resolves var(--wpds-*) calls to the real WPDS token values at build time, matching the long-standing precedent for @automattic/calypso-color-schemes. This unblocks consumers (e.g. PR #48711) from using raw var(--wpds-*) in legacy dashboard SCSS without having to manually mirror every token value into a hex fallback. Hex fallbacks remain valid as defensive coding for surfaces that may not have run through this postcss pipeline. Add @wordpress/theme as a direct dependency so the require.resolve call works deterministically regardless of pnpm hoisting changes (it was previously only transitive via @wordpress/ui).

@deprecated

…#48711) * Componentry: migrate Status to @wordpress/ui Text in plugin consumers Part of #48160. Replace the internal Jetpack Status component (from @automattic/jetpack-components) with inline JSX using Text from @wordpress/ui plus a small colour-coded indicator span in the six consumer sites in plugins/protect and plugins/jetpack: - protect: AdminSectionHero storybook, firewall hero, scan hero, scan history hero -- single Status sites, inline style blocks keep the same var(--jp-green-50|gray-50) colour vars, 0.666em indicator, font-weight 600, and line-height 1.666 as the wrapper SCSS. - jetpack: security/waf "Standalone mode" label -- inline style, preserves the waf__standalone__mode className. - jetpack: pro-status renders four different status states; co-locate a style.module.scss mirroring the wrapper's status colour map (is-active|inactive|error|action|initializing) so the four call sites stay terse. Also drop the dead text prop on the legacy rewind status site (the original wrapper only ever read "label") and fall back to the now-explicit default label per status. Annotate the Status source in js-packages/components with an @deprecated JSDoc block (mirroring the Chip -> Badge pattern from #48162) so external consumers see the guidance without breaking on upgrade. Implementation, styles, stories, and barrel export are otherwise unchanged. * Componentry: address review - design tokens + CSS classes (no inline styles) - Replace all --jp-* color vars with --wpds-color-fg-content-* design tokens (success/error/warning/info/neutral-weak) in pro-status and protect heroes. - waf.jsx: drop the inline style blocks; move styling under the existing .waf__standalone__mode class in _inc/client/security/style.scss. - Protect heroes: extract a small AdminSectionHero.StatusIndicator helper co-located with the existing admin-section-hero module so the four consumers (storybook, firewall, scan, scan history) share one CSS source instead of duplicating inline style blocks. - Update the @deprecated JSDoc on the Status component to point at the new WPDS tokens so future consumers do not reintroduce --jp-*. Addresses review comments r3228168471, r3228177952, r3228180635 on PR #48711. * Componentry: fix Status indicator color regression (use *-weak WPDS tokens + hex fallback) The previous commit switched to --wpds-color-fg-content-success / -error / -warning / -info, but those are the "ink" tokens used as text on tinted backgrounds in alerts/badges — they resolve to near-black hexes (e.g. success = #2900) and are visually indistinguishable from `color: inherit` for a small dot + label. The Status indicator is a standalone color-coded element on a plain admin-page background, so it needs the recognizable shade family — the *-weak tokens: success-weak = #8030 ≈ --jp-green-50 (#8710) error-weak = #cc1818 ≈ --jp-red-50 (#d63638) warning-weak = #926300 ≈ --jp-yellow-* (warm amber) info-weak = #006bd7 ≈ --jp-blue-* (link blue) neutral-weak = #707070 ≈ --jp-gray-50 (#646970) In addition, the legacy Jetpack settings dashboard (which hosts the WAF standalone-mode indicator and the Pro Status panel) does NOT load `@wordpress/theme/design-tokens.css` at all — so any --wpds-* variable resolves to empty/initial there, and the indicator falls back to `color: inherit`. Add a hex fallback inside each var(--wpds-…, #rrggbb) so the legacy dashboard renders the right shade without depending on the design-tokens stylesheet being enqueued. Verified in DevTools on the live dev site: - /wp-admin/admin.php?page=jetpack-protect#/scan → indicator color now rgb(0, 128, 48) (was rgb(0, 41, 0) near-black). - /wp-admin/admin.php?page=jetpack-protect#/firewall → same. - /wp-admin/admin.php?page=jetpack (legacy dashboard) → WPDS token resolves empty but the #8030 fallback paints correctly. Also update the @deprecated JSDoc on the Status component to point at the *-weak tokens and to mention the hex-fallback requirement.

The legacy _inc/ Jetpack settings dashboard's postcss pipeline runs postcss-custom-properties with preserve: false, which inlines var(--foo) at build time and strips :root { --foo: value } declarations from the output. The pipeline only sees the calypso-color-schemes token source, so any var(--wpds-*) in dashboard SCSS would fall back to whatever hex the consumer hand-wrote in the var(...) second argument. Extend the @csstools/postcss-global-data files list to include @wordpress/theme/design-tokens.css. With both sources loaded, postcss resolves var(--wpds-*) calls to the real WPDS token values at build time, matching the long-standing precedent for @automattic/calypso-color-schemes. This unblocks consumers (e.g. PR #48711) from using raw var(--wpds-*) in legacy dashboard SCSS without having to manually mirror every token value into a hex fallback. Hex fallbacks remain valid as defensive coding for surfaces that may not have run through this postcss pipeline. Add @wordpress/theme as a direct dependency so the require.resolve call works deterministically regardless of pnpm hoisting changes (it was previously only transitive via @wordpress/ui).

CGastrell added [Feature] Protect Also known as Brute Force Attack Protection [Status] In Progress [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [JS Package] Components labels May 12, 2026

github-actions Bot added [Plugin] Protect A plugin with features to protect a site: brute force protection, security scanning, and a WAF. Admin Page React-powered dashboard under the Jetpack menu RNA labels May 12, 2026

CGastrell marked this pull request as ready for review May 12, 2026 16:31

CGastrell commented May 12, 2026

View reviewed changes

CGastrell mentioned this pull request May 13, 2026

Jetpack: resolve WPDS design tokens in legacy dashboard CSS #48750

Merged

CGastrell force-pushed the change/migrate-status-wp-ui branch from a59feea to b3192df Compare May 13, 2026 11:33

CGastrell added 3 commits May 18, 2026 10:52

CGastrell force-pushed the change/migrate-status-wp-ui branch from b3192df to 181b147 Compare May 18, 2026 13:54

CGastrell mentioned this pull request May 18, 2026

Componentry: migrate ContextualUpgradeTrigger to @wordpress/ui Notice #48909

Merged

CGastrell merged commit 28d9cf0 into trunk May 18, 2026
91 checks passed

CGastrell deleted the change/migrate-status-wp-ui branch May 18, 2026 16:45

github-actions Bot removed the [Status] In Progress label May 18, 2026

CGastrell mentioned this pull request Jun 2, 2026

Normalize Hello Dolly across Jetpack admin pages + consistent WPDS token loading #49285

Closed

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Componentry: migrate Status to @wordpress/ui Text in plugin consumers#48711

Componentry: migrate Status to @wordpress/ui Text in plugin consumers#48711
CGastrell merged 3 commits into
trunkfrom
change/migrate-status-wp-ui

CGastrell commented May 12, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented May 12, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented May 12, 2026 •

edited

Loading

Uh oh!

jp-launch-control Bot commented May 12, 2026 •

edited

Loading

Uh oh!

CGastrell May 12, 2026

Uh oh!

CGastrell May 12, 2026

Uh oh!

CGastrell May 12, 2026

Uh oh!

CGastrell May 12, 2026

Uh oh!

CGastrell May 12, 2026

Uh oh!

CGastrell May 12, 2026

Uh oh!

CGastrell commented May 12, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

CGastrell commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed changes

Colour tokens — design-system migration

Related product discussion/links

Does this pull request change what data or activity we track or use?

Testing instructions

Screenshots

Uh oh!

github-actions Bot commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jp-launch-control Bot commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage Summary

Uh oh!

CGastrell May 12, 2026

Choose a reason for hiding this comment

Uh oh!

CGastrell May 12, 2026

Choose a reason for hiding this comment

Uh oh!

CGastrell May 12, 2026

Choose a reason for hiding this comment

Uh oh!

CGastrell May 12, 2026

Choose a reason for hiding this comment

Uh oh!

CGastrell May 12, 2026

Choose a reason for hiding this comment

Uh oh!

CGastrell May 12, 2026

Choose a reason for hiding this comment

Uh oh!

CGastrell commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Root cause (one line)

What landed

Verification on the live dev site

Files changed in a59feea

Builds re-checked

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

CGastrell commented May 12, 2026 •

edited

Loading

github-actions Bot commented May 12, 2026 •

edited

Loading

github-actions Bot commented May 12, 2026 •

edited

Loading

jp-launch-control Bot commented May 12, 2026 •

edited

Loading

CGastrell commented May 12, 2026 •

edited

Loading

Files changed in `a59feea`