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

Merged
merged 3 commits into from Jan 18, 2014

Conversation

Projects
None yet
3 participants
Contributor

ditorelo commented Sep 24, 2013

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.

Tyding up conflicting logic on email alerts
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 functino on text::auto_p() to
produce better looking messages
Owner

rjmackay commented Sep 25, 2013

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?

Contributor

ditorelo commented Sep 25, 2013

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.

Contributor

ditorelo commented Sep 25, 2013

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

Contributor

ditorelo commented Sep 25, 2013

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.

mail - zombie reports asdfas

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. :)

Owner

rjmackay commented Sep 25, 2013

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..

Contributor

ditorelo commented Sep 25, 2013

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.

Contributor

ditorelo commented Sep 25, 2013

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?

@@ -113,16 +113,22 @@ public static function connect($config = NULL)
* @param boolean send email as HTML
* @return integer number of emails sent
*/
- public static function send($to, $from, $subject, $message, $html = FALSE)
@rjmackay

rjmackay Nov 4, 2013

Owner

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.

Owner

rjmackay commented Nov 4, 2013

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.

// EMAIL MESSAGE
- $email_message = $incident_description."\n\n".$incident_url;
+ $email_message = $incident_description . "\n\n" . $incident_url;
// SMS MESSAGE
$sms_message = $incident_description;
@rjmackay

rjmackay Dec 12, 2013

Owner

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

Owner

kamaulynder commented Jan 18, 2014

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

kamaulynder added a commit that referenced this pull request Jan 18, 2014

Merge pull request #1249 from ditorelo/943
Tiding up conflicting logic on email alerts (Issue #943)

@kamaulynder kamaulynder merged commit e6e619d into ushahidi:develop Jan 18, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment