Opened 23 months ago
Last modified 17 months ago
#47050 new defect (bug)
Recovery Email - Keep consistent newline spacing around ###CAUSE### mergetag
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | minor | Version: | 5.2 |
Component: | Site Health | Keywords: | has-patch dev-feedback needs-testing |
Focuses: | ui-copy | Cc: |
Description
Hello,
While translating I came to the recovery email which uses several mergetags. They're all surrounded by empty lines with the exception of ###CAUSE### which I felt odd.
Current Email;
Howdy!↵ ↵ Since WordPress 5.2 there is a built-in feature that detects when a plugin or theme causes a fatal error on your site, and notifies you with this automated email.↵ ###CAUSE###↵ First, visit your website (###SITEURL###) and check for any visible issues. Next, visit the page where the error was caught (###PAGEURL###) and check for any visible issues.↵ ↵ ###SUPPORT###↵ ↵ If your site appears broken and you can't access your dashboard normally, WordPress now has a special "recovery mode". This lets you safely login to your dashboard and investigate further.↵ ↵ ###LINK###↵ ↵ To keep your site safe, this link will expire in ###EXPIRES###. Don't worry about that, though: a new link will be emailed to you if the error occurs again after it expires.↵ ↵ ###DETAILS###
Code Reference - https://build.trac.wordpress.org/browser/trunk/wp-includes/class-wp-recovery-mode-email-service.php?marks=134#L139
Opening this ticket to introduce empty lines around ###CAUSE###
The cause strings I found are;
"In this case, WordPress caught an error with one of your plugins, %s."
"In this case, WordPress caught an error with your theme, %s."
Both could use the space and not be sandwiched between the first two large paragraphs.
Cheers
Attachments (2)
Change History (12)
#2
follow-up:
↓ 3
@
23 months ago
This is intentional, as the cause can also be empty, so we don't want masses of whitespace in the email if there's no cause listed.
I'm fine with reworking the email text to make it consistent, but that needs to be taken into account.
#3
in reply to:
↑ 2
@
23 months ago
- Severity changed from normal to minor
Replying to pento:
This is intentional, as the cause can also be empty, so we don't want masses of whitespace in the email if there's no cause listed.
I'm fine with reworking the email text to make it consistent, but that needs to be taken into account.
Thanks @pento I didn't realize there was the case of an empty cause when $extension isn't set (I've moved this down to minor). I do wonder if a 'Unknown Cause' string could be more useful than no cause. Or possibly reworking the cause section in a future iteration to provide a 'Cause: ' prefix on it's own line and either supply the cause or an 'N/A' (or Unknown).
*If this type of prefix is used then the existing cause strings won't need the verbose 'In this case, ' prefix.
Cheers
#5
@
22 months ago
- Keywords needs-refresh added
- Milestone changed from 5.2.1 to Future Release
This still needs more work. Since it's a minor
severity, let's move it to Future Release and it can be milestoned whenever it becomes ready.
#6
@
19 months ago
- Focuses ui-copy added
- Keywords dev-feedback needs-testing added; needs-refresh removed
- Milestone changed from Future Release to 5.3
In 47050.2.diff I've introduced consistent new line around CAUSE and ensured there's always a string inserted. When no cause is know I used the following verbiage;
In this case, WordPress caught an unknown error.
#7
@
19 months ago
I think this path is only triggered if it happens in Core, which isn't unknown, it just doesn't have a relevant cause.
I don't recall the original discussion around why the error details weren't include for Core errors: it'd be worth looking at that, and seeing if there's a way we can get that information.
Introduce empty lines around ###CAUSE### in recovery email