#39110 closed enhancement (fixed)
Better error handling when email cannot be sent during password reset
Reported by: | johnbillion | Owned by: | johnbillion |
---|---|---|---|
Milestone: | 5.3 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Site Health | Keywords: | has-patch servehappy has-screenshots |
Focuses: | Cc: |
Description
If an email cannot be sent during a password reset (due to server misconfiguration etc), this is potentially a blocker for the user. Currently the user is presented with the message:
The email could not be sent.
Possible reason: your host may have disabled the mail() function.
This is a dead end and there's no suggested next action for the user. There's a good chance that this is the first time the user has been made aware that their server is unable to send emails.
A few things could be done to make this situation less painful, or avoid arriving at this situation in the first place.
- During installation, if the
New WordPress Site
email fails to send then a flag should be set which triggers a dismissable notification in the admin area stating that outgoing emails don't appear to be working, with a link to some documentation on the subject. - During password reset, the
The email could not be sent
error message should be presented in a nicer format (possibly returning aWP_Error
fromretrieve_password()
instead of triggering awp_die()
) and should have some more helpful information, including a link to external documentation.
Attachments (3)
Change History (23)
#2
follow-up:
↓ 3
@
7 years ago
- Milestone changed from Awaiting Review to 5.0
- Summary changed from Better error handling when emails cannot be sent (specifically during password reset) to Better error handling when email cannot be sent during password reset
I like this change, @neelpatel7295.
#3
in reply to:
↑ 2
@
7 years ago
Replying to johnbillion:
I like this change, @neelpatel7295.
Thanks for your appreciation, actually i didn't found any documentation link which relevant to how to solve such problem. Also currently focusing on the first point and definitely provide related solution soon.
#4
@
6 years ago
- Keywords ux-feedback removed
@neelpatel7295 your patch seems to solve the issue. A correction in the language
Email cannot be sent. Please check your hosting server have enabled the mail() function()
Make sure it says: "HAS enabled" not "HAVE enabled"
#6
@
6 years ago
- Keywords needs-refresh added
- Milestone changed from 5.1 to 5.2
39110.patch needs updating to apply cleanly against trunk.
#9
@
5 years ago
- Keywords needs-refresh removed
39110.2.patch improves the terminology used in the error message and adds a localised link to the support article on resetting your password. This removes the dead-end nature of this error, and provides the user with some alternative methods for resetting their password.
#11
@
5 years ago
This is looking good. I have a few thoughts on 39110.2.patch, though.
- At first glance, I would think that
email_disabled
is an error passed from a function likewp_mail()
to indicate e-mails were intentionally disabled. Maybe the error code could bereset_email_failure
, or something more specific to the action taking place (unless this same message can be triggered somewhere else and should be a bit more global feeling).email_disabled
could also be an error in plugin land somewhere. - The wording still feels awkward to me. I think that having
Possible reason:
sandwiched between too proper sentences is throwing me off.
I also don't think that the message even needs to mention a server. Maybe something less technical could suffice.
Worked through this with @johnbillion in Slack and we arrived at: Error: The email could not be sent. Your site may not be correctly configured to send emails. Get support for resetting your password.
(with the current bold/linking).
#13
@
5 years ago
- Resolution set to fixed
- Status changed from new to closed
Closing this as fixed. If someone feels like picking up the email failure detection piece that I mentioned in the description then feel free to open a followup ticket.
#14
@
5 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
e-mail
should be standardized to email
, see [33774].
#15
@
5 years ago
Huh. I did think that we'd standardised on email
over e-mail
. Turns out I was running English (UK)
locally which uses e-mail
.
#16
@
5 years ago
- Owner set to johnbillion
- Resolution set to fixed
- Status changed from reopened to closed
In 45405:
#17
@
5 years ago
Note: The same string is also used in WP_Recovery_Mode_Email_Service::maybe_send_recovery_mode_email().
It should probably be updated as well for consistency, but that depends on where it is displayed and whether it supports HTML. Related: #47255.
#18
@
5 years ago
but that depends on where it is displayed and whether it supports HTML
The WP_Error
returned by the email service is not currently displayed anywhere. However, I'd expect that to change when #47192 lands. I think HTML could probably be supported in that context, but @spacedmonkey would have a better idea.
I have done the half of job, added a patch related not die the . instead of
I have done the half of the work. I have added a patch related it will not die when displaying the message like "The email could not be sent". Instead of it will stay on same page and displaying the error message.