GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
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
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?
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.
I mean, I've seen a few email clients completely bust line breaks in plain text messages before. :)
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:
$html = TRUE
This won't change current behaviour for anyone I think. :)
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..
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.
Updating send class to attach a plain text version to message when $h…
…tml = true
Cleaning up alerts scheduler
Update behaviour so:
$html = FALSE
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).
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.
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.
Need to update this to make sure we still remove HTML from the SMS message :)
reviewed the calls to email::send() and they are on $html = FALSE.
Merge pull request #1249 from ditorelo/943
Tiding up conflicting logic on email alerts (Issue #943)