Bug Description
A user reported the HTML Email Report being delivered as plain text when an SMTP plugin that re-implements the wp_mail function is used. The replacement wp_mail bypasses the phpmailer_init action we rely on to set the multipart/alternative content type that tells email clients the message contains both a plain text and HTML body.
We should update the plugin so that, when wp_mail is replaced by an implementation that does not fire PHPMailer hooks, the email is still delivered with the correct HTML content type and renders correctly in the recipient's email client.
Steps to reproduce
Full details and screenshot here
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
- Email reports should continue to render correctly in the recipient's email client when the default WordPress email pipeline (PHPMailer) is in use, with both a plain text and HTML version delivered, as today.
- Email reports should also render correctly when an alternative
wp_mail implementation is in use that does not fire PHPMailer hooks. In this case the plain text alternative may be omitted, which is an acceptable compromise.
Implementation Brief
Files to modify
Backend
Test Coverage
QA Brief
- Activate and configure Post SMTP to deliver via SMTP to an inspectable mailbox (Mailtrap, Mailpit, or a real inbox), and run its test send to confirm delivery works.
- Trigger any Site Kit email send (e.g. an invitation via Site Kit → Admin Settings → Email Reporting, or a report via Tester Settings → Email Reporting), open the delivered email in the mailbox, and confirm the raw headers contain
Content-Type: text/html; charset=UTF-8 with no multipart/alternative boundary and the body renders as styled HTML with no raw <html> or <table> markup visible.
- Deactivate Post SMTP so the default WordPress
wp_mail pipeline is active, trigger another Site Kit email send, and confirm the raw headers contain Content-Type: multipart/alternative with both text/plain and text/html parts and the HTML part still renders as styled HTML.
- Repeat the Site Kit email send check under WP Mail SMTP in place of Post SMTP and confirm the same single-part
text/html Content-Type and HTML rendering.
Before
After
Changelog entry
- Fix bug that could cause plugins handling SMTP to send HTML emails as plaintext emails when sending Email reports.
Bug Description
A user reported the HTML Email Report being delivered as plain text when an SMTP plugin that re-implements the
wp_mailfunction is used. The replacementwp_mailbypasses thephpmailer_initaction we rely on to set themultipart/alternativecontent type that tells email clients the message contains both a plain text and HTML body.We should update the plugin so that, when
wp_mailis replaced by an implementation that does not fire PHPMailer hooks, the email is still delivered with the correct HTML content type and renders correctly in the recipient's email client.Steps to reproduce
Full details and screenshot here
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
wp_mailimplementation is in use that does not fire PHPMailer hooks. In this case the plain text alternative may be omitted, which is an acceptable compromise.Implementation Brief
Files to modify
Backend
includes/Core/Email/Email.php:send_email_and_catch_errors(), inject aContent-Type: text/html; charset=UTF-8entry into the$headersarray passed towp_mail()when no caller-suppliedContent-Typeis already present, so anywp_mailimplementation that respects the headers argument treats the body as HTML.phpmailer_initAltBodyhook in place. When PHPMailer is the active mailer it will continue to upgrade the content type tomultipart/alternativeand attach the plain text alternate, preserving today's behaviour with no functional change for the default WordPress setup.headers_contain_content_type( array $headers ): boolfor case-insensitive callerContent-Typedetection so any caller-supplied content type is respected verbatim and not double-set.@sincetags on the touched methods accordingly.Test Coverage
tests/phpunit/integration/Core/Email/EmailTest.php:Content-Type: text/html; charset=UTF-8header is added to thewp_mail()call when no callerContent-Typeis supplied.Content-Typeheader in any case is preserved verbatim and the default header is not added.phpmailer_initAltBodyhook continues to set the plain text alternative when PHPMailer runs, so the existing multipart behaviour is not regressed.QA Brief
Content-Type: text/html; charset=UTF-8with nomultipart/alternativeboundary and the body renders as styled HTML with no raw<html>or<table>markup visible.wp_mailpipeline is active, trigger another Site Kit email send, and confirm the raw headers containContent-Type: multipart/alternativewith bothtext/plainandtext/htmlparts and the HTML part still renders as styled HTML.text/htmlContent-Type and HTML rendering.Before
After
Changelog entry