Reset password link is in < RESET_URL > - Gmail does not show it.

[tommix]

This is not WP bug, but WP sends password in "<" and ">" and google looks like filtering it and in mail there is no link. If i remove those simbols from wp-login.php
$message .= '<' . network_site_url("wp-login.php?action=rp&key=$key&login=" . rawurlencode($user_login), 'login') . ">\r\n";

Then link is in email. SO we have to change < > to let's say ( ).

I just tested this and it works fine for me, the link is there and clickable.

I do think the less than/greater than signs look a little weird -- the email would be better, in my opinion, if they were removed entirely -- but they don't seen to actually break anything.

They actually serve a purpose, They define the start and endings of links in Plain Text emails, many (at least older) email clients that only use Plain Text required <..> around url's to define the boundaries, It's more of a problem when the link is long and wraps onto a second line.

It's part of the Plain Text email RFC from memory, and is also ​recommended for other addressing methods in plain text.

The "proper" thing here IMO, isn't to change the Plain text emails to be "prettier" but instead, to implement proper HTML emails so that we can style things properly: #18493

That being said, I find it hard to believe Gmail is including the brackets in the link, as I use plain text emails in Gmail every day which use that syntax.. I'd expect it to be caused by a browser addon myself.

I'm using HTML mails, i did it in functions.php file, and you all maybe using Plain text.
Hard to believe or no - it DOESN't show reset url. not for me only, my friend first told me about this, i was thinking maybe plugin causes this, but no, after i changed wp-login.php file to remove < > -it worked.

First mail - withouth changing wp-login.php, second -after changes.

I'm using HTML mails, i did it in functions.php file, and you all maybe using Plain text.

Then the Plain text -> HTML markup processing is faulty in your modifications/plugin/theme, It's probably just using content passed verbatim instead of escaping the content for display in HTML emails, that's not a core problem.

Replying to dd32:

I'm using HTML mails, i did it in functions.php file, and you all maybe using Plain text.

Then the Plain text -> HTML markup processing is faulty in your modifications/plugin/theme, It's probably just using content passed verbatim instead of escaping the content for display in HTML emails, that's not a core problem.

WORDPRESS sends reset emails, not themes. So this is core problem. I do not process any mails.
People please if you comment - enable HTML mails in WP, use reset password function with GMail and them write your opinions. This is the basic WP function, nobody changes it, why theme have to change something? I'm sending many URLs and all is working exept this one.

enable HTML mails in WP

WordPress does not send HTML emails at present. How are you enabling HTML emails in the first place?

Replying to dd32:

enable HTML mails in WP

WordPress does not send HTML emails at present. How are you enabling HTML emails in the first place?

WP doesnt send html, it sends text but mail type (header) is changed to HTML.

function html_laiskai(){

return "text/html";

}

add_filter( 'wp_mail_content_type','html_laiskai' );

WP doesnt send html, it sends text but mail type (header) is changed to HTML.

By changing the mime type, you're forcing the WordPress plain text emails content to be parsed as HTML, Since html uses < and > for tags, it's causing the content to break. Since you're not doing any further processing to the emails, it sounds like setting the content type for all emails isn't what you should be doing, it won't suddenly make emails better.

So, Either stop doing that, or also apply esc_html to the mail body, and it'll work as you expect.

You'd need to do something like this: (untested)

add_filter( 'wp_mail', 'html_email_encode_body' );
function html_email_encode_body( $mail ) {
  $mail['message'] = esc_html( $mail['message'] );
  return $mail;
}

Replying to dd32:

WP doesnt send html, it sends text but mail type (header) is changed to HTML.

By changing the mime type, you're forcing the WordPress plain text emails content to be parsed as HTML, Since html uses < and > for tags, it's causing the content to break. Since you're not doing any further processing to the emails, it sounds like setting the content type for all emails isn't what you should be doing, it won't suddenly make emails better.

So, Either stop doing that, or also apply esc_html to the mail body, and it'll work as you expect.

You'd need to do something like this: (untested)

add_filter( 'wp_mail', 'html_email_encode_body' );
function html_email_encode_body( $mail ) {
  $mail['message'] = esc_html( $mail['message'] );
  return $mail;
}

Well this helped for reset email but messed up my real HTML mails, now it just plaint html source.

Well this helped for reset email but messed up my real HTML mails, now it just plaint html source.

In that case, You'll need to only change the mimetype for the emails you're sending, not the core ones, You can do that by something similar to the following - which is how this filter was seemingly intended on being used, on a per-email basis by adding and removing the filter.

....
add_filter( 'wp_mail_content_type','html_laiskai' );
wp_mail( my html messages );
remove_filter( 'wp_mail_content_type','html_laiskai' );

Closing as invalid since WordPress was doing exactly as you were asking (Note, you can still reply without re-opening the ticket if need be)

Well i wouldn't say that this ticket is invalid, it is valid, and this is some kind of bug. All mails should by default be HTML type. We what living in 90's? It's stupid to everytime you want to send mail to apply filters, send mail and then undo filters. I'd better change core file and that's it. No need to put urls in < >

Replying to tommix:

All mails should by default be HTML type.

And we already have a ticket for that: #18493.

No need to put urls in < >

Per #14140, there's a reason for them to be there.

Replying to SergeyBiryukov:

No need to put urls in < >

Per #14140, there's a reason for them to be there.

So his problem is important and mine no? I don't see reason why broken links is worse than no links at all in mail.

In your case, the links are only missing when the message is incompletely converted to HTML, not by default.

Implementing HTML emails in a consistent manner makes more sense to me than reverting a valid fix in order to support an incomplete workaround.