[buddypress-trac] [BuddyPress Trac] #6592: Email API and customisation features
noreply at wordpress.org
Sat Sep 19 21:36:02 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 | Resolution:
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
* 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
* The idea is to split the message object away from the delivery
* 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
* 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
* 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,
* 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
* 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'
* 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/>
More information about the buddypress-trac