Tiding up conflicting logic on email alerts (Issue #943)

[ditorelo]

HTML2Text was being called on message, but we're sending messages as HTML. This was producing nasty emails and sad alertees.

Removed the call to HTML2Text and wrapped function on text::auto_p() to produce better looking messages.

[rjmackay]

The original behaviour here was to send plain text emails.. I was working on the same issue for a client build recently but haven't had a chance to clean up my fix yet.

Any thought on whether plain text or html message will work better?

[ditorelo]

I reckon we have more general control of how it renders with HTML markup as I've seen line breaks go completely bust in plain text message in a few cases before. (This is a very weak argument though...)

I'm not sure if SwiftMailer creates a text based version of the message as it sends it. I'll have a look and get back to you.

[ditorelo]

I mean, I've seen a few email clients completely bust line breaks in plain text messages before. :)

[ditorelo]

SwiftMailer doesn't automagically generate a text version of the message. Having said that, the text version for this particular case is not that unreadable.

Another possible solution would be to update email_Core::send:

• if the function is called with $html = TRUE
• run message content through html::strip_tags
• call $message->addPart($content, 'text/plain'); to provide a plain text option.

This won't change current behaviour for anyone I think. :)

[rjmackay]

Ooh. Sending an HTML and plain text version would definitely be good. It'd allow us to improve some of the existing message formatting too.
Would it make sense to run it through HTML2Text for the plain text version?

One thing to watch for is that there are a few of the message templates that assume they'll be sent in plain text, so you might need to use nl2br on those..

[ditorelo]

I'll have a go at it.

HTML2Text seems to be doing a very bad job on what it promisses - stripping line breaks and such.
I'll have a play with our options and get back to you.

[ditorelo]

Update behaviour so:

• Every message that is created with $html = TRUE will attach a plain text version of itself to message body.
• Messages with $html = FALSE remain unaltered.

HTML2Text is nice, the way the alerts function was mixing it up with the html header is not.

I reckon this might call for a review of all calls to email::send() around the code. It might be the case that a plain text message is being passed to the function with $html = TRUE, which will make things confusing (this was the cause of the original problem with the alerts).

Wadjuracoon?

[rjmackay]

I think you should be able to override/extend this function by adding a file application/helpers/MY_email.php. If we do it that way its easier to see whats been customised or not.

[rjmackay]

Definitely like this idea. You're right that we'll need to review all the other calls to email::send() since some of them do something similar to alerts.

[rjmackay]

Need to update this to make sure we still remove HTML from the SMS message :)

[kamaulynder]

reviewed the calls to email::send() and they are on $html = FALSE.