[wp-trac] [WordPress Trac] #18493: HTML E-Mails

WordPress Trac wp-trac at lists.automattic.com
Sat Jan 28 10:57:57 UTC 2012


#18493: HTML E-Mails
---------------------------+-----------------------------
 Reporter:  aaroncampbell  |       Owner:  westi
     Type:  enhancement    |      Status:  reviewing
 Priority:  normal         |   Milestone:  Future Release
Component:  Mail           |     Version:  3.2
 Severity:  normal         |  Resolution:
 Keywords:  3.4-early      |
---------------------------+-----------------------------

Comment (by rmccue):

 Replying to [comment:22 westi]:
 >  1. How much should be templates versus "magic" - i.e. Do we need to
 have HTML versions of every email body we send or can we just auto-tag the
 text using autop / a simple markup language.

 This is actually harder than it seems, but it is possible. The easiest way
 is to use a HTML-to-Markdown converter, since Markdown is based on email
 formatting.

 In any case, if we want to even think about including full post content in
 text emails, we'll need this. Personally, the excerpt is enough for my
 needs, but I can see that being different for other people. It depends on
 what we'll want in core.

 >  3. Can the emails be made to be themable enough by just letting the
 header/footer be customisable

 Given the state of CSS support in email clients, no. Unfortunately, you
 often need to be able to use inline styling ([http://www.email-
 standards.org/clients/gmail/ Gmail does not support anything but inline
 styling], for example).

 > Phase 1 - This may be starting too small but also should be something
 someone could pull together in a couple of hours as a proof-of-
 not-a-concept ;)
 >
 > Create an api function {{{wp_html_mail( $to, $subject, $message,
 $headers = '', $attachments = array() )}}} which mirrors the API of
 {{{wp_mail()}}} but takes the message and wraps in up into a nice HTML
 blanket.

 What would be the advantage of this over the current proposed solution?
 (That is, overloading `wp_mail`'s body parameter)

 I think the filtering would have to be done pre-`wp_mail`, wherever it's
 called, given the different formatting of all the different emails that
 are sent.

 > This api has filters which allow a theme to do simple child theming of
 the emails:
 >  * Replace the CSS that we output in the header of the email - I believe
 based on my understanding of the limits of HTML emails this will allow for

 As I noted above, email client support isn't good enough to be able to do
 this, unfortunately. One possibility is a per-element filter, but that
 seems somewhat crazy to me. I think being able to replace the whole thing
 is going to be necessity.

 >  * Should we implement a simplified templating language?
 >
 > I think when we review these we will find that on balance an output
 buffering based template system is best because it gives theme developers
 the most familiar experience and gives them full control.

 I have to agree. While output buffering is fairly ugly from our
 perspective, it's much nicer from a theming perspective. To me, a
 templating language is not WordPress-y enough, and I think it would likely
 be a bit confusing.

 > It would be great if we could all get together in IRC early next week to
 discuss - I'm around most week days 9am-5pm UTC.

 I'm around most days from 3am-5pm UTC, and I can be on IRC for all of that
 time if I remember to open my client. :)

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18493#comment:23>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list