[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`
reference.
* 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