[wp-trac] [WordPress Trac] #46898: WSOD Protection: Finalize email language

[WordPress Trac]

#46898: WSOD Protection: Finalize email language
-------------------------------+-----------------------------
 Reporter:  TimothyBlynJacobs  |       Owner:  SergeyBiryukov
     Type:  defect (bug)       |      Status:  reopened
 Priority:  normal             |   Milestone:  5.2
Component:  Administration     |     Version:  trunk
 Severity:  normal             |  Resolution:
 Keywords:  servehappy         |     Focuses:
-------------------------------+-----------------------------

Comment (by TimothyBlynJacobs):

 I'm +1 to any language changes, just wanted to provide technical clarity.

 > Additionally, sending the email every 4 hours feels overly aggressive.
 Could someone point me to the original discussion on the link timeout, and
 why 4 hours was chosen?

 > Also, I saw this email being triggered by a cron task, which seems
 overly obtuse. At most the site owner would want to report that error to
 the plugin author, not take immediate recovery action.

 The email isn't triggered by a cron task. It's sent whenever the fatal
 error happens immediately and if the error continues to happen, it will
 send a new recovery mode link at most every four hours.

 The original timeout was one hour, but was revised in this slack
 discussion:
 https://wordpress.slack.com/archives/C60K3MP2Q/p1550761315015300 and
 discussed briefly in other meetings.

 The trade off being you don't want to bombard the user with emails, but
 you don't want to make the timeout between emails so long that getting to
 the recovery mode link would be very difficult.

 > "This link expires in 4 hours" inspires artificial urgency

 Right now, the link itself is valid only for four hours. We could
 dramatically increase this, perhaps to 7 days, such that it isn't
 necessary to mention.

 > The "Error Details" section is entirely unnecessary for the vast
 majority of site owners.

 This was added because we don't store the error server side until the user
 engages in recovery mode. So it provides parity with the stack trace that
 is shown in wp-admin. That being said, I'm fine with completely removing
 it, or including it on `WP_DEBUG_DISPLAY` like you mentioned. Perhaps also
 a way to filter on?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46898#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform