[wp-trac] [WordPress Trac] #23578: URLs wrapped in <> parsed as HTML when wp_mail_content_type set to text/html

[WordPress Trac]

#23578: URLs wrapped in <> parsed as HTML when wp_mail_content_type set to
text/html
-----------------------------+--------------------------
 Reporter:  iandunn          |       Type:  defect (bug)
   Status:  new              |   Priority:  normal
Milestone:  Awaiting Review  |  Component:  Mail
  Version:  3.1              |   Severity:  normal
 Keywords:                   |
-----------------------------+--------------------------
 [16285] wrapped the password-reset URL in the e-mail sent from
 retrieve_password() in greater-than/less-than signs in order to prevent it
 from breaking when line wrapped (see #14140). That has the side-effect of
 causing the URL to be parsed as HTML by the mail client when the message's
 content-type is set to text/html via the wp_mail_content_type filter. I
 don't see any other places in Core where this happens.

 Using wp_mail_content_type to enable HTML e-mails is a common technique
 documented on the Codex and across the Web. Is it considered a bad
 practice to enable it globally -- as opposed to adding it before calling
 wp_mail(), then removing it after; or just setting the content type in the
 $headers param of wp_mail()? If so, we should document that on the Codex
 and possibly in wp_mail() where the filter is applied.

 Even if it is, I don't think it'd hurt to have retrieve_password() check
 the content-type and behave accordingly. If it's "text/html", then create
 a proper link; otherwise wrap the URL in greater-than/less-than signs.

 If everyone agrees on that approach, I'll submit a patch.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23578>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software