And here’s the first worm, as promised...
In all fairness, Swift is a much better written piece of software, but it’s overkill for what is needed in the core of MODx. This is precisely why I chose to create a generic MODx API to abstract any direct calls to PHPMailer functions, SwiftMailer functions, or plain old mail(), without limiting access to more advanced functions from whichever mailer you may prefer to use for your add-ons that need to. As an example from 0.9.7 code...
<?php
// This line gets an instance of the configured mailer implementation
// and adds it to the $modx object, similar to 0.9.6.x extenders (hint, hint)
$modx->getService('mail', $modx->config['mail.className']);
// Set some attributes common to any mailer
$modx->mail->set(MODX_MAIL_SUBJECT, 'My Email Subject');
$modx->mail->set(MODX_MAIL_FROM, '[email protected]');
$modx->mail->set(MODX_MAIL_BODY, 'This is a message.');
// Set addresses
$modx->mail->address('to', '[email protected]', 'Full Name');
$modx->mail->address('reply-to', '[email protected]', 'Full Name');
// Set some custom headers (maybe?)
$modx->mail->header('X-Mailer: modMail prototype');
// And send it...
$modx->mail->send();
?>
This code could load whatever derivative class of modMail you wanted, via system settings, or a parameter. That class would be responsible for implementing the modMail function calls using the mailer engine you wanted, and you could still get access to the mailer directly via $mail->mailer->PHPMailerSpecificFunction().
You can see the beginning of this implemented for 0.9.7 at
http://svn.modxcms.com/svn/tattoo/tattoo/branches/0.9.7/core/model/modx/mail/. It still needs some work, and I need to make sure Swift will work well with this before I set the API in stone, but it might make a good extender ($modx->mail) for the 0.9.6.x branch; that way component developers for 0.9.6.x and 0.9.7 have one less things to migrate.
MODX Staff
☆ A M B ☆
