[enejb]

Important

Rebased onto trunk (October 2026). Trunk now ships the real Protect dashboard as the protect-dashboard module (packages/protect, behind the jetpack-protect-dashboard feature flag). This spike no longer replaces it. It is its own module, protect-dashboard-spike, with a "Protect (spike)" menu item at admin.php?page=jetpack-protect-spike, so the two pages can be compared side by side.

• The spike's components now use @wordpress/ui (SwitchControl, Notice, TextareaControl, Link), as trunk's lint rule requires.
• The threats-list icon crash fix found here is split out as Scan: Don't crash the threats list layout on a threat of unknown type #53818.
• To compare both on a site:
  • enable the flag with add_filter( 'jetpack_feature_flag_enabled_jetpack-protect-dashboard', '__return_true' );
  • run wp jetpack module activate protect-dashboard protect-dashboard-spike

Fixes #

Note

Exploration. This is a spike for comparing approaches to a Protect dashboard inside the Jetpack plugin. It is not ready to merge.

Proposed changes

• Add a new protect-dashboard Jetpack module (Settings › Modules › "Protect"). When it is active, a Protect item appears in the Jetpack sidebar, gated through Admin_Menu::add_menu( …, [ 'module' => 'protect-dashboard' ] ). The item goes away when the module is turned off.
• The page is a wp-build route (routes/protect-hub) loaded through the existing Jetpack_WP_Build_Page loader. It has two tabs:
  • Overview. One collapsible box per security feature, with that feature's settings inline:
    • Scan: active threats, last scan, and the plugins, themes and core version it covers.
    • Firewall: requests blocked today, in the last 30 days and all time; when the rules were last updated; the firewall and automatic-rules toggles; the IP allow and block lists.
    • Brute force protection: on/off and the number of blocked login attempts.
    • Account protection: on/off.
    • Downtime monitoring: on/off, email alerts, and the last downtime.
    • Secure sign-on: on/off, match accounts by email, and require two-step authentication.
  • Scan results. The existing packages/scan threat list and history, reused as-is. Sites without Scan get a plan notice instead of the list's misleading "You're set up" empty state.
• A primary Scan now button in the page header. It is hidden when the site has no Scan plan.
• The content column is the same width as the Jetpack AI page (708px).
• There is almost no new backend. The page uses existing endpoints:
  • jetpack/v4/module/* (toggles and /data)
  • jetpack/v4/settings
  • jetpack/v4/waf
  • jetpack/v4/site/scan/*
• The module registers the Scan package's REST routes, because they are normally gated behind rsm_jetpack_ui_modernization_scan. Plugin and theme counts and Waf_Stats::get_blocked_requests() have no REST endpoint, so they are passed to the page as data at render time.

Screenshots

Overview, using Scan's mock data (&jps-mock=1) to show a site with Scan:

Overview on a site without a Scan plan:

Scan results on a site without a Scan plan:

Open questions and known gaps

• Naming. The existing protect module is Brute Force protection, and My Jetpack's Protect product points at it. The new module shows as "Protect" in WP-CLI, which is easy to confuse with it.
• Where the code lives. This spike puts the route in the Jetpack plugin and deep-imports @automattic/jetpack-scan-page/src/js/*. A shared package would let the standalone Protect plugin adopt the same page.
• "Files scanned" isn't available. The WordPress.com scan API returns no file count.
• Firewall block counts are read once, when the page loads, so they need a reload to refresh.
• The Scan results tab lost its "Auto-fix N threats" header button. It is replaced by the single primary Scan now button.
• js-packages/scan produces two CSS 404s. threats-data-views/styles.module.scss uses a plain @import "*.css", which Sass leaves as a runtime URL. This is existing code and also affects the standalone Scan page.

Related product discussion/links

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

No. The page reads existing module, settings, firewall and scan data through existing endpoints. The Scan now button reuses the Scan package's existing jetpack_scan_scan_now Tracks event.

Testing instructions

• Build the Jetpack plugin from this branch, e.g. jp build plugins/jetpack --deps, then connect Jetpack.
• Activate the module with wp jetpack module activate protect-dashboard. If it is missing from the module list, run wp eval 'Jetpack_Options::delete_option("available_modules");' first.
• Confirm Jetpack › Protect appears in the sidebar. Deactivate the module and confirm the item disappears; then reactivate it.
• Open Jetpack › Protect:
  • Toggle each feature and confirm the change sticks after a reload and matches wp jetpack module list.
  • With the firewall on, confirm the blocked-request tiles and the "Rules last updated" tile appear.
  • With Downtime monitoring and Secure sign-on on, toggle their sub-settings and reload.
  • Turn on the allow list, add an IP, click Save IP lists, and reload.
• On a site without Scan, confirm the Scan box shows what would be checked plus an upgrade notice, and that Scan results shows the plan notice.
• Add &jps-mock=1 to the URL to preview the page with Scan data. The Scan now button and the threat counts should appear.

[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 or WordPress.com Site Helper), and enable the add/jetpack-protect-module branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack add/jetpack-protect-module

bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/jetpack-protect-module

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:

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]

Code Coverage Summary

Coverage changed in 2 files.

File	Coverage	Δ%	Δ Uncovered
projects/js-packages/scan/src/components/threats-data-views/index.tsx	67/130 (51.54%)	0.36%	1 ❤️‍🩹
projects/plugins/jetpack/modules/module-headings.php	1142/1178 (96.94%)	0.06%	0 💚

9 files are newly checked for coverage. Only the first 5 are listed here.

File	Coverage
projects/plugins/jetpack/_inc/client/protect-dashboard/data.ts	0/33 (0.00%) 💔
projects/plugins/jetpack/_inc/client/protect-dashboard/index.tsx	0/17 (0.00%) 💔
projects/plugins/jetpack/_inc/client/protect-dashboard/overview.tsx	0/75 (0.00%) 💔
projects/plugins/jetpack/_inc/client/protect-dashboard/scan-tab.tsx	0/33 (0.00%) 💔
projects/plugins/jetpack/_inc/client/protect-dashboard/security-box.tsx	0/9 (0.00%) 💔

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.}