On 03/25/2014 04:50 PM, Johannes Schlüter wrote:
On Tue, 2014-03-25 at 13:51 -0400, Gary Mort wrote:
Sending mail is just passing a stream of bytes to a stream. That stream
could be an SMTP server, it can be an executable program, or it can be a
file.
Even that is not that easy, as Rasmus wrote.
Frameworks are encouraged to subclass MailMessage and extend it's
functionality to suite their requirements - ie if they to synchronize
the header property with the recipients/from/subject properties they are
free to do so - there is no rule/standard saying they cannot.
So frameworks should still contain their own mail classes working
differently? So this is neither solving the sending problem nor the
"it's different everywhere" problem.
Yes, frameworks should still contain their own mail classes - the issue is not that they have them, but that PHP Applications[as opposed to frameworks] such as Drupal, Wordpress, and Joomla require application specific code to perform the simple task of sending e-mail.
At the moment the mail() function is almost useless because it cannot be assumed work - on windows it is likely to generate an error. On Linux it depends on if sendmail/postfix/etc are configured. Make it a handler with a sane default setting and then it can be trusted.
Take writing a simple "contact us" form processor. A theoretical contact form could have fields for:
Category of Problem, $category
Summary of Problem, $summary
Full details of Problem, $details
Who it is to be sent to is pre-defined. Subject is pre-defined.
It only takes a few lines to send this e-mail:
$message = <<<EOT
Category: $category.\n
Summary: $summary.\n
Details: $$details.\n
EOT;
mail($to, $subject, $message);
I would guess that over half of all sending of e-mail can be accomplished with these types of simple steps.
Instead, for some applications like drupal you have to use the relatively simple:
drupal_mail($module, $key, $to, $language, $params = array(), $from = NULL, $send = TRUE)
https://api.drupal.org/api/drupal/includes!mail.inc/function/drupal_mail/7
Joomla is more complex with a nice OO interface:
http://docs.joomla.org/Sending_email_from_extensions
$mailer = JFactory::getMailer();
$mailer->addRecipient($to);
$mailer->setSubject($subject);
$mailer->setBody($message);
$mailer->send();
By making it possible to register a mail handler, a Drupal website merely has to call:
set_mail_handler(
function ( $to , $subject , $message ) {
$module = 'drupal';
$key = unique();
$language = language_default();
$params = array('body' => $message);
return drupal_mail($module, $key, $params);
return strtoupper($match[1]);
}
);
And all simple e-mail can now be generated and sent with the PHP mail function, rather then requiring custom use.
A Joomla website would just call:
set_mail_handler(
function ( $to , $subject , $message ) {
$mailer = JFactory::getMailer();
$mailer->addRecipient($to);
$mailer->setSubject($subject);
$mailer->setBody($message);
return $mailer->send();
}
);
The basic concept here is to not require application developers to keep changing how they write code based on the underlying application - instead always use basic PHP function unless your needs go beyond that.
IE $myvar = _SESSION['somekey'] is the best way to retrieve session data. The framework/application can use the SessionHandler functionality to implement specific custom methods of dealing with session data. The Session Handler can deal with sanitizing/filtering data.
$filedata = file_get_contents($filepath) is the best way to get the contents of a file. Don't worry about if the file is local, from the web, stored in some weird virtual file system, etc. The Framework/Application can use Stream Handlers to deal with oddball situations.
Sending an e-mail message is a basic requirement for PHP, as such mail() should be the preferred method of doing so. If you have custom formatting needs, then use a library to format the e-mail message.
Consider this list itself, it's using an archaic web interface[ezmlm] because to implement an email list in /any/ language requires a stupid amount of work.
When this list receives an e-mail message, it has to loop through a list of all subscribers and: skip subscribers who are set to nomail, add it to a periodic digest for subscribers who are set to digest, send it directly to subscribers who want mail immediately.
Using registered e-mail handlers, in PHP this becomes a simple process:
foreach ($subscribers as $recipient)
{
mail($recipient, $subject, $message);
}
All the heavy lifting is offloaded to the Mail Handler, which is only required to deal with one thing - delivering e-mail. A hypothetical list handler would check the subscriber database for the recipient, if the recipient is set to nomail it can return immediately, if the recipient is in digest it can append queue it for a future digest generator, and if the recipient is immediate invoke the default PHP mail handler.