Ross Wintle

I actually fixed this to use HTML code. I’m not sure if it was @jfarthing84’s intention to use HTML markup or leave link interpretation to the email client. In any case, here’s what I put in class-theme-my-login.php:

$message = '<p>';
		$message .= __( 'Someone requested that the password be reset for the following account:', 'theme-my-login' ) . "\r\n\r\n";
		$message .= network_home_url( '/' ) . "\r\n\r\n";
		$message .= '</p>';
		$message .= '<p>';
		$message .= sprintf( __( 'Username: %s', 'theme-my-login' ), $user_login ) . "\r\n\r\n";
		$message .= '</p>';
		$message .= '<p>';
		$message .= __( 'If this was a mistake, just ignore this email and nothing will happen.', 'theme-my-login' ) . "\r\n\r\n";
		$message .= '</p>';
		$message .= '<p>';
		$message .= __( 'To reset your password, visit the following address:', 'theme-my-login' ) . "\r\n\r\n";
		$url = network_site_url( "wp-login.php?action=rp&key=$key&login=" . rawurlencode( $user_login ), 'login' );
		$message .= '<a href="' . $url . '">' . $url . "</a>\r\n";
		$message .= '</p>';

I appreciate the overall change and re-brand. This will be good for the plugin in the long run. I get why it happened.

But WOW – this was bad for users.

• NOTHING in the plugin changelog to say that this happened.
• It was a MINOR 0.0.x release. I get that it didn’t change any functionality, but a larger version number bump might have drawn attention to what you just did.
• A green monster icon appeared in my Dashboard menu without notification. A MONSTER?! I TOTALLY freaked out.

At the very least, update the changelog in the README to say what’s happened. Please.

Hi @pajohns

The get_avatar() function is both filterable (you can hook a filter function to it) and pluggable (you can replace it entirely with a function in a plugin), so there’s lots of opportunity for the output to get mangled. I’d ask what plugins you have installed and if any of them might be modifying the avatar output.

Do you get the same poor quality output if you disable all your plugins?

Ross

Conversely, if your site runs on a sub-domain, such as blog.mywebsite.com then you should be allowed a from email address on the top-level domain, such as me@mywebsite.com

The comparison is the wrong way around. You need to get the domain from the email address and ensure that that is at the END of the website’s domain.

The last line should probably be something like:

return substr($site_domain, - (strlen($email_arr[1]))) === $email_add[1];

I’ve not tested this code, but it’s an idea that may work.

Oh, and you should probably test that the explode() works as well before accessing $email_arr as an array; explode() can return false!

Of course, it’s possible that the email address could be from a subdomain and the website on the main domain.

Perhaps we just need to rethink this whole thing through again?

I’m getting the same IP(s) on my DO droplet as I’m getting in other places. My DO droplet is already using Google’s DNS. DNS resolution is fine

Thanks @jeronemo. That’s a good tip. If I can’t make any sort of connection to wordpress.com then changing from HTTP to HTTPS isn’t going to make a difference though.