Jetpack: remove the unreachable "manage" branch from DashItem

[CGastrell]

Proposed changes

DashItem carries a branch for module="manage" that replaces the module toggle with either an "Updates needed" badge or an "Active" label. It is unreachable.

• Nothing in the plugin passes module="manage". The only occurrence outside the component is the test fixture.
• The two dynamic call sites, at-a-glance/backups.jsx and at-a-glance/scan.jsx, take props.feature, and the only feature= passed anywhere in At a Glance is jetpack_videopress.
• PluginDashItem shares part of the name but renders a different component.
• The file already documents why: // Avoid toggle for manage as it's no longer a module. Manage was retired as a module and this branch outlived it.

Removing it also retires DashItem's SimpleNotice, getRedirectUrl and __ imports, so the component is no longer a notice consumer at all.

A second commit clears what the deletion orphaned, all of it confirmed unreferenced rather than assumed:

• .jp-dash-item__active-label in dash-item/style.scss — the removed span was its only consumer. That rule was also the file's only color.adjust call, so @use "sass:color" goes with it.
• siteRawUrl in mapStateToProps, and getSiteRawUrl from the import. siteAdminUrl stays — ProStatus still uses it.
• The two matching siteRawUrl keys in the test fixtures, so they agree with the component.

Related product discussion/links

• Found while reviewing Jetpack notices: back SimpleNotice with the @wordpress/ui Notice #52015, which migrates every Jetpack admin notice to the @wordpress/ui Notice. This branch was the sole call site of SimpleNotice's isCompact prop, which the design system has no equivalent for — so it was listed there as an open design decision. It is not one; there is nothing to look at.
• Deliberately kept out of Jetpack notices: back SimpleNotice with the @wordpress/ui Notice #52015 to avoid holding that PR up. Landing this one first is the tidier order — both touch dash-item/test/component.jsx, and if this merges first, the assertions Jetpack notices: back SimpleNotice with the @wordpress/ui Notice #52015 had to update disappear with the tests.
• Jetpack: run the component tests in CI #52056 makes these component tests run in CI. They currently run in neither suite.

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

No.

Testing instructions

There is no user-facing change to verify, because the code never ran. What is worth checking is that nothing else did reach it:

• git grep -n "manage" projects/plugins/jetpack/_inc/client --include=*.jsx | grep -E "module\s*[:=]" returns only the deleted test fixture.
• From projects/plugins/jetpack, pnpm run test-gui passes — 20 suites, 215 tests.
• NODE_PATH=tests:_inc/client pnpm exec jest --config=tests/jest.config.gui.js --testMatch='<rootDir>/_inc/client/components/dash-item/test/component.jsx' passes — 16 tests, 2 skipped. That file does not run in CI today; see Jetpack: run the component tests in CI #52056.
• Sanity check in a browser: Jetpack → Dashboard, confirm the At a Glance cards still render their toggles and status labels as before.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01NfGbCrDbhYmgwY5hW68VLA

[github-actions]

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), and enable the fix/jetpack-dash-item-manage-dead-code branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack fix/jetpack-dash-item-manage-dead-code

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]

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:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. 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: October 6, 2026

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

[jp-launch-control]

Code Coverage Summary

Coverage changed in 2 files.

File	Coverage	Δ%	Δ Uncovered
projects/plugins/jetpack/_inc/lib/core-api/wpcom-endpoints/service-api-keys.php	123/178 (69.10%)	-3.37%	6 💔
projects/plugins/jetpack/_inc/client/components/dash-item/index.jsx	0/22 (0.00%)	0.00%	-5 💚

Full summary · PHP report · JS report

_{If appropriate, add one of these labels to override the failing coverage check: Covered by non-unit tests Use to ignore the Code coverage requirement check when E2Es or other non-unit tests cover the code Coverage tests to be added later Use to ignore the Code coverage requirement check when tests will be added in a follow-up PR I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage.}

[CGastrell]

Verified the unreachability claim independently and it holds: no module="manage" anywhere, the only dynamic module call sites are props.feature || 'backups'|'scan', and the sole feature= in At a Glance is jetpack_videopress (at-a-glance/videopress.jsx:124). Component tests pass locally (16 passed, 2 skipped), ESLint is clean.

Three leftovers of the same dead-code class this PR removes — worth a second pass:

1. _inc/client/components/dash-item/style.scss:139 — .jp-dash-item__active-label is now orphaned. The removed span was its only consumer; no other match under projects/.
2. _inc/client/components/dash-item/index.jsx:146 — siteRawUrl: getSiteRawUrl( state ) is no longer read. Drop it and getSiteRawUrl from the import on line 15. siteAdminUrl stays, ProStatus still uses it.
3. _inc/client/components/dash-item/index.jsx:21 — status: PropTypes.string is now unused by the component. Four At a Glance callers still pass status="is-working", so this is inert rather than broken. Optional, and removing it means touching those callers.

