Support #4314
Sending only HTML mails without plain text version
| Status: | Closed | Start date: | 2009-08-25 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assignee: | - | % Done: | 100% |
|
| Category: | Finisher | |||
| Target version: | Stable v1.0 | |||
| Votes: | 0 |
Description
I'm having problems with the formatting of my utf-8 encoded HTML mails, and I cannot send the HTML part of the mail as an attachment. Basically, my styling of the mail is ignored. I do know how to write HTML-code that can by understood by mail programs. I'm not sure what exactly the problem is, but when I compare the mails sent via formmailer to the ones I get from direct_mail, I noticed that formhandler creates different headers. I don't really know enough about mail headers to be able to say if this is wrong or just a different way of doing this. If you don't have access to an HTML newsletter sent by direct_mail and are interested in comparing the two, I could post an example here.
Anyway, as a quick and dirty solution, I tried to send only the HTML part of the mail, without a plain text version. I know this isn't perfect, but since this only concerns the mails sent to the admin, compability doesn't really matter in my case.
However, this doesn't seem to be possible at all:
If I simply remove the ###TEMPLATE_EMAIL_ADMIN_PLAIN### marker in the template, the plain text part is still added to the mail, it just remains empty.
If I put my HTML code in the ###TEMPLATE_EMAIL_ADMIN_PLAIN### marker and remove the ###TEMPLATE_EMAIL_ADMIN_HTML### marker, and then manually set the headers of the mail to text/html via typoscript, this setting is ignored and the mail is sent as text/plain.
Any ideas how to solve this? Do I have to write my own finisher?
History
Updated by Reinhard Führicht over 3 years ago
- Assignee set to Reinhard Führicht
- Priority changed from -- undefined -- to Must have
- Target version set to Stable v1.0
It seems that t3lib_htmlmail doesn't work well with HTML-Mails and UTF-8. Furthermore this class doesn't allow to set custom headers (I discovered that already, but didn't add info to the manual, sorry).
I had a quick look at direct_mail and saw that they extend the t3lib_htmlmail class to fit their needs. Maybe this is the way to go for Formhandler too. I will have a look into this.
Regarding the problem with plain text part being set even if the subpart in the template is removed: I am quite sure that this is a bug in Formhandler. Should be fixed quickly.
I will dig deeper into t3lib_htmlmail and post any news here. Please post the two sent emails (formhandler and direct_mail) or at least the headers, so that I can compare them.
Updated by Veronica over 3 years ago
- Assignee deleted (
Reinhard Führicht) - Target version deleted (
Stable v1.0)
Reinhard Führicht wrote:
It seems that t3lib_htmlmail doesn't work well with HTML-Mails and UTF-8. Furthermore this class doesn't allow to set custom headers (I discovered that already, but didn't add info to the manual, sorry).
I had a quick look at direct_mail and saw that they extend the t3lib_htmlmail class to fit their needs. Maybe this is the way to go for Formhandler too. I will have a look into this.
Regarding the problem with plain text part being set even if the subpart in the template is removed: I am quite sure that this is a bug in Formhandler. Should be fixed quickly.
I will dig deeper into t3lib_htmlmail and post any news here. Please post the two sent emails (formhandler and direct_mail) or at least the headers, so that I can compare them.
Thank you for the (as always) quick reply. It would already help a lot if I could send HTML-only mails, because that would reduce the possible error sources.
Do you think it would solve the problem if I sent my mails ISO encoded? Unfortunately, the whole TYPO3 project I'm working on is set to UTF-8, but I guess it would be doable on my part. For formhandler, would it be enough to set the encoding to ISO via typoscript, or would I have to do more changes (e.g. the template file is encoded as UTF-8, will this be a problem)?
I think I might have been wrong about the headers; when I compared the two mails in detail, and used Google to further analyze what I saw, I realized that the differences were probably a result of the fact that the direct_mail newsletter I was looking at also had images attached to it. The only thing that I can't really explain is this additional setting in direct_mail:
Content-Type: multipart/alternative; boundary="----------part_2_49feec6338588" Content-Transfer-Encoding: 7bit
The mails sent by formhandler don't have this "7bit" part, but I guess this could also be a result of the images inserted in the newsletter.
What I also noticed was that in the mail sent via formhandler, the raw code of the mail looked normal. In the newsletter, however, parts of the code had been changed, here's an example:
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso= -8859-1" /> =20
As far as I know this is an result of the setting "Content-Transfer-Encoding: quoted-printable", I don't know why it doesn't appear to have any effect in the mail sent by formhandler.
Here's the raw code from direct_mail:
[...]
Reply-To: xxx
X-Mailer: TYPO3 Direct Mail module
X-Priority: 3
Mime-Version: 1.0
Content-Type: multipart/related;
boundary="----------part_1_49feec63375e7"
Date: Mon, 4 May 2009 15:23:47 +0200 (CEST)
X-PMFLAGS: 570949760 0 1 PMBXUEV5.CNM
This is a multi-part message in MIME format.
------------part_1_49feec63375e7
Content-Type: multipart/alternative;
boundary="----------part_2_49feec6338588"
Content-Transfer-Encoding: 7bit
------------part_2_49feec6338588
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Wenn dieser Newsletter nicht richtig angezeigt wird, klicken Sie=
bitte hier:=20
http://www.xxx.de/index.php?id=3D17
<!-- Cached page generated 04-05-09 15:22. Expires 05-05-09 15:22=
-->
<!-- Parsetime: 143 ms-->
------------part_2_49feec6338588
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd">
<html>
<head>=09
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso=
-8859-1" /> =20
</head
<body>
[...]
</body>
</html>
------------part_2_49feec6338588--
------------part_1_49feec63375e7
Content-Type: image/gif
Content-ID: <part8.cf717cb392184f81e653ca352bdceb00_MID4_t1>
Content-Transfer-Encoding: base64
R0lGODlhFAAHAIABAF5eXv///yH5BAEAAAEALAAAAAAUAAcAAAINjI+py+2PAIBK0otVAQA7
------------part_1_49feec63375e7--
Updated by Veronica over 3 years ago
And here's what I get from formhandler:
[...] Reply-To: xxx X-Mailer: TYPO3 4.2.8 X-Priority: 3 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----------part_1_4a93970760a19" Date: Tue, 25 Aug 2009 09:47:19 +0200 (CEST) X-PMFLAGS: 570950016 0 1 P6801X39.CNM This is a multi-part message in MIME format. ------------part_1_4a93970760a19 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable New registration: [...] Please find the generated invoice attached to this mail. ------------part_1_4a93970760a19 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso=-8859-1" /> </head> <body> [...] </body> </html> ------------part_1_4a93970760a19--
Updated by Reinhard Führicht over 3 years ago
I had a closer look at t3lib_htmlmail and found out that the plain-text header is sent always along with the text/html header.
So, I decided the following:
Formhandler will use it's own class for sending the mails which extends t3lib_htmlmail.
I should have time to do that in the next days, so it should be done at least until next week.
Updated by Veronica over 3 years ago
Reinhard Führicht wrote:
I had a closer look at t3lib_htmlmail and found out that the plain-text header is sent always along with the text/html header.
So, I decided the following:
Formhandler will use it's own class for sending the mails which extends t3lib_htmlmail. I should have time to do that in the next days, so it should be done at least until next week.
Thank you! I'm glad you could identify the problem so quickly. Here's hoping that the core developers will also fix this at some point in the not too distant future...
Let me know if there's any code I can test for you.
Updated by Reinhard Führicht over 3 years ago
- Status changed from New to Needs Feedback
- % Done changed from 0 to 30
I committed some changes.
Formhandler uses it's own mailer class now which extends t3lib_htmlMail.
I added a condition to only print the plain text message if a message exists.
Furthermore I put some basic feature in the code to add custom headers additionally to the default headers. But the additional headers will NOT overwrite default headers by now. Maybe this needs to be changed.
Beware: This is the first version using the new mailer class. I did some basic testing, but I am not completely sure if I did everything correctly. So forgive me, if errors occur.
Veronica, could you please test and give feedback on any errors or additional features needed.
Updated by Veronica over 3 years ago
Reinhard Führicht wrote:
I committed some changes.
Formhandler uses it's own mailer class now which extends t3lib_htmlMail. I added a condition to only print the plain text message if a message exists. Furthermore I put some basic feature in the code to add custom headers additionally to the default headers. But the additional headers will NOT overwrite default headers by now. Maybe this needs to be changed.
Beware: This is the first version using the new mailer class. I did some basic testing, but I am not completely sure if I did everything correctly. So forgive me, if errors occur.
Veronica, could you please test and give feedback on any errors or additional features needed.
Okay, I just got the two files you changed/added, I didn't check out the whole project. Not sure if the following error is related to this:
Fatal error: Class 't3lib_htmlMail' not found in /xxx/typo3conf/ext/formhandler/Resources/PHP/class.formhandler_htmlmail.php on line 44
The mail only got sent after I added this to the top of the class:
require_once(PATH_t3lib . 'class.t3lib_htmlmail.php');
I just tried to send an HTML-only mail by deleting the plain text part of the mail template and manually adding the html header via typoscript:
header = content-type: text/html; charset=utf-8
However, the mail still got sent as "Content-Type: multipart/alternative;", the plain text part was then just missing.
When I try to put my HTML-mail in place of the plain text template, the text/html header set via typoscript is ignored and the mail is still sent as plain/text (only).
Unfortunately, the end result is that I don't really see any improvement when I look at the raw mail code, and the HTML view looks still as bad in my mail program as before.
Updated by Reinhard Führicht over 3 years ago
Ok, the fatal error did not occur when I tested it. I added a require_once.
I can change the behaviour so that the multipart/alternative header is not sent anymore if only plain or html is set.
But I do not understand what you mean by
"When I try to put my HTML-mail in place of the plain text template, the text/html header set via typoscript is ignored and the mail is still sent as plain/text (only)."
When you put your HTML in the HTML-Subpart in the template it is sent as text/html, when you put it into PLAIN-subpart it is sent as text/plain. I don't see why this would surprise you? Or did I get you wrong?
I will continue improving the class tomorrow. By now I committed the require_once change.
Updated by Veronica over 3 years ago
Reinhard Führicht wrote:
Ok, the fatal error did not occur when I tested it. I added a require_once.
Might depend on the TYPO3 version? I'm using 4.2.8.
I can change the behaviour so that the multipart/alternative header is not sent anymore if only plain or html is set.
Yes, please, I'd like to try if that improves the way the HTML mail is displayed.
But I do not understand what you mean by
"When I try to put my HTML-mail in place of the plain text template, the text/html header set via typoscript is ignored and the mail is still sent as plain/text (only)."
When you put your HTML in the HTML-Subpart in the template it is sent as text/html, when you put it into PLAIN-subpart it is sent as text/plain. I don't see why this would surprise you? Or did I get you wrong?
No, it makes sense of course, I just tried this since I couldn't get a text/html only mail the regular way, I only wanted to get rid of the multipart/alternative header.
I will continue improving the class tomorrow. By now I committed the require_once change.
Thank you!
Updated by Reinhard Führicht over 3 years ago
Some things I would like to know before going further:
- Which mail client doesn't show the mails from Formhandler correctly?
- When setting the headers, there are some conditions:
Plain && HTML && !Attachment -> multipart/alternative
Plain && HTML && Attachment -> multipart/related
Plain && !HTML && !Attachment -> text/plain
Plain && !HTML && Attachment -> multipart/related
!Plain && HTML && !Attachment -> text/html
Correct?
Updated by Veronica over 3 years ago
Reinhard Führicht wrote:
Some things I would like to know before going further:
- Which mail client doesn't show the mails from Formhandler correctly?
I know it doesn't work in Pegasus Mail and Outlook 2003.
My best guess it that the main problem is the fact that special characters aren't encoded/masked properly, which might be related to the setting "Content-Transfer-Encoding". For example, the following remains the same in the raw view of a formhandler mail:
<style type="text/css">
I believe it should look like this:
<style type=3D"text/css">
At least that's what direct_mail does, and those HTML mails are displayed correctly. I don't know why that happens, and if this is actually the cause, but the end result is that attributes of tags seem to be ignored (for example, image tags are broken).
- When setting the headers, there are some conditions:
Plain && HTML && !Attachment -> multipart/alternative Plain && HTML && Attachment -> multipart/related Plain && !HTML && !Attachment -> text/plain Plain && !HTML && Attachment -> multipart/related !Plain && HTML && !Attachment -> text/html
Correct?
Plain && !HTML && Attachment should be "multipart/mixed", as far as I can tell.
Other than it looks okay to me (though I'm definitely no expert on this topic). Also, the content types are located in a tree structure:
Plain && HTML && !Attachment:
overall mail: multipart/alternative -> part1 (first): text/plain + part1 (second): text/html
Plain && HTML && Attachment:
overall mail: multipart/related -> part1 (single): multipart/alternative + part2 (first): text/plain & part2 (second): text/html
Updated by Veronica over 3 years ago
My best guess it that the main problem is the fact that special characters aren't encoded/masked properly, which might be related to the setting "Content-Transfer-Encoding". For example, the following remains the same in the raw view of a formhandler mail:
[...]
I believe it should look like this:
[...]
At least that's what direct_mail does, and those HTML mails are displayed correctly. I don't know why that happens, and if this is actually the cause, but the end result is that attributes of tags seem to be ignored (for example, image tags are broken).
Oh, great news: Looks like this really was the problem. I figured I might just as well try what happens if I do this by hand, and edited my whole HTML template to replace any occurrence of
="
with
=3D"
and lo and behold, the mail is now displayed correctly in Pegasus Mail!
Now to figure out why this isn't encoded correctly right away...
Updated by Reinhard Führicht over 3 years ago
Ok, good to know!
This issue made me think about the architecture of Formhandler in general. I started refactoring some parts of the code. My goal is (among other things) to make the mail class used by Finisher_Mail customizable. So that you can easily write your own mail class and plug it into Finisher_Mail. This way you can decide yourself if you want to use t3lib_htmlMail or maybe even the class directmail uses. You would just have to write a wrapper class and enter the class name in TypoScript.
I am not sure how long this will take and I realized that there are many other things to change too. But I am sure, that it will be quite awesome when I'm done. I think it will take me about 2 weeks.
Updated by Veronica over 3 years ago
Reinhard Führicht wrote:
Ok, good to know!
This issue made me think about the architecture of Formhandler in general. I started refactoring some parts of the code. My goal is (among other things) to make the mail class used by Finisher_Mail customizable. So that you can easily write your own mail class and plug it into Finisher_Mail. This way you can decide yourself if you want to use t3lib_htmlMail or maybe even the class directmail uses. You would just have to write a wrapper class and enter the class name in TypoScript.
I am not sure how long this will take and I realized that there are many other things to change too. But I am sure, that it will be quite awesome when I'm done. I think it will take me about 2 weeks.
Before you go and develop your own mail class, take a look at the Swift Mailer library: http://swiftmailer.org/
I haven't used it myself so far, but have heard only great things about it. It takes care of all those nasty headers and everything else. Apparently getting that stuff right yourself is really difficult.
In the meantime, I'll have to see if I can at least fix the encoding manually somehow.
Updated by Reinhard Führicht over 3 years ago
I wasn't planning on writing a new mailer class from scratch.
I ment to have an interface to integrate existing mailer classes into Formhandler.
The interface might look like this:
function sendMail($recipient); function setSubject($subject); ...
This way you can write your own wrapper which implements this interface. The wrapper itself can use t3lib_htmlMail or swiftmailer or some classes from Zend framework, it doesn't matter.
Anyway, thanks for the swiftmailer hint. I will have a look at the features.
Updated by Reinhard Führicht over 3 years ago
- Target version set to Stable v1.0
Updated by Reinhard Führicht over 3 years ago
- Status changed from Needs Feedback to Closed
- % Done changed from 30 to 100
Big update committed today.
Finisher_Mail now needs a mailer component to do the mail sending. The mailer defaults to Mailer_HtmlMail which uses t3lib_htmlmail.
To integrate a new mailer:
- Inherit from AbstractMailer
- Implement MailerInterface
- Enter mailer in TS
finishers.1 {
class = Finisher_Mail
config {
mailer {
class = Mailer_XYZ
config {
...
}
}
...
}
}
I think this should satisfy all needs for now. After some time maybe different mailers will be integrated into Formhandler. For now Mailer_HtmlMail will do the job. If you need further functionality you can now easily integrate your own class.