add filter in bp_send_email to allow html email in wp_mail call

[shawfactor]

Currently when you need to use wp_mail in the bp_send_email function the content sent is plain text. As far as I can see there is not way to override this.

I understand why this is the default but this causes a problem if you have downstream filters on wp_mail and expect or want the output to be in html format. For instance in my case I have html queue class that logs all emails and sends them asynchronously.

Unfortunately if I want to use this class the emails must be plain text, which is not what I want as I have another downstream process that actually makes all emails multipart anyway.

This problem could be fixed by simply adding a filter on bp-core-functions.php line 3201 thus:

$email->get( apply_filters( 'bp_email_content_type', 'content_plaintext' ), 'replace-tokens' )

I really hope something like this could be added to the core plugin

[imath]

Hi @shawfactor

I think you can already filter the content to be HTML. Could you try to use the filter bp_email_get_content_plaintext like what I've wrote into this ​gist?

[imath]

I think we need time to work on this need. From what I understand so far:

If the plain text is used although wp_mail content type is filtered to be text/html is probably due to the fact some plugins might use their own template (header/footer) and forcing ours might be a problem.

I also think only sending html e-mails can be problematic for receivers who set their mail software to only accept plain text. BP e-mails are including an alternate text version of the html e-mail for this case. I don’t see right now how we can/ if we need to check if the use made with wp_mail contains this alternate version (I know it’s possible).

Let’s wait for contributions by the community or other members of the dev team.

[JohnOlek]

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 it's ​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:

​https://buddypress.org/support/topic/buddypress-smtp-settings/
​https://buddypress.org/support/topic/sendgrid-and-buddypress-emails/
​https://ast.io/html-emails-buddypress-bbpress/
​https://buddypress.org/support/topic/buddypress-wont-send-activation-link/

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.

<?php
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 ​in this blog post, but if anyone knows of a reason this shouldn't be considered a full fix I would appreciate the info!

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 ​release notes for version 2.8.0. The filter was added as part of #7286.

Any thoughts would be greatly appreciated. Thanks for reading!