Repository navigation
Conversation
…pack Protect plugin
Contributor
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
github-actions
Bot
added
[Feature] Protect Dashboard
[Plugin] Jetpack
Contributor
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
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:
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. |
Code Coverage SummaryCoverage changed in 6 files. Only the first 5 are listed here.
4 files are newly checked for coverage.
|
enejb
force-pushed
the
add/protect-dashboard-monitor
branch
from
October 6, 2026 00:55
a2e0ab7 to
7a7a9a5
Compare
enejb
force-pushed
the
add/protect-dashboard-monitor
branch
from
October 6, 2026 01:22
6ff6d1b to
9218a31
Compare
With the protect-dashboard module active and no standalone plugin, the link went to protect-details or Jetpack Cloud instead of the Protect page.
… retry A failed save no longer resets the IP list field to the saved value, and a failed settings load now clears its error on retry and offers a Try again button. Section types take an optional state type, the tab search param is narrowed at runtime, and the settings hook returns a stable object.
ProtectCard and CardRow keep their props and now render through Card from the WordPress UI package, so border, radius, background and header spacing come from the design system.
… section registry Adds routes/ to the client Jest roots so route tests run.
…to add/protect-dashboard-foundation
The base branch added a Jetpack_Protect_Dashboard_Test class of its own, so the section registry tests now live in that class and the threats test moves into the same suite directory.
…to add/protect-dashboard-foundation # Conflicts: # projects/plugins/jetpack/composer.lock
…' into add/protect-dashboard-monitor
My Jetpack no longer depends on the feature flags package, so the Jetpack plugin now reports the flag through jetpack_my_jetpack_protect_in_jetpack.
…to add/protect-dashboard-foundation
…' into add/protect-dashboard-monitor
Pass MonitorState to ProtectSection and DashboardContext now that they take a state type, and drop the casts.
enejb
force-pushed
the
add/protect-dashboard-foundation
branch
3 times, most recently
from
October 8, 2026 14:23
b531356 to
6567e4b
Compare
…d-monitor # Conflicts: # projects/packages/my-jetpack/src/class-main-features.php # projects/packages/my-jetpack/src/products/class-protect.php # projects/packages/my-jetpack/tests/php/Protect_Product_Test.php # projects/plugins/jetpack/_inc/lib/class-jetpack-protect-dashboard-feature-flags.php # projects/plugins/jetpack/composer.json # projects/plugins/jetpack/composer.lock # projects/plugins/jetpack/modules/protect-dashboard.php # projects/plugins/jetpack/tests/php/_inc/lib/Jetpack_Protect_Dashboard_Feature_Flags_Test.php
Refuse the uptime route while Monitor is off, drop the cached history when Monitor is toggled, wait for a Monitor save before fetching, count the days actually returned in the heading, keep the bars visible in forced-colors mode, and declare the connection package dependency.
kraftbj
marked this pull request as ready for review
October 8, 2026 16:43
kraftbj
added
[Status] Needs Review
Re-read the email setting after Monitor is turned on, lock the email toggle for users without a WordPress.com connection, clear the cached history from any Monitor toggle, stop one user's refused request from being cached for every admin, make the day summary translatable as a whole, and cover the route's permission check and the card's remaining states in tests.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes JETPACK-2933
Part of JETPACK-2887
Proposed changes
packages/protect:src/sections/class-monitor.php: state is the Monitor module'savailable/active, the number of days shown and whether the current user is connected to WordPress.com, and a newGET jetpack/v4/protect-dashboard/uptimeroute returning{ days, isUp }. It asks WordPress.com (as the connected user) for 90 days ofjetpack-monitor-uptime, keeps the newest 40 valid days oldest-first as{ date, status, downtimeInMinutes }, and reads the current status fromjetpack-monitor-status(isUp: true / false / null). Results are cached for 10 minutes; failures and unknown status for 1 minute. The cache is dropped when Monitor is turned on or off, by any route. A 401 or 403 from WordPress.com is not cached, since it is about one user's token.routes/dashboard/sections/monitor/: an Overview card with one bar per day (UTC days, localized dates; down days striped, no-data days shorter), a visible "X days up, Y days down, Z days with no data" summary and a screen-reader list of every day, a current-status badge (Operational / Down / Status unknown / Off / Unavailable) and a link to Settings. A Settings card with the "Monitor your site for downtime" toggle and the "Email me…" toggle, which is disabled while Monitor is off or when the user has no WordPress.com connection. Turning Monitor on re-reads the email setting, because activation subscribes the user on the server. Both cards respectavailable.packages/protectnow requiresautomattic/jetpack-connectiondirectly, since the section uses the connection client.Dashboard_Testno longer assumessrc/sections/is empty, so the tests keep passing as real sections land.Related product discussion/links
Does this pull request change what data or activity we track or use?
No. It reads the site's existing Monitor uptime history from WordPress.com.
Testing instructions
wp companion feature-flag enable jetpack-protect-dashboard(or thejetpack_feature_flag_enabled_jetpack-protect-dashboardfilter)wp eval 'Jetpack_Options::delete_option("available_modules");'thenwp jetpack module activate protect-dashboardwp jetpack module activate monitor).admin.php?page=jetpack-protect).wp --user=<admin> eval '$r = rest_do_request( new WP_REST_Request( "GET", "/jetpack/v4/protect-dashboard/uptime" ) ); echo wp_json_encode( $r->get_data() );'returns{ "days": [...40], "isUp": true }.Screenshots
Overview card on a site where Monitor was just turned on, so most days have no data:
Site down, with sample history (the WordPress.com answer was substituted on a test site to show down days):
The same card in forced-colors mode:
WordPress.com unreachable, or the user not connected:
Settings card:
Settings card for an admin with no WordPress.com connection:
