Recovery Email - Keep consistent newline spacing around ###CAUSE### mergetag

[garrett-eclipse]

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

[garrett-eclipse]

Introduce empty lines around ###CAUSE### in recovery email

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

[garrett-eclipse]

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

[desrosj]

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.

[garrett-eclipse]

Refreshed patch to add unknown cause string

[garrett-eclipse]

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.

[pento]

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.