[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