Closed crstauf closed 4 years ago
MillerMedia
commented
4 years ago We have an email queue plugin that we use internally that we are going to investigate releasing as part of a fix rather than fully editing the code within the Mandrill plugin. Stand by for more details.
MillerMedia
commented
4 years ago Some thoughts on this:
Ideally, the fallback system is determinable and customizable by each site's developer. Giving developer(s) the option to write and use their own fallback system would allow the responsibility of continuing to process emails properly (given the various environments, scenarios, perspectives, and costs) to not rest solely on us. I'm not excusing us from all responsibility; I think the above mentioned fallbacks should be included with the plugin, but allow developers to also introduce their own system if they want to.
• There is a fallback in the plugin:
The action 'wp_mail_native' allows developers to custom a fallback action. As it currently is, when the Mandrill API call fails, it fails back to the native wp_mail function that can be overridden with that function.
• In this case, we could build a queueing system but the more we debated here, the more we realized that this will work as designed (falling back to wp_mail if Mandrill doesn't work). Of course wp_mail() is unreliable which is why people use Mandrill in the first place but this being a temporary outage I don't believe warrants a rewrite since it will perform as it is designed. A queueing system long-term would be gool, and we have one built that we can integrate but this will take quite a bit of QA'ing to get right and won't be a good solution for this week's outage considering the time frame.
• I suggest this. Worst case scenario is that it falls back to wp_mail() and then wp_mail() fails to send the email to the recipient. We have some suggestions that we are going to publish in a blog post which basically consists of:
1) Downloading the 'Email Log' plugin to at least catch all emails in the event they fail 2) Override it yourself using wp_mail_native 3) Download a patch email queue plugin that we are building that will be available for download from our site
I suggest we simply create an admin_notice that says:
"On Saturday, January 11th from 1am - 7am EST, the Mandrill email service will be upgrading its infrastructure and all emails sent through their service will fail. The 'Send Emails with Mandrill' plugin is currently configured to send mail through your normal WordPress server without any additional configuration. As a precaution, we have posted a blog detailing additional details actions you can take as precautions during this outage. Read more here: (link will be: https://www.millermedia.io/mandrill-outage-details-and-actions/ and link text will be 'Mandrill Outage Details and Actions)."
The post has not been published yet but that will ultimately be the URL to it.
@crstauf I have assigned you to this, let me know if the above sounds ok to you and if you want to handle making that admin notice. I suggest we do a date check as well and ensure that the admin_notice only shows if the date is before January 12, 2020 EST.
crstauf
commented
4 years ago @MillerMedia PR #53 created.
The impending Mandrill outage resulted in issue #51, and prompted some initial thoughts and discussion regarding a full and customizable fallback system.
@MillerMedia presented the following fallbacks:
wp_mail()usagewp_mail()native functionality.I propose that the second fallback be adjusted slightly:
The reason for my proposed change is to avoid sending emails out of the order that they're received. If we continue to attempt to send emails as they are requested, and when we get a successful connection we process the emails in the queue, then the first email to be sent after the outage will have been sent before the others, potentially disrupting the order of an email campaign or something of that nature. In most scenarios it's likely an edge case, but it's a pretty easy thing to solve for that I think it should be addressed.
Ideally, the fallback system is determinable and customizable by each site's developer. Giving developer(s) the option to write and use their own fallback system would allow the responsibility of continuing to process emails properly (given the various environments, scenarios, perspectives, and costs) to not rest solely on us. I'm not excusing us from all responsibility; I think the above mentioned fallbacks should be included with the plugin, but allow developers to also introduce their own system if they want to.
This doesn't need to be complex either: I'm thinking something similar to WordPress'
pre_hooks, that checks if there are actions on that hook, and runs the hooks until there's a successful response. Obviously a native hook won't work, because they would all run, but something similar to that I think would be simple and accomplish the objective.In the event that the plugin does need to fallback to another alternative, there should be an alert displayed in the WordPress admin, informing an admin of the following:
wp_mail(), or how many emails are currently in queue, etc)Ideally the alert's content and behavior is determined by the fallback being used, so if a developer implements their own fallback system, they can dictate the information that's shown.
Perhaps everything I've described is much too involved for this plugin's current usage and not deemed a priority; if that's the case, then I'll hope someone (including myself) gets bored or excited enough to to work on a PR for this. :)