Add Custom Description for Rollback Fixer

[jwidavid]

Changes proposed in this Pull Request

• Jetpack Scan provides customized descriptions of how it will fix a threat. This PR adds a custom description for fixing threats with a "rollback".
  Example: Jetpack Scan will rollback the affected file to the version from January 8, 2021, 3:40 am.

Testing instructions

• Use a test site with backup and scan plans
• Ensure the site has at least one successful, full backup
• Using the Threat Tester Plugin on your test site - add a "infect a file" threat. (You can get the plugin here)
• Run calypso locally and initiate a scan of the test site
• Verify that the threat was discovered and that a Fix is available
• The description of the fix should read something like Jetpack Scan will rollback the affected file to the version from <date-and-time>.

[matticbot]

Test live: https://calypso.live/?branch=add/custom-message-for-rollback-fixer

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~44 bytes added 📈 [gzipped])

name  parsed_size           gzip_size
scan       +239 B  (+0.1%)      +44 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[singerb]

Tagging Voyager in too, although this is a small change.

[singerb]

Confirmed in wpcom\public_html\wp-content\lib\vaultpress\threat\class-threat.php that we're translating to real dates for the API, so simply displaying the target here is ok without the need for more parsing. Fine from my end.

[mattgawarecki]

@singerb @jwidavid Will those dates from the API automatically come back in a locale-appropriate format for the user? I changed my WordPress.com account to use Japanese, but the timestamp still appears on the page for me as US-formatted.

[mattgawarecki]

I should note that, other than the date format, everything showed up correctly for me. I'm sure our customers will appreciate this once it's merged 👍

[singerb]

@singerb @jwidavid Will those dates from the API automatically come back in a locale-appropriate format for the user? I changed my WordPress.com account to use Japanese, but the timestamp still appears on the page for me as US-formatted.

No, it's a straight gmdate call with a format string. Since it's in WPCOM code we should be able to make it use locale-aware functions; I'm terrible at catching/doing things like that.

[mattgawarecki]

If it's fixable in the back end without a ton of effort, I don't see any reason to hold up this PR. At worst, the date format will be incorrect for a bit. Approving for my part, but what do y'all think?

[singerb]

Yes; it's better than the default fixer message and the date change should be able to be just swapping to use date_i18n() on the backend (https://developer.wordpress.org/reference/functions/date_i18n/ which I see used in WPCOM already).

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/5428521

Hi @jwidavid, could you please edit the description of this PR and add a screenshot for our translators? Ideally it'd include all of the following strings:

• Jetpack Scan will rollback the affected file to the version from %(version)s.
• Jetpack Scan will rollback the affected file to an older (clean) version.

Thank you in advance!

[a8ci18n]

Translation for this Pull Request has now been finished.