Re-routing emails to a development email address with php and SwiftMailer
Swift Mailer is a php library that automates and makes sending emails from php scripts a breeze. It is feature rich and in my opinion the best mail library available for php.
One of the things I like about it is it’s plugin architecture, it is simple to use and super simple to implement your own plugins. Swift Mailer comes packaged with a set of useful plugins however it was missing something that I have used in scripts previously, that is the ability to intercept emails before they are sent and send them to a different email address.
The reason for doing this is simply a development and debugging process. I like to set my development environment up so I can route all emails that the eventual live site will send to a development address. That way as I’m testing I can register email addresses on the development site as firstname.lastname@example.org, then when I test the site and an email gets fired off it will send to a “debugging” email address that I specify (eg. email@example.com). Then when the site goes live I switch the debugging off so all emails will get sent to their relevant recipients.
This is really useful if the site you are developing has lots of different users/emails that it needs to send, such as forums and notifications, or if the data you are using comes from a real source and you don’t want to spam a set of real email addresses with your test emails.
With all this in mind the solution was simple – to write a Swift Mailer plugin. You can download the Intercept plugin here. To install you simply need to drop the file into your Swift plugins directory (SwiftDirectory/lib/Swift/Plugins/InterceptPlugin.php)
To use it you just need to register the plugin and set the email address you want to route emails to instead of their original destination.
// require the Swift library require_once('Swift-4.0.6/lib/swift_required.php'); // create the message and all other options as you would normally $message = Swift_Message::newInstance(); $message->setSubject('A message subject.'); $message->addPart('<strong>The message</strong>', 'text/html'); $message->setBody('The message'); $message->setFrom(array('firstname.lastname@example.org' => 'From Address')); $message->setTo(array('email@example.com', 'firstname.lastname@example.org')); $mailer = Swift_Mailer::newInstance(Swift_MailTransport::newInstance()); /* Here we register the plugin with a new instance of Swift_Plugins_InterceptPlugin. The only parameter the constructor takes is the debugging email address this plugin MUST BE THE LAST plugin registered as it changes the 'to' field of the email so if you are using the decorator plugin for example it will * disrupt the way that works and your emails won't be decorated properly. */ $mailer->registerPlugin(new Swift_Plugins_InterceptPlugin('email@example.com')); // send as you would normally $mailer->batchSend($message);
Obviously a good idea would be to set up a switch within your own system that sets whether you use this plugin or not depending on if the code is being executed within a live or development environment.
- Using Swift Mailer plugins with Laravel 4
- Using Selenium Server 2 and PHPUnit to automate browser acceptance testing
- Laravel 4 First Thoughts
- UK Data.gov Property Price Mash Up
- Problems embedding true type fonts with TCPDF
- php $_FILES array shorter than expected and max_file_uploads sillyness
- Find and replace html links with PHP