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

[buddypress-trac]

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

Comment (by DJPaul):

 I owe everyone following an update, so here goes: my latest code so far is
 on my Github, here: https://github.com/paulgibbs/BuddyPress/compare
 /amazing-emails

 * I have put some framework into core for post types
 * I have registered an "Emails" post type.
  * The intention is to use a standard wp-admin editor box to allow people
 to change the contents of the email.
 * I have replaced all direct calls to `wp_mail` with a new custom function
 `bp_send_mail` that, basically, wraps `wp_mail`.
  * I surveyed all the mail replacement plugins I could find (like
 Mandrill's), and they all re-declare `wp_mail` to implement support for
 their custom service.
  * Therefore, if `wp_mail` is redeclared, *or* something has been filtered
 to get WP to send HTML emails, I'm assuming there's some dark voodoo at
 work -- and for reasons of trying to be compatible as possible, BP will
 treat emails the same way it does today (we'll pass it straight through to
 whatever  `wp_mail` is).
 * `bp_send_mail` does three things; 1) the compatibility checks as
 described above, 2) creates a `BP_Email` object representing the email to
 be sent (the content, addresses, etc), 3) and sends the email.
  * Sending is achieved by looking for a class that represents some kind of
 email delivery service. I'm still playing with the class name, but for
 example, we could have a `BP_WPMail` class that takes our email, sets up
 `wp_mail` appropriately (enables multipart, HTML, etc), then sends the
 email.
  * The idea is to split the message object away from the delivery
 implementation.
  * Mandrill, for example, could create a new BP class in their plugin,
 filter something in BuddyPress, and they'd receive an email object, and it
 would be up to them to format it and send it to their delivery API -- but
 they wouldn't be stomping all over BP core's email implementation to do
 so.
 * There are a number of unit tests in place, but there's more needed.
 * Most of this hasn't been hooked together yet, it's all pretty fragmented
 still.

 Remaining tasks:
 * On new installation/upgrade, auto-create Email objects for each scenario
 in BP. e.g. received a private message, you got mentioned in an update,
 etc.
  * Figure out how best to support i18n here. I think it might be a PITA to
 do well, but we *need* to do it well. :) Biggest problem is what happens
 if English language email posts are created in the DB, but then later the
 site uses a German language packs -- the emails are still in English.
 * Implement Email customisation (maybe font colour, background colour, etc
 -- don't know yet).
  * I am very keen to get @timersys on board to help build out the
 customisation features. He has great experience and really high-quality
 code in in his popular Email Templates plugin that we would be foolish to
 ignore.
 * Finish building out email delivery class/objects/etc and think the
 implementation through a bit more. Write more unit tests.
 * Implement new email template(s).
 * Implement code that grabs those templates (with theme compat. and child
 theme support, etc), replaces tokens with real values (names, links, etc),
 and anything else needed to prepare it for sending. Some of this is
 already done, and some it I will  probably re-use directly from @timersys'
 plugin.
 * Connect all these separate bits together.

 In terms of facilitating contributions from @timersys and @espellcaste and
 anyone else, fork https://github.com/paulgibbs/buddypress/ (use the
 "amazing emails" branch) on Git, and send PRs. If Git isn't your thing,
 you can check out Github repos as SVN, and then run a diff and send normal
 patch files to me, via this trac ticket.

 If you want to help, please co-ordinate with me so we don't duplicate
 effort -- let me know here or email me or find me in the WordPress Slack
 (#buddypress) -- and we can work together.

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