My goal for a recent project was to setup a way to send reliable, custom emails each time a new WordPress post is published. Sadly, that rules out leveraging Jetpack because its email templates cannot be customized. Enter MailPoet, arguably one of the most feature rich freemium newsletter and email plugins for WordPress.
Email, especially WordPress email, is a tough beast to tackle, and a reliable method to email WordPress posts to subscribers can prove elusive. Many emails get flagged as spam or are rejected entirely and rendered undeliverable. Read more about how Mandrill makes quick work of increasing your WordPress email deliverability using the same engine that powers MailChimp. Best of all, the Mandrill development team created a free plugin to integrate Mandrill with WordPress: wpMandrill.
Enter Mandrill & MailPoet
Daniel Klose wrote a great tutorial on how to setup Mandrill and MailPoet to send free newsletters with WordPress. Although it doesn’t discuss why you might want to do that, it’s a great starting point if your WordPress site will involve voluminous transactional emails—new post notifications, membership confirmations and notices, invoices, shipping updates, etc. Basically any automated emails you plan to send are good candidates for deliverability issues which Mandrill aims to reduce significantly.
Shared Hosting Problems
Klose’s MailPoet and Mandrill tutorial configures MailPoet to use Mandrill via SMTP. Unfortunately, many shared hosts block the ports required for WordPress to connect with an external SMTP server, which is where I ran into difficulty. MailPoet does offer the ability to send emails through GMail, but it’s recommended to have a paid GMail account if you plan on significant email volume, which wasn’t exactly keeping in the spirit of sending free newsletters reliably for my budget-minded client.
MailPoet comes with the native ability to use PHP’s
sendmail() functions, claiming the functions work on 95% and 5% of servers respectively. I think we can do better than that. So I dug around…
wpMandrill actually “intercepts” WordPress’s mail function and uses the Mandrill API instead. Unfortunately, this only works when we call WordPress’s own mail function (
wp_mail()). MailPoet does not provide us with the ability to use
wp_mail(), so it looks like we’re stuck. Or are we?
I sifted through the MailPoet code and found an interesting line:
'allow_wpmail' => false1
After some more digging, I noticed that the complete infrastructure is in place to enable MailPoet to send emails with
wp_mail(), which could then magically be intercepted by wpMandrill—all without the need to pay for GMail or a VPS! A quick consult with the MailPoet support team led me to create a function which enables
wp_mail() in MailPoet and remains update proof. So I added this to my
|$model_config = WYSIJA::get('config','model');|
|$model_config->save(array('allow_wpmail' => true));|
Now when we go to the settings (MailPoet->Settings->Send With…->Your own website) we see the two default options are now three beautiful options:
Choose WP Mail, save the settings, and send yourself a test. Now you should be off and running, ready to email WordPress posts to subscribers with Mandrill and MailPoet on your shared host, even if your outgoing ports are blocked!
Thanks to MailPoet and Rafael for helping me navigate the MailPoet codebase.
This function makes it possible to adjust any of the parameters in the MailPoet
$defaults array2. Some of them are a bit cryptic, so the MailPoet support desk was kind enough to provide more details on the MailPoet hidden options. Just be sure to test your settings on a non-production installation first!