wp_mail removes the Content-Type

[morty]

wp_mail() removes the Content-Type. This breaks _all_ plugins not sending text-mails. Content-Type should be filtered just like the From headers.

Plugin which fixes the problem....

You just need to use the PHPMailer API

$phpmailer->ContentType = "text/plain";

Heh...

This will fix this ticket and add filters galore.

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 );
}

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

Okay, new logic that should fix that issue.

(In [5639]) wp_mail() rewrite that handles HTML mail. fixes #4296

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.

Any examples?

I'll look through the code even so.

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.

Rob1n? ;)

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.

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()?

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

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.

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.

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?

(In [5668]) Revert [5639] for 2.2 branch, it's causing problems. see #4296

Okay, bumping milestone to 2.3.

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

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.

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.

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!

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.

(In [5763]) Don't add MIME-Version header twice (PHPMailer already adds it). see #4296

(In [5764]) Correctly grab Content-Type from old-school headers, skip blank headers. fixes #4296