Page 1 of 1

Sending emails depending on the subscriber preferences

Posted: Thu Apr 05, 2007 12:03 am
by oth
Hi,

So here is the scenario:

I have a newsletter subscription form, the potential subscriber can choose the format of the newsletter, that is, html or plain. In the backend administration, the newsletter is created in two formats, plain and html.

Basically when sending the newsletter, I have to decide which newsletter format I should send to a particular subscriber.

Suppose I have an array from the database, something like that:

Code: Select all

$subscribers = array(0=>'email'=>'...@domain.tld','format'=>'plain',1=>'email'=>'...@domain.tld','format'=>'html',..);
Also suppose the content of the html and plain newsletters are respectively hold in $htmlNewsletter and $plainNewsletter.

Now here comes my question, what's the best practice to do the send ?

Should I loop through the subscribers array do a conditional test and call send() with the appropriate newsletter' content for each subscriber ? or Should I split the subscribers list in two categories, html and plain, and call send twice ? or is there a Swift way of handling this ?
The decorator plugin is for decorating the message, in this case it's different because I want to tell it: send $plainNewsletter for this subscriber and send $plainNewsletter ( text/html ) for that other subscriber.

Any thoughts ?

Thanks in advance.

Posted: Thu Apr 05, 2007 2:25 am
by Chris Corbyn
It would be faster to group all HTML and all PLAIN together. But Swift sends in multipart so why not simplify things (for the end user) and just send a multipart message then let their mail client preferences use the correct part? This will also reduce your spam score on the HTML-only emails, since HTML-only gets penalized a little.

Posted: Thu Apr 05, 2007 12:11 pm
by oth
Well currently, that's what I'm doing, sending a message of two parts HTML and PLAIN. The thing is, though, if a subscriber chose to receive the PLAIN version of the newsletter it would probably be because he wants the PLAIN version even if his/her client has support for HTML Emails.
So letting the client choose is not the best bet.

When sending HTML, I always attach a plain part which is basically a strip_tags()-ed version of the HTML one.

But now there is the PLAIN version, which is probably different than the HTML one, maybe it just contains an URL where the subscriber can see the HTML version.

So I'm still lost, my only concern is performance. I guess grouping and sending is what I should do.

Posted: Thu Apr 05, 2007 3:57 pm
by Chris Corbyn
oth wrote:Well currently, that's what I'm doing, sending a message of two parts HTML and PLAIN. The thing is, though, if a subscriber chose to receive the PLAIN version of the newsletter it would probably be because he wants the PLAIN version even if his/her client has support for HTML Emails.
So letting the client choose is not the best bet.

When sending HTML, I always attach a plain part which is basically a strip_tags()-ed version of the HTML one.

But now there is the PLAIN version, which is probably different than the HTML one, maybe it just contains an URL where the subscriber can see the HTML version.

So I'm still lost, my only concern is performance. I guess grouping and sending is what I should do.
Yes, group and send will be faster. Do the messages very for each recipient?

Posted: Thu Apr 05, 2007 7:35 pm
by oth
Do the messages very for each recipient?
No they don't vary. the subscribers that chose to have an HTML version should receive an email with two parts, HTML and PLAIN-STRIP_TAG() of the HTML version. The subscribers that chose PLAIN should receive the plain version.

Posted: Fri Apr 06, 2007 5:05 am
by Chris Corbyn
Ok, well if they don't vary make sure you either use batchSend() or re-use the same $message object. The message object is optimized to cache itself at runtime so it's lots faster to re-use it.

Posted: Fri Apr 06, 2007 4:40 pm
by oth
Isn't batchSend() just a loop that calls send() with the same message and one address at a time anyway ?

Posted: Sat Apr 07, 2007 7:31 am
by Chris Corbyn
oth wrote:Isn't batchSend() just a loop that calls send() with the same message and one address at a time anyway ?
Yep. I was just referring to the way Swift caches messages. Provided you don't keep making new message objects then you'll get the performance benefits anyway. The only bit that gets re-rendered are the address headers.

You *may* actually find you get a speed increase from using the disk cache wherever possible. Something like this after you require() Swift.php.

Code: Select all

$sess_save_path = ini_get("session.save_path");
if (is_writable($sess_save_path))
{
  Swift_CacheFactory::setClassName("Swift_Cache_Disk");
  Swift_Cache_Disk::setSavePath($sess_save_path);
}