WordPress.org

Make WordPress Core

Opened 5 months ago

Closed 3 months ago

Last modified 3 months ago

#47681 closed enhancement (fixed)

Critical error handler needs to offer backup troubleshooting instructions in addition to email

Reported by: tobifjellner Owned by: SergeyBiryukov
Milestone: 5.3 Priority: normal
Severity: normal Version: 5.2
Component: Site Health Keywords: has-patch needs-testing
Focuses: Cc:
PR Number:

Description

https://build.trac.wordpress.org/browser/trunk/wp-includes/class-wp-fatal-error-handler.php?marks=173#L173 may show the message
The site is experiencing technical difficulties. Please check your site admin email inbox for instructions.
However: there are various reasons a rightful admin may not receive that email and therefore won't be able to follow those instructions.

Suggestion: Simply add "Or follow the debugging instructions in https://wordpress.org/support/article/debugging-in-wordpress/" (link should be translatable!)

This change needs for sure to be done in WP 5.3, but would be good to have already in a point release to 5.2 (and could could be seen as an error introduced with WP 5.2 – This particular message has generated a lot of questions over in the support forums.)

Attachments (4)

47681.patch (827 bytes) - added by dkarfa 5 months ago.
46881.patch (845 bytes) - added by dkarfa 5 months ago.
47681.1.patch (844 bytes) - added by Hareesh Pillai 5 months ago.
Minor change in capitalisation
47681.2.diff (909 bytes) - added by garrett-eclipse 5 months ago.
Re-use the 'Read about debugging in WordPress.' string and link from class-wp-site-health.php for this implementation

Download all attachments as: .zip

Change History (16)

This ticket was mentioned in Slack in #forums by tobifjellner. View the logs.


5 months ago

@dkarfa
5 months ago

#2 @SergeyBiryukov
5 months ago

  • Component changed from Bootstrap/Load to Site Health

#3 @SergeyBiryukov
5 months ago

  • Milestone changed from Awaiting Review to 5.3
  • Version changed from 5.2.2 to 5.2

#4 @SergeyBiryukov
5 months ago

Thanks for the patch, @dkarfa! Just noting that here is not a great link text for accessibility reasons, and should not be a standalone string. I'd suggest linking debugging instructions instead.

@dkarfa
5 months ago

#5 @dkarfa
5 months ago

Welcome, @SergeyBiryukov I made the change and update the patch.

@Hareesh Pillai
5 months ago

Minor change in capitalisation

@garrett-eclipse
5 months ago

Re-use the 'Read about debugging in WordPress.' string and link from class-wp-site-health.php for this implementation

#6 @garrett-eclipse
5 months ago

  • Keywords has-patch needs-testing added

Hello, thanks for the initial patches @dkarfa & @hareesh-pillai

I've uploaded 47681.2.diff to address this issue by reusing the strings and link setup found in class-wp-site-health.php.

I went this direction for a few reasons;

  • Doesn't introduce new strings.
  • Applies to both of the messages, original patch only applied to the $message when is_protected_endpoint()
  • Adds the external link icon, security noopener and accessibility text
  • Uses string placeholders properly with sprintf the original patches had placeholders but no printf function to apply them.
  • Drops the repetitive debugging instructions as it was twice in the second patch; once before the link and the second as the link text.

Please review & test. Thanks

This ticket was mentioned in Slack in #core-site-health by garrett-eclipse. View the logs.


3 months ago

#8 @SergeyBiryukov
3 months ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#9 @SergeyBiryukov
3 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 46151:

Site Health: Add a link to "Debugging in WordPress" support article to fatal PHP error handler's default message.

Props garrett-eclipse, tobifjellner, dkarfa, hareesh-pillai.
Fixes #47681.

#10 follow-up: @garrett-eclipse
3 months ago

Thanks for the commit @SergeyBiryukov checking the changeset I noticed the external link icon, security noopener and accessibility text were all dropped. Was that intentional? Do we not want this to open in a new tab like is done for the example same link in Site Health here;
https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-site-health.php#L1232-L1237

Appreciated, just want to be sure I understand what convention on links we want to go with moving forward.

Cheers

#11 in reply to: ↑ 10 @SergeyBiryukov
3 months ago

Replying to garrett-eclipse:

checking the changeset I noticed the external link icon, security noopener and accessibility text were all dropped. Was that intentional?

Thanks for bringing this up, I should have left a comment :)

In my testing by causing a fatal error in a plugin, neither Dashicons font nor .screen-reader-text styles were loaded, so (opens in a new tab) was displayed in plain text after the full stop, which looked weird.

I'm not sure if target="_blank" is really necessary here. We have a similar message without target="_blank" in _doing_it_wrong(), so I thought it would make sense to follow the same approach here, since the message is generally displayed in a context where Dashicons and .screen-reader-text styles are not available.

We could probably add them to _default_wp_die_handler() if you think it's necessary.

#12 @garrett-eclipse
3 months ago

Thanks @SergeyBiryukov I greatly appreciate the follow-up. That makse complete sense and I agree if the dashicons and styles aren't present that does present itself a little weird.

I like this convention it makes sense to me and don't really see the need in _default_wp_die_handler but will leave that open to those with more of an accessibility mind.

Cheers

Note: See TracTickets for help on using tickets.