Added getMessage method to access Swift_Message

[markwilde]

I've added a method for read access to the Swift_Message instance. I needed it so I could reach into the transport adapter and pick out the Message-ID from the message once it had been delivered. Might be useful if there are any other headers etc to read once message has been sent.

I then was able to use the following to get what I needed from my controller once I'd delivered the message:

$message_id = null;

Mailer::applyFilter('deliver', function($self, $params, $chain) use (&$message_id) {
    extract($params);
    $result = $chain->next($self, $params, $chain);
    $message_id = $transport->getMessage()->getHeaders()->get('Message-ID')->getFieldBody();

    return $result;
});

[markwilde]

I've slightly updated this as I noticed the MessageID recorded was different to the one received on email. This is because SwiftMailer changes it once sent. There is now a new method called getMessageId() which stores the ID before the send. It allows you to access it using the following update to the code above.

$message_id = null;

Mailer::applyFilter('deliver', function($self, $params, $chain) use (&$message_id) {
    extract($params);
    $result = $chain->next($self, $params, $chain);
    $message_id = $transport->getMessageId();
    return $result;
});

[mariuswilms]

Why not have deliver() return the final ID on success and false if delivery failed? This way there's no additional method needed.

[eLod]

@markwilde not sure if i fully understand everything, but by looking at your code you set the $messageId before actually sending. also i don't really like the idea of having the last sent message sticked onto the transport. i would rather add filtering for creating the messages, also i'm open to discussion about the returned values from $transport->send(). i originally thought it would be nice to have back whatever the transport would return (e.g. this library is just a glue for the different adapters, which in turn depend on the mail sending php libraries - afaik swift for example returns the number of recipients), but it presents these kind of problems.

[markwilde]

@eLod I needed to collect the message ID before the send in SwiftMailer because it seems to generate the message id on the object before send, and once sent it changes it to a new id. I personally think that @DavidPersson idea of setting the message id on return for each adapter would probably be better for now on each adapter as li3_mailer needs to have a standard return from the send function so it's predictable what is being returned. Maybe even the li3_mailer Message object being returned with all the information would be better?

[eLod]

@markwilde what is changing the id? i don't think it's a good idea that the adapters return the message id, as you said, the message itself would be better (so you can look at the message id and any other attribute as well). that said the return value of the transport/send is still important, how else would you know if your message got sent actually (or know what error happened, if the return value indicates that, etc.)? the adapter could return you other information as well. so i would go with a composite return value.

[markwilde]

@eLod I think it is SwiftMailer and from what I could find it's to do with how it handles bulk message sending. Maybe the li3_mailer message object could contain attributes for error handling to that similar to how models handle errors? That way you could interrogate the message object to find out if it's been sent etc.