[buddypress-trac] [BuddyPress Trac] #6592: Email API and customisation features

buddypress-trac noreply at wordpress.org
Tue Jan 5 20:34:38 UTC 2016

#6592: Email API and customisation features
 Reporter:  DJPaul            |       Owner:  DJPaul
     Type:  idea              |      Status:  assigned
 Priority:  normal            |   Milestone:  2.5
Component:  Component - Core  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |

Comment (by DJPaul):

 Progress is going well, but I wanted to share a technical overview to aid
 with code review:

 Researching WP plugins that support services such as Mandrill or Amazon
 SES showed a common approach of replacing `wp_mail()`. Some made
 formatting changes, some just delivered the email to the external service,
 some did both.

 I looked at a few other PHP CMS projects to see how they approached
 things. I remember looking at Joomla!, Drupal, and a handful of others. I
 was hoping to find a nice architectural model or technical implementation,
 but everything looked like `wp_mail()`. I wanted to split email delivery
 away from the internal representation of an email itself.

 * Class `BP_Email` represents an email; the bits you see in your email
 client like the subject, message, recipients. It also encapsulates custom
 email headers and tokens.
  * Tokens help personalise the content of an email. Analogous to
 MailChimp’s merge tags.
 * Class `BP_Email_Recipient` represents an email recipient. It’s a simple
 class, and holds an email address and recipient name. If the class is
 instantiated with a WordPress user ID, then it also has a `WP_User`
 * Class interface `BP_Email_Delivery` mandates a `bp_email()` function,
 which mail delivery services will use to implement BuddyPress support.
  * Class `BP_PHPMailer` implements that interface for PHPMailer.
 * Function `bp_send_email()` is the function we use to send emails.
  * If `wp_mail()` has been re-implemented, then BuddyPress will fallback
 and use it (work in progress, may change).

 The other major feature that I wanted to implement was user-editable
 emails. WordPress multisite lets you edit some of its emails in a basic
 textarea. BuddyPress requires a code filter. Both are crappy solutions.

 * An email post type and an “email type” taxonomy have been added.
 * All of BuddyPress’ emails have been moved into email posts.
  * Tokens are used to personalise the email content (i.e. to add a link to
 the recipient’s user profile).
  * Each type of email in BuddyPress has been assigned a unique type, and
 these are mapped to the email post with the “email type” taxonomy.
 * A HTML email template has been added.
 * A Customizer integration allows email appearance changes.
 * Extensive effort has been made to maintain backwards compatibility for
 existing email filters, but there will be some breakage (some parameters
 will be removed from some actions).

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

More information about the buddypress-trac mailing list