[buddypress-trac] [BuddyPress Trac] #8104: add filter in bp_send_email to allow html email in wp_mail call

buddypress-trac noreply at wordpress.org
Tue May 24 19:01:39 UTC 2022

#8104: add filter in bp_send_email to allow html email in wp_mail call
 Reporter:  shawfactor         |       Owner:  DJPaul
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Contributions
Component:  Emails             |     Version:  4.3.0
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |
Changes (by JohnOlek):

 * cc: JohnOlek (added)


 Hi there!

 I came here from #8108, which feels closer to what I'm looking for but was
 closed as a duplicate of this ticket.

 It seems very unfortunate to me that BuddyPress is incompatible with many
 (most?) of the plugins that allow users to send emails through a custom
 SMTP server, or more generally, using a custom `$phpmailer`. At least out
 of the box.

 WP-Mail-SMTP, which has over 2 million active installs, even has a
 warning] telling users it won'd work out of the box with BuddyPress
 because of BuddyPress's custom method for handling emails.

 Many plugins that handle this kind of override rely on the idea that
 WordPress emails will get send with the global `$phpmailer` instance, so
 they override that variable. Back in February of 2016, BuddyPress moved
 away from using the global `$phpmailer` and instead
 creates its own].

 Based on the commit message for that change, it sounds like the
 justification was mostly due to the fact that BuddyPress doesn't want to
 initialize a global if it doesn't already exist. That makes sense, and it
 definitely is possible that `$phpmailer` might not be initialized because
 /wp-includes/pluggable.php#L262-L262 defined in `wp_mail`], a pluggable
 function that could be completely overridden.

 In practice I suspect there are very few sites out in the world using an
 overridden `wp_mail` that doesn't define a global `$phpmailer`, but I
 could definitely be wrong.

 In any case, I'm wondering if there's a reason we couldn't simply check
 for the existence of the global in the $GLOBALS array and only reference
 it if it exists.

 if (isset($GLOBALS['phpmailer'])) {
   // code to use global $phpmailer goes here

 Unless I'm missing something, it seems like this would avoid the concern
 about potentially initializing an unset global, and it might make
 BuddyPress work out of the box with WP-Mail-SMTP and similar plugins,
 which has clearly been an issue for many people:


 As a workaround I used the `bp_phpmailer_object` filter to ensure that the
 global version is used (I didn't include the global check but definitely
 could have). I wasn't able to find this filter by searching through any
 documentation by the way -- I found it from looking through the source
 code directly.

 add_filter('bp_phpmailer_object', function() {
   global $phpmailer;
   return $phpmailer;

 I was just testing this briefly for a client, and I'm not sure if doing
 just this would be enough to resolve all the issues users have been
 experiencing with sending emails through third party plugins. It feels
 like a cleaner approach than the workaround described  [https://ast.io
 /html-emails-buddypress-bbpress/ in this blog post], but if anyone knows
 of a reason this shouldn't be considered a full fix I would appreciate the

 If nothing else it might be nice to document the `bp_phpmailer_object`
 filter on a page like https://codex.buddypress.org/emails/. The only place
 I'm seeing even a reference to it is in the
 [https://codex.buddypress.org/releases/version-2-8-0/ release notes for
 version 2.8.0]. The filter was added as part of #7286.

 Any thoughts would be greatly appreciated. Thanks for reading!

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8104#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list