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

buddypress-trac noreply at wordpress.org
Fri Aug 14 19:45:33 UTC 2015


#6592: Email API and customisation features
------------------------------+-----------------
 Reporter:  DJPaul            |      Owner:
     Type:  idea              |     Status:  new
 Priority:  normal            |  Milestone:  2.4
Component:  Component - Core  |    Version:
 Severity:  normal            |   Keywords:
------------------------------+-----------------
 We've wanted to overhaul emails in BuddyPress for the longest time. The
 problems with our current implementation is that we don't really have an
 implementation: we just use `wp_mail`. While the email content is
 filtered, it still requires a developer to write code to customise the
 email, when really, the site owner should be able to do that themselves.
 Cosmetically, we send plain text emails, and I don't think that is simply
 good enough for modern expectations.

 Even WordPress multisite's network admin has better email editing features
 (just a textarea, but we don't even have that), and no-one's touched that
 part of multisite for a very long time.

 So, after much discussion with interested parties over the years in dev
 chats, support forums, and WordCamps, here are the foundations that I
 propose we build our experience on:

 * Use a Post Type for email templates.
  * Use wp-admin to edit them.
  * Use the [http://wptavern.com/edit-wordpress-email-templates-in-the-
 customizer WP Customiser to visually customise those emails].
  * Use `post_content` to store the HTML version of the email, and
 `post_excerpt` to store the plain text version.
  * Use a set of `printf`-like tokens to dynamically replace text in the
 email (username, links, etc) as required.
 * Use a Taxonomy to store the distinct types of emails we send (e.g.
 new_user, new_site, new_activity_mention, etc).
  * Use the taxonomy to find the related Email (post type instance).
  * Taxonomy instead of post_meta to (potentially) scale better, and allow
 advanced use case e.g. an implementation of a basic A/B test for emails.
 * Introduce new HTML email templates into the BP template stack, with a
 template hierarchy (user type, component).
 * Introduce new classes to represent an email (`BP_Email`), one for each
 type of email.
  * Has: filters, callback functions to fetch the token replacements,
 convenience functions to access `WP_Post` properties
 (`bp_email->get_subject`, etc).
  * Provide basic API for fetching/creating these objects, like we did for
 the xprofile field types.
 * Create an interface, and a class (that uses it) that takes the assembled
 `BP_Email` object, and sends the email with `wp_mail()`.
  * Structure of this class is set with an interface, which will allow
 easier integration with third-party mail delivery services (e.g.
 mailchimp). Currently, all of these plugins I've researched replace the
 `wp_mail` function which is not ideal.

 (I couldn't find an existing ticket for this, despite all the discussion
 over the years.)

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


More information about the buddypress-trac mailing list