Would Emails work as DataObjects?

[Jeremy Shipman]

I've been doing some work with sending emails after event sign-ups,
and the newsletter module.

I wonder if it would be handy for Emails to become DataObjects. They
are currently subclassed from ViewableData, therefore I don't think it
would be a huge jump to DataObject.

Pros:
- Less redundant email-specific code?
- Bounce handling can become more universal, and not so specific to
the Newsletter module. One email has many bounce records.
- Attachments (files) could be associated with emails. IE: one email
has many attachments.
- Store stats about the emails

Cons:
- Emails can be very template-specific. (Maybe the ability to
subclass will solve this, or the ability to choose a template for an
email)

Other:
- The CMS could have an Email interface for viewing all the bounced
emails & view open / click-through rates etc. (Similar to page
comment)
- Email could be associated to a group (like how newsletters are now)

Feel free to share your own pros, cons or thoughts.

[dalesaurus]

I think this is definitely a good idea, as a module. Moving the
management of email out this way would make integration of third party
SaaS backends easy (MailChimp, MyEmma, Brontomail, etc). Those
services tend to have a different schema and approach to user data/
emails/analytics than SS currently supports.

A move to a DO based Email system would be an opportune time to figure
out where to take the SS Mailer backend code. I've had at least one
host that required the use of a SSL SMTP relay host to send mail.
Having a more robust Mailer like Swift Mailer or PEAR Mail would have
been simpler to configure (working with sendmail.mc is so fun!) .
This brings up the question of adding yet-another-smattering-of-third-
party-code though.

My thoughts would be
-Move Email as DO to a module
-Include an optional backend Mailer for that module that can take
advantage of third party services
-Indirectly related, review the current core Mailer code for potential
enhancements to make the above work as well as other mailers that work
from localhost+mail()

Thoughts on my thoughts?

---- Digression below, stop reading to stay on topic ----

I've been fighting a SS 2.3 site I have that sends plain text emails.
The content that gets rendered from a template to the mail() function
has a flaw that causes any of 4 sendmail backends I've tried on CentOS
to not be able to find the To: address (with or without -t). I have
Swift Mailer partially integrated which resolved it, but the code is a
long way from a drop-in replacement Mailer class.

The weirdest part about the SS Mailer code is that the first email
will go through fine, but any subsequent email will fail with the
above issue and end up using the $email->From address as the Cc and To
also. I've been trying to pin down the exact problem on and off for
months.

Before anyone scolds me, yes I will file a bug once I figure out what
the heck is happening :)

[Nicolaas Thiemen Francken - Sunny Side Up]

I like the idea a lot.

[fuz...@gmail.com]

On Jan 12, 6:10 pm, dalesaurus <dale.lis...@gmail.com> wrote:
> I've been fighting a SS 2.3 site I have that sends plain text emails.

> also.  I've been trying to pin down the exact problem on and off for
> months.

> .....snip.....

> Before anyone scolds me, yes I will file a bug once I figure out what
> the heck is happening :)

Very OFFtopic , and maybe this should be moved to the normal SS-user
forum.

BUT !! This sounds very familiar... Do you happen to use XCache ?
If so , what version ?

[fuz...@gmail.com]

let's take the mailer discussion over to :

http://www.silverstripe.org/general-questions/show/259626

[Jeremy Shipman]

I like the idea of using 3rd party mailers. I guess it would be useful
to choose the mailer per email. Eg: you wouldn't want to use up your
3rd party quota sending out 'forgot password' emails.

I'm keen to hear what SS core devs think of this. I'm pretty sure they
would steer clear of the PEAR code you suggest.

[Sam Minnee]

You should be able to choose a different mailer by creating a mailer
class for your third party API and passing it to Email::set_mailer().
I don't think that there should be a separate ThirdPartyMailer class.
Create a separate Mailer subclass for each of your third party
systems. There's no need to add an additional layer of abstraction.

The different Mailers, with their third-party dependencies, can be
included in modules, thus keeping the core nice and lean.

One main core change that could be helpful here is a bit of a
refactoring of the mailer class to separate the header generation and
multipart packaging from the actual sending of the emails.

For example, if Mailer::sendHTML() was rewritten to look like this:

function sendHTML($to, $from, $subject, $htmlContent, $attachedFiles,
$customheaders, $plainContent, $inlineImages) {
$mail = $this->prepareHTMLEmail ($to, $from, $subject, $htmlContent,
$attachedFiles, $customheaders, $plainContent, $inlineImages);
return $this->sendPreparedEmail($mail['to'], $mail['subject'], $mail
['body'], $mail['headers']);
}

You could then simply override sendPreparedEmail() on your Mailer
subclass, without having to rewrite all the multipart logic.

Anyone want to write a patch?

[Toby Champion]

I'm up for working on this patch, unless someone else with more of an
interest than Because It's There wants to do it.

I'm stuck though: I downloaded trunk, ran all the unit tests and many
tests raised the same exception:

file(C:/xampp/htdocs/silverstripe-hacking/trunk/site/) [<a
href='function.file'>function.file</a>]: failed to open stream: No such
file or directory

I'll see what I can do here (I'm running on Windows against PHP 5.2.6),
but if there's something I'm missing here, let me know.

Toby

--
Toby Champion
Poulsbo, Washington, USA
Voice/SMS: +1 (360) 930-9180 (GMT-8)
Web: http://www.tobychampion.com/
Email: to...@tobychampion.co.uk
Skype: tobych

[Toby Champion]

Also, there don't seem to be any unit tests for the Mailer class or for
mailing. Am I missing something?