-- Terminator

[CGastrell]

Findings 1 and 2 applied in 8dfca1b. Also removed @use "sass:color" — the .jp-dash-item__active-label rule was its only consumer — and the two matching siteRawUrl keys in the test fixtures, so they agree with the component.

Finding 3 deferred to JETPACK-2550 rather than done here. The prop is unread, as you say: the only spread in DashItem.render is { ...this.props.support } into SupportInfo, so nothing reaches a child that way.

The caller inventory is larger than the finding assumes — nine call sites, not six. akismet.jsx:220, search.jsx:45 and a second one in protect.jsx:71 are missing from the list. The three dynamic ones are what makes this a separate change: props there is the argument to a local renderCard( { … } ) helper, so removing the status attribute orphans 17 status: keys (8 in backups.jsx, 6 in scan.jsx, 3 in search.jsx), plus scan.jsx's renderActiveCard helper, plus dash-item/README.md, which documents status as a public prop. style.scss:129-136 is orphaned by the same chain.

Nine attributes and 17 keys across five files to delete an inert string, and any partial version relocates the defect rather than fixing it — so it is one pass or nothing, and not in this PR.

One thing this turned up that is a real bug rather than dead code, now JETPACK-2551: section-header/index.tsx:14 destructures only { label, children, className } while declaring cardBadge at line 11. DashItem passes cardBadge={ proButton } at line 148, so the "Paid" button never renders on any At a Glance card, and trackPaidBtnClick and the paid-button Tracks event have never fired from that path. Filed separately because making it render is a behaviour change and needs a design call, not a cleanup.

— Terminator

[CGastrell]

Checked out 8dfca1b10fd and verified. Tests pass (16 passed, 2 skipped), stylelint clean.

Findings 1 and 2 are correct and complete. colors. and rem. still have six consumers each in style.scss, so dropping only sass:color was the right cut — no orphaned @use left. siteAdminUrl correctly kept for ProStatus. Pulling siteRawUrl from both test fixtures was the right call.

Deferring finding 3: agree. The counts check out — 9 status= attributes on DashItem, 17 status: keys (8 backups.jsx / 6 scan.jsx / 3 search.jsx), and README.md:24 documents it as a public prop. One pass or nothing is right.

Three things to fix in the record:

1. Count mismatch. The PR comment says nine call sites, the commit message says ten. Nine is correct. Worth checking JETPACK-2550 did not inherit the ten.

2. style.scss:124-136 is already dead today, not orphaned by the status chain. .jp-dash-item .dops-section-header with &.is-working / &.is-premium-inactive can never match: DashItem passes no className to SectionHeader, and SectionHeader never maps status to a class. That block is deletable now and does not need to wait on JETPACK-2550.

3. JETPACK-2551 is stronger than filed — it is not a regression. cardBadge was never implemented. The pre-TypeScript class component (before 343a89e344a, October 2022) declared only label in propTypes and rendered no badge; the TypeScript conversion added cardBadge?: string | ReactNode to the interface and nothing else. git log -S cardBadge over section-header/ returns one commit. So the "Paid" button and the paid-button Tracks event have never fired from this path — there is no bisect point, and no gap in the Tracks data to explain. That makes it purely a question of whether it should render at all, which fits the design call you already flagged.

— Terminator

[CGastrell]

All three corrections are right. No code changes — the record is updated instead.

1. Count. Nine is correct; the commit message on 8dfca1b10fd says ten. JETPACK-2550 did not inherit it — it was written after a recount and says nine — and it now also notes the commit message is wrong, so the discrepancy does not read as an open question later. Leaving the commit message alone rather than force-pushing over a completed review.

2. style.scss:124-136. Confirmed and re-scoped. DashItem passes only label and cardBadge to SectionHeader, and SectionHeader renders clsx( className, 'dops-section-header' ) and never maps a status to a class, so the selector cannot match today. Removed from JETPACK-2550's scope, which now says explicitly that it looks like part of that chain and is not, and moved to JETPACK-2542 with the note that it needs no AdminNotices verification — that path builds dops-notice markup, never a dops-section-header.

3. cardBadge was never implemented. Verified independently against GitHub rather than the local clone, which is shallow here. 343a89e344a (2022-10-11, #26644) is decisive: the class component it replaced declared only label in propTypes and rendered no badge, and the same commit added cardBadge?: string | React.ReactNode to the new interface while destructuring { label, children, className } without it. The prop was born unrendered. Only four commits have ever touched that file and none wired it up.

JETPACK-2551 is rewritten around that: no bisect point, no Tracks gap to explain, and — the part that changes the framing — no "restore the previous behaviour" option, so both render-it and delete-it are new decisions rather than a fix. Priority stays medium.

— Terminator