Opened 18 years ago
Closed 18 years ago
#4296 closed defect (bug) (fixed)
wp_mail removes the Content-Type
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 2.3 | Priority: | high |
Severity: | major | Version: | 2.2 |
Component: | General | Keywords: | has-patch |
Focuses: | Cc: |
Description
wp_mail() removes the Content-Type. This breaks _all_ plugins not sending text-mails. Content-Type should be filtered just like the From headers.
Attachments (4)
Change History (35)
#7
follow-up:
↓ 8
@
18 years ago
I'm not 100% sure how phpmailer works but some of this code may be contradictory.
We are checking for Content-Type and setting it as text/plain if it is not set.
However, I have a plugin that passes some mail via wp_mail() that sets the Content-Type as text/html. With his diff the Content-Type will be left alone but the code still invokes $phpmailer->IsHTML( false ); which presumably tells phpmailer that the email isn't html when in fact it is!
Something like this might avoid this problem (if indeed it is still a problem after the patch.
if ( !isset( $content_type ) ) { $content_type = 'text/plain'; $phpmailer->IsHTML( false ); } elseif ( isset( $content_type) && ($content_type == 'text/plain' ) { $phpmailer->IsHTML( false ); } elseif ( isset( $content_type) && ($content_type == 'text/html' ) { $phpmailer->IsHTML( true ); }
#8
in reply to:
↑ 7
@
18 years ago
... but the code still invokes $phpmailer->IsHTML( false ); which presumably tells phpmailer that the email isn't html when in fact it is!
I have the same problem. My "DJ-Email-Publish" plugin sends the post via wp_mail().
It works not well since 2.2, because wp_mail will be sent HTML mail ($phpmailer->IsHTML( false );).
#11
@
18 years ago
I'm getting some reports of funkiness with mail when using the latest from the 2.2 branch.
I'm seeing weird stuff in my comment e-mails - escaped quotes and the mime info in the msg body.
#15
@
18 years ago
Here's an example of mime being in the body. I removed personal info from the headers.
From: xxx Date: June 4, 2007 10:48:39 AM MDT To: xxx Subject: [foo.bar] Comment: "Foo is the new Bar" Reply-To: xxx : MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8"
I asked the original reporters to drop a note on this ticket.
#17
@
18 years ago
I've taken a look through the code, and upon visual inspection I can't find anything faulty, but I'm now going to be running specific debugs and tests.
See where that gets me.
#18
follow-up:
↓ 19
@
18 years ago
Okay, I found some errors in my coding, but any extra headers I called wp_mail() with, nothing showed up in the body.
How did they call the wp_mail()?
#19
in reply to:
↑ 18
@
18 years ago
Replying to rob1n:
How did they call the wp_mail()?
I'm not sure I understand the question. Would be happy to provide more info from my end if I know what you are asking for. :)
#20
@
18 years ago
Like, what was the function call and the arguments?
I tried variations on the headers argument, but I still couldn't find the issue of headers in the body.
#21
@
18 years ago
As far as I can tell, it's every instance. For days, any notifications for moderation or new comments all have the weird headers that display into the message itself.
#22
@
18 years ago
Okay, I'm just going to yank this out of 2.2 and leave it in 2.3, where I will commence debugging. The only reason why I put this patch in 2.2 is because the reporter says it breaks HTML emails, but I guess it's plain text for now?
#25
@
18 years ago
Just for information I was getting reports back from some WordPress 2.2 users of my plugin that Content-Type was being added as a header defined as text/plain and was also being added as text in the body of the email as text/html when my plugin was sending HTML emails.
If you want to see who my plugin constructs the emails see the publish (starts at line 327) and mail (starts at line 232) functions here:
http://dev.wp-plugins.org/browser/subscribe2/branches/WordPressMuand2.1/subscribe2/subscribe2.php
#26
@
18 years ago
Further update. I think the issue with my plugin was I was using Content-type with a small 't' whereas the wp_mail looks for Content-Type with a big 'T'. on not finding it the new header is added.
The problem here is that both may be valid depending on which document you read :-( For strict coding though it should bt 'T' - so my bad.
#27
@
18 years ago
I believe those headers are case-sensitive. There was a ticket that I committed in the last month or so that changed all mentions of "Content-type" to "Content-Type" in the WP source.
#28
@
18 years ago
Like HTTP headers, MIME headers are not case sensitive. See section 1.2.2
WP should be comparing such headers in a case-insensitive way. If we're requiring a header to have a certain type of capitalization, that's a bug!
#29
@
18 years ago
- Keywords has-patch added
I've attached a patch which makes the relevant MIME header compares case-insensitive.
I've also made sure that that mime header is actually used, because the current code always adds a Content-Type: text/plain, whatever the input.
Plugin which fixes the problem....