Email Library

[lonnieezell]

The email library is in drastic need of some refactoring. Here's my thoughts:

• MUST support multiple drivers, including mail, sendmail, smtp, log (for simply saving the generated emails to the writable directory), and for a few services like MailTrap.io, MailGun, Postmark or Mandrill.
• We can simplify things and make a Mailer class the single point to manage everything about that email, including which views are used, default from values, etc. This also gives us the power to really customize the emails if we need to by tapping into any part of the application to gather data and display it correctly, etc
• MUST be able to easily queue the emails to be sent at a later date, and/or throttled. This would integrate with the Queue System that is already planned.

In your controllers, when you need to send an email, it would be as simple as:

(new App\Mail\NewUserWelcomeEmail())
    ->to($user->email, $user->name)
    ->send();

[sv3tli0]

Will it be possible to add SignedBy(encrypted) method to all other standard things?
I think that it may be helpful if an app can send signed mails in some cases ..

[lonnieezell]

Will it be possible to add SignedBy(encrypted) method to all other standard things?
I think that it may be helpful if an app can send signed mails in some cases ..

No promises, but I can look into it.

[ivantcholakov]

bcit-ci/CodeIgniter#3626

[saifulnizamnordin]

@lonnieezell should we use many service as you state? but we target simple. I think the better one

(new App\Mail\NewUserWelcomeEmail()) ->to($user->email, $user->name) ->send($service);

service we can make it null refer to default library. the rest depend on service. etc mailgun postmark ...

[lonnieezell]

@aa6my Services are pretty simple, and they make customizing everything much easier. That said, I'm definitely NOT happy with the email library at the moment, which is part of why it's been sitting for a bit while I work on other parts. :)

The original intent was to do it much like a number of other services, where there's a helper method, so it would look like this:

mailer(new App\Mail\NewUserWelcomeEmail())
    ->to($user->email, $user->name)
    ->send();

So it's very similar to what you've specified. And the problem with passing the service in at that point, is that should you ever change who you're sending email with (which could happen relatively often throughout the lifespan of projects) you have to change it at every location. By making it a service, you only have to change it in the Services config file and everything works.

The goal for has always been to make App\Mail\NewUserWelcomeEmail() the one place where all of the truth for the message is, all of the headers, addresses, subject line, etc. Thinking on this a little more today, and on something that @sv3tli0 mentioned on the forums a little while back, I may have another idea worth exploring:

The mail file is still the location of truth. But we can have services you declare in it, like Mailable, Pushable, SMSable, which provide the delivery methods. So, if you want the message to be sent by email, you'd make sure the class used the Mailable trait which provides a mail() method. If you sometimes wanted to mail something and sometimes need to push it via a cellular push notification (like when the system has major issues) you could use both Mailable and Pushable and could use mail() and push() as possible delivery methods. And queue() should always be available to add it to a queue to be dealt with asynchronously.

[saifulnizamnordin]

@lonnieezell thanks for explaining for me. Actually i like this part

The mail file is still the location of truth. But we can have services you declare in it, like Mailable, Pushable, SMSable, which provide the delivery methods. So, if you want the message to be sent by email, you'd make sure the class used the Mailable trait which provides a mail() method. If you sometimes wanted to mail something and sometimes need to push it via a cellular push notification (like when the system has major issues) you could use both Mailable and Pushable and could use mail() and push() as possible delivery methods. And queue() should always be available to add it to a queue to be dealt with asynchronously.

After you start code it, i'll try assist as i can,

[lonnieezell]

I've tried planing this out, and it really doesn't work well. There's too many differences between what you would send as an email and a text/push message. I was getting a bit frustrated at that point, only to realize I had already solved much of this problem with SprintPHP. So, will be moving much of the methodology of that over and that should work out fairly nice.

[isantolin]

MUST support multiple drivers, including mail, sendmail, smtp, log (for simply saving the generated emails to the writable directory), and for a few services like MailTrap.io, MailGun, Postmark or Mandrill.

Amazon SES, Sendgrid too?

[ivantcholakov]

No, it won't happen. Ivan Tcholakov На 10.02.2017 в 13:31, Ignacio Santolin написа:

…

MUST support multiple drivers, including mail, sendmail, smtp, log (for simply saving the generated emails to the writable directory), and for a few services like MailTrap.io, MailGun, Postmark or Mandrill. Amazon SES, Sendgrid too? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#276 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABXxmMWuW_FxIHON1cPojo5pQzvaVurdks5rbEp1gaJpZM4KFjeF>.

[ivantcholakov]

@isantolin

Oh, sorry. I've answered here by a mistake. Ignore my previous post.

[mpmont]

Whats the general opinion on just using something like phpmailer/phpmailer?