[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