scootergrisen wrote: ↑
Wed Jul 31, 2019 10:36 am
So i would like better message for the user to see on the page and better error messages in the log.
Overall, I'd say you're correct on all points: The message logged in the case of phpBB being configured to use PHP mail() is not useful. And it would be better if the user knew that phpBB already knew that their email did not succeed.
After digging into the code a bit more, I see there are essentially two reasons why the user will never see that error:
First, the default of phpBB is to "queue" the email rather than sending it directly and immediately, as controlled through the "Email package size:" setting in the ACP Email Settings page. When this configuration is set to a non-zero value (as it is by default), the "success" being seen when sending email is "successfully queued"
, not "successfully sent"
yet. phpBB will perform the actual email send at some other time, after the user has already left the email sending page and might not even still be using the site.
Second, although functions_messenger.php was tracking, logging and returning the failure status as described, this failure status is not
actually examined by the higher-level callers of the Messenger::send or Messenger::submit functions. So even if you did change the "Email package size:" to zero such that the mail was being sent synchronously, the high-level reaction shown to the user still wouldn't reflect the error status, just as you described. The error log message would still be the only evidence of failure.
Obviously the error log message could be improved relatively easily. So I would suggest keeping that proposal separate, since the idea really stands on its own, and there isn't really anything for someone to "be against." And since arguably, for most environments, notifying the administrator that an email failed "is enough", since it's not typical that "all email starts failing every day due to how much email was sent."
Suggesting that "the email sending failure should be surfaced back to the user" has many more challenges, only one of which is the whole "queuing" aspect mentioned earlier. But nonetheless, it still seems like a valid idea. You can expect some push-back on it, and perhaps reasonably so, since essentially you're looking to "design phpBB for the failure" of email that stops working every day due to usage. Rather than eliminating that failure, such that the condition of "email failure" moves back closer to being "a rare and administrator error log-only occurrence" as would probably be characterized by "most phpBB users."
But as David indicated, there is nothing you're able to do in standard phpBB settings in order to create either of those outcomes. Changing the "Email package size:" to zero moves the needle a little closer to where it could be "possible" to do something, but still ultimately does not help.